Writing Branching Dialogue Trees Without Losing Narrative

Three options, each with three follow-ups, each with three more. That’s twenty-seven states four beats into a single conversation, and it’s why every guide to branching dialogue arrives at the same advice: converge.

Converging is correct and it isn’t the craft. It’s a scope decision, and it’s the reason players complain that their choices don’t matter - not because the branches rejoined, but because the writing let them notice.

Here’s the shift that fixes more problems than any structural pattern.

No player ever experiences the tree. They experience one path through it. The tree is a production artefact. The path is the product. Which means a structurally elegant tree that produces paths reading like a machine assembled them is a failed tree, and a crude one that produces paths reading as authored is a good one.

Design the tree. Audit the paths.

For the discipline around it, start with our video game writer’s handbook.

What is a dialogue tree?

A dialogue tree is a branching conversation structure in which player choices at each node determine which lines follow, typically implemented as nodes connected by conditional edges. Nodes hold content, edges hold conditions, and the whole structure is usually authored in a dialogue editor or database rather than a document.

Branching dialogue is the wider term and covers structures that aren’t strictly trees - including systems where topics unlock and lock based on world state rather than on a fixed hierarchy.

Structure and consequence are different problems

Worth separating up front, because they get conflated and they have different fixes.

Structure is what this article covers: how branches are built, how they reconverge, how a line reads naturally after several different inputs, how you stop the content doubling every turn.

Consequence is whether a choice changes anything - tracked state, downstream payoff, endings. That’s a design question about what the game remembers, and it’s covered in Writing for Player Agency: Choice, Consequence, and Meaningful Endings.

A perfectly built tree can deliver choices that change nothing. A structurally crude one can deliver choices that reshape the game. They’re independent, and confusing them is why “make choices matter” gets offered as advice to writers who have a branching problem.

Six structures worth knowing by name

Most writing on this topic names two. There are at least six in common use, and picking the right one is most of the scope battle.

Hub and spoke is the most used and the most criticised. It reads as a menu, because it is one - the player exhausts options with no pressure and no cost. It’s fine for a merchant and deadly for a confrontation. The cheap fix is to make options disappear once used, or to put a cost on staying.

The gauntlet is underrated. One line of content, three ways for the player to say it. No branching cost at all, and it delivers the thing players actually want most of the time: the ability to express who their character is.

The diamond carries most dramatic scenes, and the whole craft is in the reconvergence line.

The open state machine is what the best conversation systems really are - not trees but sets of available topics governed by conditions. It’s expensive, and it’s why the conversations in games people praise for dialogue feel unlike menus.

What a choice actually selects

Players talk about choice as one thing. It’s four, and they cost wildly different amounts.

1. Content - which information you receive. Cheap. Usually hub-and-spoke.

2. Tone - how your character is characterised. Nearly free. This is what a dialogue wheel with aggressive, neutral and diplomatic options is really selling.

3. Relationship - how an NPC now regards you. Cheap to record, cheap to reference later.

4. Outcome - what actually happens in the world. Expensive.

Here’s the useful part: most player complaints about “fake choices” aren’t about the fourth. They’re about the second and third going unacknowledged. A player who chose the cruel option and gets a response identical to the kind one hasn’t lost an outcome - they’ve lost the characterisation they were trying to perform, which is what they were choosing for.

And acknowledgment is nearly free. One clause registering how the player spoke, before the conversation converges, buys most of the perceived agency at a fraction of the branching cost.

Why choices feel fake

Not convergence. Visible convergence.

Players accept branch collapse constantly and without complaint. What breaks the illusion is a response that could not plausibly have followed what they just said.

PLAYER  A: "I'll help you. Whatever it takes."
PLAYER  B: "I'm not doing this for free."
PLAYER  C: "Say another word and I'll leave you here."

NPC  →  "Good. Meet me at the docks at midnight."   ← the tell

That NPC line is a perfectly serviceable plot beat and it is a perfectly serviceable proof that nothing the player said registered. The fix isn’t three separate branches. It’s one extra clause per option, or one line before the convergence that acknowledges the register.

The rule: converge on content, never on tone. The plot beat can be identical. The acknowledgment shouldn’t be.

Writing the convergent line

The specific craft skill, and the one that separates competent branching from good branching.

You need a line that reads naturally after three or four different inputs. Five techniques do most of the work.

Respond to the topic, not the phrasing. All three player options above are about whether they’ll help. A line responding to the subject rather than the wording fits all three.

Give the NPC their own agenda. A character pursuing something doesn’t fully process what you said - they redirect to what they want. This is the single most useful trick in branching dialogue, because it makes convergence characterful rather than mechanical.

Delay by one beat. Acknowledge in the first clause, converge in the second. “Suit yourself. Docks, midnight.”

Make the NPC someone who doesn’t listen carefully. A distracted, arrogant or frightened character justifies loose responses permanently. Casting a scene with a poor listener is a legitimate structural decision.

Use the environment to interrupt. Something happens, the conversation moves. Expensive to overuse and reliable when the scene needs to reconverge hard.

