Fugue Devlog 3: Dialogue Editor and Manager

Dialogue is a key part to Fugue, so I'm taking care to design those systems well from the start. The challenge is trying to imagine all the potential scenarios I might want to play out with the dialogue system beforehand. I'm probably going to get it wrong but I tried my best to design for maximum flexibility/minimum regret.

There are three main pieces that go into the system:

• The schema: how is the data that describes a dialogue/conversation encounter (a "script") structured?
• The editor: if I'm going to be writing and tweaking a lot of these scripts, I need a tool that's robust, quick, and intuitive.
• The manager: the system that handles running scripts in the game, e.g. figuring out where/how to render the text, handle choice selection, etc.

But first, what features am I looking for in a dialogue system?

• Branching and dynamic dialogue: choices in dialogue and factors outside that specific encounter influence the course of a conversation.
  • Choices that depend on other variables (either hidden or shown but not selectable until the criteria is met)
  • Variable substitution
  • Pick up at different points depending on previous conversations
  • Circular conversations (e.g. that let you return to a menu of questions to ask someone)
  • Time-limited decisions, especially because managing time will be an important part of the game
• Rich formatting: colors, bold, italic, and whatever else I can get
• Entity agnostic: Conversations can be had with both objects and NPCs (without needing to classify objects as NPCs or anything hacky like that)
• Flexible in triggering: A conversation can be triggered by player choice (e.g. approaching an object/NPC and interacting), by entering the proximity of something, or after some other action is taken
• Integrate into broader scenes: triggering other actions/animations and events, capture the cadence and rhythm of a conversation with pauses (delays and timeouts) and by revealing the text over time (the "typing" effect)
• Feels well integrated into the surrounding ambient environment: less "we are locked into having a conversation now"
• Handle multiple simultaneous speakers: For example, to convey the feeling of everyone talking over each other in a large group

In terms of developing the game and editing dialogue, there are a couple other quality-of-life features, like making it easy to attach a script to an object, NPC, or trigger area and supporting validation/tests to minimize bugs.

The script schema

This is the schema that's currently in place.

A dialogue script has two top-level keys:

• root: The root note that determines how the dialogue starts. It's just an array of "Outcomes" (see below)
• events: An array of "Events", which are the basic unit of a dialogue script. This is a flat array, though represents and is parsed into a graph.

An "Event" has the following structure:

• id: Used to keep track of event relationships. Only needs to be unique to its parent dialogue.
• type: There are two types of Events:
  • thought: An internal dialogue statement, italicized, and has no associated speaker
  • verse: A spoken dialogue statement, spoken by a speaker
• text: The actual statement that's shown. Can use BBCode, which means colors and other styles can be applied.
• speaker: An optional speaker name to show with the rendered text.
• delay: Optional delay in seconds before the next event is rendered. For pacing a conversation.
• timeout: Optional timeout in seconds the player has to make a choice or to auto-progress the dialogue. If there are choices, letting the time run out is a "null" choice.
• signal: Optional signal name (signals are Godot's way of having nodes communicate with each other without direct references) to emit when this event starts. This can be used to trigger things like other actions/animations in the environment (I think, I haven't tested it yet).
• outcomes: An array of "Outcomes". An Outcome is a link to another Event, with zero or more conditions attached to it.
  • The order of the array matters. Outcomes have their conditions evaluated in the array order; the first to evaluate to true (or to have no conditions) is selected as the next Event.
  • An Outcome with no conditions is the "default" Outcome; there can be only one.
  • An Outcome has:
    • ids: The next events to load if this Outcome is selected. Something I'm thinking through now is whether this should only be a single id or multiple ids (the current implementation); the relevance is for the simultaneous speakers feature. Not sure how to do that yet without making the progression of the conversation hard to anticipate.
    • conditions: An array of Conditions that must evaluate to true for the Outcome to be selected
