Writing Branching Dialogue for Games Without Losing Control

Every branching conversation starts out simple. A character asks a question, the player has three answers, and each answer gets a reply. Then each reply needs its own answers, and a companion has an opinion. A few weeks later you have a tree nobody can read, lines that contradict each other, and a bug report saying the blacksmith thanked the player for saving a village they burned down.

Branching dialogue is less about writing many lines and more about deciding where the story may split and where it must come back together. Here are the structures, state tracking and writing habits that keep a tree under control.

Why trees explode

If every choice leads to a unique continuation, the number of paths multiplies at every step. Three choices, three levels deep, is already 27 endings to one conversation. Nobody writes, records or tests that.

The fix is not fewer choices. It is structure: letting branches diverge briefly and then merge, and storing the consequences of a choice as state instead of as a separate copy of the rest of the conversation.

Three structures that scale

Branch and bottleneck

The conversation splits, each branch plays out for a few exchanges, and then all branches return to a shared node. The player gets a real reaction to their choice, and you only have to write one version of what comes after.

The bottleneck is where the scene's essential information lives. Anything the player must hear to continue the quest goes after the merge point, never inside a branch they might skip.

Hub and spoke

A central node offers several topics. The player picks one, hears it out, and returns to the hub. Topics they have exhausted disappear or change label. A final option leaves the conversation.

Hubs suit investigation, shopkeepers and companions at camp. The risk is that the hub becomes a menu and the character stops feeling like a person. Vary the hub line ("Anything else?" becomes "You're still here?" after the third topic) and let some spokes end with the character steering the talk back to what they want.

Gated choices

Some options only appear, or only succeed, when a condition is true: a skill check, an item in the inventory, a relationship value, a quest stage. Gates let the tree respond to the player's build and history without adding new top-level branches. Decide early whether locked options are hidden or shown greyed out. Showing them hints at depth the current character cannot reach; hiding them keeps the screen clean. Either works if you are consistent.

State flags and variables

The real memory of a branching game lives in its variables, not in its tree. A choice sets a flag, and that flag is read later by other conversations, quest scripts and world events.

Keep the state model small and deliberate:

• Boolean flags for facts: met_harlan, harlan_knows_about_ledger.
• Integers for relationships or counters: harlan_trust, bribes_paid.
• Enums or quest stages for anything with more than two states: ledger_quest = not_started | active | returned | burned.

Name flags by what happened in the world, not by which line set them. told_harlan_truth is more useful than choice_3b, because someone writing a scene six months later can understand it without opening your tree.

Keep a shared list of every flag, what sets it and what reads it. When a flag is set but never read, you have a choice with no consequence. When a flag is read but never set, you have a bug.

A small dialogue tree sample

Here is a short conversation with an invented smuggler, Harlan, written in a plain node format. Each node has an ID, a speaker, optional conditions and optional effects.

[HARL_010] HARLAN
  "You're the one asking about the ledger. Sit."
  -> HARL_020

[HARL_020] PLAYER CHOICES
  1. "I'm here to buy it."            -> HARL_030
  2. "Your partner sent me."          -> HARL_040
     condition: met_vessa == true
  3. [Intimidate] "Hand it over."     -> HARL_050
     condition: strength >= 6
  4. "Never mind."                    -> HARL_END

[HARL_030] HARLAN
  "Everyone wants to buy it. Nobody can afford it."
  set: harlan_trust -= 1
  -> HARL_060

[HARL_040] HARLAN
  "Vessa? Then she's still breathing. Good."
  set: harlan_trust += 2
  set: harlan_knows_vessa_alive = true
  -> HARL_060

[HARL_050] HARLAN
  "Easy. I didn't say no. I said sit."
  set: harlan_afraid = true
  -> HARL_060

[HARL_060] HARLAN   (bottleneck)
  "The ledger's at the customs house. Third drawer. Locked."
  set: ledger_quest = active
  -> HARL_070

[HARL_070] HARLAN
  if harlan_trust >= 1: "Bring Vessa next time."
  if harlan_afraid:     "And don't come back."
  else:                 "We're done."
  -> HARL_END

Three approaches, one shared bottleneck with the quest information, and a closing line that remembers how the player behaved.

Meaningful choices and flavor choices

Not every choice needs to change the plot. Many of the best choices in games change only tone: the player picks whether their character is dry, warm or blunt, and the other character reacts in the moment. These flavor choices are cheap because they merge immediately.

