Skip navigation
DRAGONCLAW / FIELD NOTEINDEX [←]

Branching dialogue without an unmanageable tree

FILED 2026.10.14Dragonclaw field notes

A branching conversation can become difficult to manage long before it becomes interesting to read. Every new branch creates text to write, conditions to test and paths a player might never see. For a small project, start with a conversation that changes one relationship or reveals one piece of information.

Give the conversation a purpose

Imagine a caretaker deciding whether to lend the player a key. The player can be direct, offer help or ask about the building. Each option should communicate a different intention. Three differently worded versions of “give me the key” do not necessarily create three meaningful choices.

Write the opening and the possible outcomes first. Perhaps the player receives the key, learns where another entrance is, or leaves with a task to complete. Keep the number of outcomes small enough that each can affect the next scene.

Let branches meet again

Separate responses can return to a shared point while preserving a small piece of state. The caretaker might remember that the player offered help, even if all paths eventually reveal the same destination. The later response should acknowledge the choice in a way the player can understand.

Avoid promising a large consequence that never appears. A modest, visible reaction is often more satisfying than a dramatic choice screen followed by identical behaviour. If the choice is primarily expressive, let the writing support that role rather than pretending it changes the entire world.

Track state in plain language

Before implementing variables, make a small table of facts: has the player offered help, received the key or heard the warning? Describe when each fact changes and which lines depend on it. Distinguish facts from temporary presentation details.

Walk through the conversation using that table. Test unusual orders, such as returning after finding the alternative entrance. Look for repeated rewards, references to events that have not happened and options that remain visible after they no longer make sense.

Read every route aloud

Follow one path at a time and listen for abrupt changes in tone. A line that works beautifully in isolation may not follow naturally from all the routes that reach it. Adjust the shared line or split it only where the difference matters.

Keep a simple route checklist beside the script. Mark the paths you have tested in the current build, not just those you remember testing before the last edit. A small conversation feels intentional when its choices, memory and consequences agree with one another.

For an implementation exercise, inkle’s official introduction to writing web stories with ink provides a way to try interactive text. The planning method here does not require that tool.

END OF NOTEBack to the top ↑