• choices: An array of "Choices". When selected a Choice sets a local variable called choice; Outcomes can condition on this variable (i.e. a Choice can lead to a specific Outcome but more complex behaviors are also supported). A choice consists of:
  • id: This is what the choice variable is set to if the Choice is selected
  • required: An array of Conditions that have to be satisfied for this Choice to be selectable
  • show_required: An array of Conditions that have to be satisfied for this Choice to be visible (e.g. for secret choices)
  • text: The text displayed for the Choice. Supports BBCode, so colors and other styles can be applied.

The other piece are Conditions, which have the following recursive schema broken into two types:

• Comparison:
  • variable: The variable name for the left side of the comparison
  • value: The value or variable name for the right side of the comparison
  • type: Indicates if value is a "value" or a "variable"
  • comparator: One of ==, !=, <, <=, >, >=, for comparing the left and right sides
• JointComparison:
  • op: An and or or operation
  • a: A Condition
  • b: Another Condition

Thus JointComparisons can contain more JointComparisons and so on.

The dialogue editor

I shouldn't be editing dialogue scripts by hand but through an editor that keeps things valid where possible. This is implemented as a "main screen" EditorPlugin for Godot using its built-in GraphEdit node and other UI elements. I was surprised at how much can be done with just the built-in components, though it was a struggle at times. I learned a lot in the process but some of Godot's UI behavior is unusual coming from frontend web development.

An additional feature is a validator. It runs through the script and identifies common errors, checking that:

• In the script root:
  • There's one default entrypoint. That is, the script has to have some default starting event.
  • Each entrypoint is connected to an event.
  • Each entrypoint eventually leads to a terminal event (i.e. no conversations that loop forever).
• For all Conditions:
  • All values and variables are defined.
  • All variables reference existing global state variables or choice.
• For each Event:
  • The text is not empty.
  • Must have a parent (which can be the root).
  • Each Outcome must be connected to another event.
  • Has one default Outcome.
  • Has one default Choice, if it has any Choices.

There are some other small quality-of-life features, like highlighting all events a given event is connected to. The editor will also automatically layout nodes, but it's not very good at the moment. It also gets very dense, very quickly given how many properties there are for an events. I want to figure out how to make that representation more compact and support faster free-flow writing.

The dialogue manager

The dialogue manager is what reads a dialogue script and plays it out in-game. So it needs to render and position the text, render the choices and handle their interactions, etc. So far it's relatively simple (if the schema does its job well, the dialogue manager shouldn't have to do much). But it will probably get more complicated with more advanced features like speaker position tracking, simultaneous dialogue, and ambient dialogue.

I won't have any voice acting (bad voice acting is worse than no voice acting!) but I want the talking that does happen to still feel like ambient sound and conversation. This video on game design that accommodates for deaf people or people with hearing difficulties mentions sound cue indicators that can be enabled in Fortnite:

Sound cues won't be important in Fugue, but maybe something like this can give a sense of ambient snippets of conversation happening around you. In general I want conversations to feel less like you're fixed in a place with a big block of text at the bottom of the screen and more weaved into the environment, which I think this helps with.

I need to implement and experiment with this kind of approach. It might get way too cluttered or be otherwise overwhelming. One way I could approach that is not showing snippets of speech as the visual cue except when you're close enough where you'd be able to make out what they're saying. At further distances I could group further conversations away into a more abstract representation of speech happening off-screen.

Next steps

Working out and implementing the rest of the dialogue system is enough to keep me occupied for awhile. Figuring out the ambient dialogue system, a better way to do simultaneous dialogue, and dynamically positioning dialogue boxes based on the speaker position are the next challenges. Then testing everything, fixing any issues, and feeling confident in its robustness and expressiveness.

After that, I want to try building an exterior environment and work on player movement/scene transitions.

Bigger tasks off the top of my head: an inventory system and building out more object interaction, then thinking through some of the more specialized systems. Right now that includes: a card game, a legal system, and character ability puzzles. But what of those remain and what they ultimately need to do depends on figuring out the rest of the world and story in more detail.