Dialogic: Local & Global Visited Events History

Hey guys! Let's dive into a cool discussion about enhancing Dialogic, specifically concerning the visited_events_history. Currently, it's stored globally, which is awesome for certain situations, but what if we could make it even more flexible? Let's explore the possibilities!

The Current Scenario: Global History

Right now, the visited_events_history in Dialogic operates on a global scale. What does this mean? It means that the history of events you've visited is stored independently of your current slot or playthrough. This can be super handy! Imagine you're creating a game where you want players to easily skip sections they've already experienced. With the global visited_events_history, this becomes a breeze. Players can jump around, revisit areas, and the game intelligently remembers what they've seen, making for a smoother, more user-friendly experience.

Think about it – no more repetitive dialogues or re-reading the same exposition dumps! Players who've already invested time in your game can quickly navigate to new content or specific areas of interest without feeling bogged down. This is a great way to respect their time and keep them engaged. Furthermore, a global visited_events_history can be incredibly useful for testing and debugging your game. You can quickly jump to different parts of the narrative to ensure everything is working as intended without having to replay the entire game from the beginning each time. This can save you countless hours in the development process and help you deliver a more polished final product.

From a design perspective, this global approach also allows for interesting meta-game mechanics. For example, you could create achievements or unlockable content based on the player's overall journey through the game, regardless of how many times they've restarted or switched between save slots. This adds another layer of depth and encourages players to explore every nook and cranny of your game world.

The Need for a Local Perspective

However, there are situations where a more localized approach would be beneficial. Consider scenarios where you want to track event visits within a specific run or slot. Choices, for example, currently use the visited_events_history to provide a visited_before variable to _load_info(). The problem? It's global, which often isn't what you'd want. Think about it: you might want a choice to appear different or have different consequences based on whether it's the first time you're encountering it in this particular playthrough.

For instance, imagine a branching narrative where a character reacts differently depending on whether you've spoken to them in the current session. With a global history, the game might remember that you've talked to them ever, even if it was in a completely different playthrough. This could lead to confusing or nonsensical interactions, breaking the player's immersion and making the game feel less responsive to their current actions.

A local visited_events_history would solve this problem by providing a way to track event visits on a per-slot or per-run basis. This would allow you to create more nuanced and context-aware interactions, making your game feel more dynamic and reactive to the player's choices. You could implement consequences that only trigger the first time a player encounters a specific event in a given playthrough, or offer different rewards based on their actions in the current session.

Moreover, a local history could be incredibly useful for creating games with roguelike or roguelite elements. In these genres, players typically start fresh with each run, and it's important to track their progress and choices within that specific run. A local visited_events_history would allow you to create events and encounters that evolve and adapt based on the player's actions in the current playthrough, adding replayability and depth to your game.

The Proposed Solution: Best of Both Worlds

So, what's the solution? We need a way to have both global and local visited_events_history independently of each other. This would give developers the flexibility to choose the right approach for each situation, opening up a whole new world of possibilities for creating dynamic and engaging narrative experiences.

Implementing the Change

There are a few ways we could approach this. One option would be to introduce a new setting or flag that allows developers to specify whether the visited_events_history should be stored globally or locally for a particular event or project. This would provide a simple and intuitive way to control the behavior of the history without requiring significant changes to the underlying code.

Another approach would be to create two separate history objects: one for global visits and one for local visits. This would allow developers to access both types of history directly, giving them maximum flexibility in how they use the information. However, this approach might be slightly more complex to implement and could potentially increase the memory footprint of the game.

Regardless of the specific implementation, the goal is to provide developers with the tools they need to create the best possible experience for their players. By offering both global and local visited_events_history, we can empower them to create more dynamic, engaging, and responsive narrative experiences.

Use Cases

Let's look at some specific use cases to illustrate the benefits of having both global and local visited_events_history:

• Choices with Context: Imagine a game where the player can choose to help a character in need. If the player has helped the character before (globally), the character might recognize them and offer a discount or special item. However, if the player has already helped the character in the current playthrough (locally), the character might simply express their gratitude and offer a different reward, such as information or a new quest.
• Dynamic Dialogue: A character's dialogue could change based on whether the player has visited a specific location in the current run. For example, if the player has already explored a dangerous dungeon, the character might warn them about the dangers that lie ahead. However, if the player hasn't visited the dungeon yet, the character might simply provide directions and basic information.
• Roguelike Elements: In a roguelike game, you could use the local visited_events_history to track the player's progress through each run. This could be used to create events that become more challenging or rewarding based on how far the player has progressed in the current run. For example, you could introduce new enemy types or unlock new areas as the player explores deeper into the game.
• Tutorials and Hints: You could use the global visited_events_history to track whether the player has completed a tutorial or received a specific hint. This would prevent the game from repeatedly displaying the same tutorial or hint, even if the player restarts the game or switches between save slots.

Conclusion: Enhancing Dialogic's Flexibility

By adding the ability to have both local and global visited_events_history, we can greatly enhance the flexibility and power of Dialogic. This would allow developers to create more dynamic, engaging, and context-aware narrative experiences, ultimately leading to better games for players. This enhancement would provide a more nuanced and adaptable system for tracking player progress and choices, opening doors to more immersive and personalized gaming experiences. What do you guys think? Let's discuss!