Branching Dialogue Systems

Problem

Dialogue in games usually needs more than displaying a line of text. It has to change later content based on player choices, existing flags, and numeric state. If dialogue lines, branches, conditions, and variables are all embedded in scripts, maintenance, localization, and testing become harder to reason about.

How It Works

This skill models dialogue as a graph: nodes hold lines, choices, commands, or jumps; conditions gate options; and variables remember what the player has done. It helps choose between Ink, Yarn Spinner, and a custom JSON resource graph:

• Ink is author-oriented and fits dialogue-heavy or CYOA narratives.
• Yarn Spinner is node-based and fits game-driven logic with many engine hooks.
• A custom runner fits minimal-dependency or full-control scenarios. The goal is to build a graph, not to invent a scripting language.

The core steps are to define the node contract, separate variables from flow, localize from the start using line IDs and string tables, and drive the runner as a state machine in the game loop: current node, emit content, wait for input, advance branch, then validate that every path terminates correctly.

Boundaries

This skill does not render UI text boxes, portraits, or choice buttons, and it does not persist state across sessions. If dialogue state needs to be saved, pair it with save-systems; if dialogue data should live in Godot or Unity, use the relevant engine resource skills.