In this Vertical Slice, the dialogue system is not just a tool for displaying text. The project itself relies heavily on exploration, NPC interaction, and player choice, so the conversations between the player and characters also need to carry some mechanical functions. Through dialogue, the player can gain information, understand character relationships, make responses, and potentially change how NPCs feel about them or push the story state forward.
Because of this, I do not see the Dialogue Manager as simply “showing text on screen”. I understand it more as a player input system. Dialogue options are essentially player choices, and choices need to have consequences. These consequences could be a change in reputation value, gaining or consuming an item, or setting a story flag that affects later dialogue and quest states.
Based on this need, we used Ink as the foundation of the dialogue system. Ink is well suited for branching narrative, as it supports branches, choices, variables, and tags. Its main advantage is that it allows narrative content to be separated from Unity scene logic. The dialogue text and branches can be written inside Ink files, while Unity reads the Ink content and translates its variables or tags into actual game state changes. This is also very useful for our team workflow. Our Narrative Designer can directly write interactive dialogue, instead of giving me a Word document that I then have to manually convert and re-edit into a dialogue system.
As a Mechanics Designer, what I cared about most was how Ink connects with other systems. The GDD includes design directions such as reputation, character relationships, item interaction, and multiple story outcomes, so the dialogue system needs to interact with these mechanics. For example, when the player talks to Sierra or Marcus, different choices can change their reputation. Whether the player has the Map, Mushroom, or Compass can also affect what information or options are visible in the dialogue. Some key actions can also be recorded through story flags and then influence later dialogue branches.
In the later production version, this direction became much clearer. The Dialogue Manager does not only play Ink text. It also sends Unity game states into Ink, such as NPC reputation, player inventory items, and story flags. At the same time, Ink tags can trigger behaviours in Unity, such as increasing reputation, giving items, consuming items, or setting flags. In this way, Dialogue is no longer just narrative presentation. It becomes a bridge between narrative content and game mechanics.
This process also made me realise that I underestimated the complexity of the dialogue system at the beginning. At first, I focused more on how to display text, progress the dialogue, and generate choice buttons. However, the truly difficult part was actually the interface between systems: how Ink reads the current game state, and how the player’s choices can reliably affect reputation, inventory, and story flags.
If I were to redesign this system, I would start with a much smaller gameplay loop first: one NPC, one Ink dialogue, one choice, one reputation change, and one consequence that the player can immediately see. This would allow us to test the relationship between dialogue and reputation much earlier, instead of trying to build an overly large system from the beginning. This is also one of the most important things I learned in the Mechanics Designer role: narrative mechanics need clear and testable system interfaces before they can truly become playable mechanics.
Leave a Reply