Branching dialogue without an unmanageable tree
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.
A caretaker conversation, worked through
Here is a small invented conversation you can implement on paper. The caretaker has a key. The player can ask directly, offer to help with a shelf, or ask about another entrance. This is a proposed design and a manual trace of its rules, not a report of player research.
Which branches can meet again?
All three replies can lead back to a shared question: “Anything else before you go?” The shared line does not erase what happened. Asking directly reveals that the key is unavailable until the shelf is repaired. Offering help accepts that task. Asking about the building reveals a side entrance. Those are different pieces of information even though the conversation returns to one place.
Give the common hub a limited job: show the choices that still make sense. Do not copy the entire ending underneath every reply. If a new line needs to appear after every route, a shared hub gives you one place to change it. A branch that truly changes the scene can still leave the hub.
What must the conversation remember?
For this version, record three true-or-false facts: help_accepted, shelf_repaired and key_received. Start all three as false. The separate “ask about the building” reply can reveal the side entrance in its text; if later scenes need to react to that knowledge, add a dedicated fact then. Do not introduce a variable merely because a sentence exists.
Offering help sets help_accepted to true. Completing the shelf task outside the conversation sets shelf_repaired to true; this prototype permits that task only after help is accepted. The key choice is visible only when the shelf is repaired and the key has not been received. Choosing it grants the key and sets key_received to true as one action.
That last condition matters. Checking only “shelf repaired” would leave the reward available on every return. In the proposed rules, once the key has been received, the caretaker acknowledges it and offers no second key. The three flags are part of the paper model, not instructions for a particular story engine.
How do I test the joins and repeat visits?
Use a route list, not just a read-through of the most cooperative path. The rows below are expected results derived from the stated rules. Mark an actual pass only after following the route in your current prototype.
| Route | Expected result |
|---|---|
| Ask directly, then return | No key; the shelf condition remains. Re-entering the hub does not complete a task. |
| Offer help, leave, return without repair | Task accepted; no key yet. The reply acknowledges the pending repair. |
| Offer help, repair, return, receive key | All three facts become true in that order; the key is granted once. |
| Return again after receiving the key | The grant choice is absent; acknowledgement replaces it. |
| Ask about the building, then offer help | The alternative route information does not block the shelf task. |
Also try restoring or restarting the prototype. Decide whether the facts reset or persist, then test that decision rather than assuming it. If you manually force an impossible state such as “key received, shelf not repaired”, record it as a debugging setup, separate from a route a player can take under these rules.
Once the state trace works, read each join aloud and ask someone to try the conversation. Correct logic alone does not establish that the choices are clear or the writing feels natural. Keep observed actions separate from explanations using the test-bench protocol, and put the route list beside your next playable build.