Meaningful choices change state that something else reads later. They cost more to write and test, so spend them where they matter: at the end of a quest, at a relationship turning point, at a moral decision the game will remember.

Problems start when the two are confused: a weighty-looking choice that changes nothing feels like a cheat, and a casual-looking one that locks out a companion feels like an ambush. Signal weight through the writing itself: a meaningful choice should be framed by stakes the character states out loud.

Reactivity and callbacks

Players notice when the world remembers. A callback is a line that references an earlier choice: the guard who mentions the player let a thief go, the companion who brings up the lie told in chapter one.

Callbacks are among the cheapest forms of reactivity because they are usually one conditional line inside an otherwise shared conversation. A good habit is to write the default line first, then add one or two conditional variants keyed to the flags that matter most. If every line has six variants, you are back to an explosion.

Barks

Barks are short, often unprompted lines: combat callouts, ambient comments, reactions to the player walking past. They carry a surprising amount of characterization and reactivity because players hear them constantly. Write them in sets with variants so they do not repeat in an irritating loop, and tag them with conditions just like dialogue nodes ("low health", "after the bridge collapses", "if the player is wearing the guard uniform").

Voice and character consistency

When a tree is written over months, sometimes by several writers, voice drifts. A character who speaks in clipped sentences in one branch starts giving speeches in another.

Keep a one-page voice sheet for each major character: vocabulary they use and avoid, sentence length, what they never talk about, how they address the player at different trust levels. Read a character's lines in isolation, outside the tree, before you ship a build. The same principles that make prose dialogue sound natural apply here, and the techniques for writing realistic dialogue translate well to game scenes.

Writing choice labels that match the spoken line

The player chooses from a short label, and then their character speaks a full line. If the label says "Be polite" and the character says something sarcastic, the player feels the game took control away from them.

A few rules of thumb:

• The label should predict the intent and tone of the full line. If the spoken line is a threat, the label should read like one.
• Keep labels short and parallel in form so the player can compare options at a glance.
• Avoid paraphrases so loose that the full line surprises the player.
• Mark special options consistently, such as skill checks in brackets, so players learn the convention once.

Line IDs and localization-friendly writing

Every spoken line needs a stable ID, like HARL_040 above. IDs let voice directors schedule recording, let translators track context and let programmers hook lines to animation and audio. Do not renumber IDs when you insert lines. Use gaps (010, 020, 030) so new nodes can slot in without breaking references.

Writing for localization also means:

• Avoid building sentences from fragments at runtime ("You have " + count + " coins"). Word order differs between languages, and grammar may need to change with the number.
• Keep jokes and wordplay in places where a translator can rewrite them freely, and add a note explaining the intent.
• Write context notes for ambiguous lines: who is speaking to whom, the emotional state and whether the line is sarcastic.
• Avoid gendered assumptions in lines that play for any player character unless the system supports variants.

Testing every path

You cannot read a branching conversation the way you read a scene. You have to walk it.

1. Trace every route by hand at least once, noting which flags are set at the end of each.
2. Check every condition both true and false. A gate that is never true is a dead branch.
3. Check bottlenecks for information that only one branch delivered. If the merged line says "as I told you", make sure every route told them.
4. Check callbacks against routes where the earlier event never happened.
5. Read each character's full line list in order to catch voice drift.

A visual map of the conversation helps a lot here. Seeing merges and dead ends as shapes is faster than following arrows in text, which is the same reason story diagrams help with plot structure in linear projects.

Doing this in Aevon

Aevon's Game Studio keeps branching dialogue trees next to the rest of your game's narrative: the design document, quests and levels all sit in the same project. You can write each conversation as a branching dialogue tree and keep the quest that a dialogue starts right beside it, which makes it easier to check that the bottleneck line delivers what the quest needs.

Characters, locations, items and lore live in the same project, and the manuscript editor's @mentions link a character to their entries, so the voice sheet and backstory for Harlan are a click away while you write his lines. The floating Ideas and Notes panel stays open across sections, handy for a running list of flags.

Story diagrams are available in every project type, so you can map how conversations and quests connect across the whole game. If you work with other writers, roles (owner, editor, viewer) and change approval let a lead narrative designer review edits to a tree before they land, which helps keep voice consistent. When dialogue feeds into larger mission structures, the companion guide on quest design for narrative designers covers how to plan the quests themselves. You can try the Game Studio for free in the web app or the desktop apps.

Further reading

• Quest design for narrative designers: goals, stakes and structure
• How to write realistic dialogue
• Story diagrams and plot structures compared
• Game Studio for game narrative and dialogue