What doesn’t work: writing a line so vague it fits everything. Players read that as evasion by the writer, and it drains the scene rather than saving it.

Containing the explosion

Practical techniques, in rough order of how much they save.

Set a flag instead of branching. The most valuable habit in the discipline. When a player makes a choice, record it and continue on one path. Reference the flag later - one line, one condition, huge perceived reactivity, near-zero structural cost.

Reconverge inside the scene, not across scenes. Branches that survive a scene boundary multiply everything downstream. Branches that close before the scene ends cost only what’s inside them.

Cap depth at three. Rarely go more than three nodes deep before a bottleneck. Beyond that, authoring and testing costs rise faster than the player notices the difference.

Don’t branch on information the player will get anyway. If every path eventually reveals the same fact, you’ve paid for a branch and bought sequencing.

Branch on stance, not on fact. Facts converge cleanly. Positions are what players want to choose and what’s cheap to record.

Gate rather than branch. An option that only appears under a condition - a skill, an item, prior knowledge - creates variation between playthroughs without multiplying the tree.

Prototype before you author. Testing a structure playable is faster than reasoning about it on paper, and it’s what prototyping tools exist for - Twine and Ink: Prototyping Branching Narratives covers those.

Testing: walk paths, not diagrams

Because the player experiences a path, the diagram will lie to you.

Walk every terminal. Not every combination - every ending state of the conversation, arrived at from at least one route.

Read each path aloud as a continuous scene. With no menus, no node names, no structure visible. This is the single most effective test available and almost nobody does it. A path that reads as a scene works; a path that reads as a form being filled in doesn’t, and you’ll hear the difference immediately.

Test the extreme paths. The most aggressive route through and the most passive one. Middle paths tend to work by accident; the poles expose the convergence.

Test out of order. Reach the conversation having done things in an unexpected sequence, and check nothing assumes knowledge the player might not have. Order-independence is the constraint that catches writers arriving from linear media.

Track coverage. In a large game, knowing which nodes have never been walked in testing is a real production concern, and it usually lives in a spreadsheet.

Where trees go wrong

Menu syndrome. Hub and spoke used for a scene that needed pressure. Nothing is at stake because nothing closes.

Convergence on tone. Identical response to opposite inputs.

Depth without payoff. Six levels of branching that reconverge to the same place. Cost paid, nothing bought.

Branching on facts. Multiple paths to the same information.

The vague pivot line. A convergence line written so loosely it fits any input and satisfies none.

Unwalked paths. Content that ships untested because the tree grew past what anyone verified.

No flags. Everything handled by branching, so the tree carries state that a variable should be carrying.

Assumed order. A line that only makes sense if the player did things in the sequence you imagined.

Keeping the graph and the lines together

Branching work has an awkward shape: the structure is a graph and the text is a document, and they usually live in different applications. You reason about the tree in a diagramming tool, write the lines somewhere else, and the two versions diverge from the first week - which is how unwalked paths and stale conditions get into a build.

Skrib narrows that gap. The Plan gives a conversation room to spread out as connected cards - nodes, conditions, which flags each one sets - while you draft the lines beside it rather than in another window. Dialogue tables move in and out as .csv and .xlsx, matching how production text actually travels, and the Library keeps every version searchable when a scene gets rebuilt three times.

Being precise about the boundary: Skrib doesn’t compile, branch or run anything. It won’t validate your conditions or catch an unreachable node, and it isn’t a replacement for Twine, Ink or your studio’s dialogue editor. It’s the thinking-and-writing layer that sits before them. You can start free.

Frequently asked questions

What is a dialogue tree in a video game? A branching conversation structure where player choices determine which lines follow, built from nodes holding content and edges holding conditions. Broader branching systems don’t always form strict trees - some use topics that unlock and lock based on world state instead.

How do you stop branching dialogue from exploding in scope? Set flags instead of branching wherever possible, reconverge within the scene rather than across scenes, cap depth at around three nodes before a bottleneck, and branch on the player’s stance rather than on facts they’ll receive anyway.

Why do players say their dialogue choices don’t matter? Usually because the response doesn’t acknowledge how they spoke, not because the branches rejoined. Convergence is accepted constantly; visible convergence isn’t. Converge on content, never on tone - one clause registering the player’s register recovers most of the perceived agency.

How do you write a line that works after several different choices? Respond to the topic rather than the phrasing, give the NPC their own agenda so they redirect rather than reply precisely, or cast the scene with a character who genuinely doesn’t listen carefully. Writing a line vague enough to fit everything reads as evasion and makes the scene worse.

How do you test a dialogue tree? Walk every terminal state and read each path aloud as a continuous scene with the structure hidden. A path that reads like a scene works; one that reads like a form being filled in doesn’t, and the difference is audible immediately.

How deep should a dialogue tree go? Rarely more than three nodes before reconverging. Past that, authoring and testing costs climb faster than players register the additional depth, and unwalked paths start reaching the build.