QORPOHow to test branching game dialogue in ink
Test branching dialogue in ink by recording which choices are visible before a decision, which state changes after it and what the player sees when they return. Start with a small set of cases that share a scene but enter it with different histories. That gives a writer and a programmer the same definition of what the branch is supposed to do.
Build cases around what the player knows
Inkle's Writing with Ink guide documents choices, variables and diverts. A variable can make a choice available after an event, and a divert can route separate branches to a common point. Use those tools to define what changes when a player learns a fact, spends something or comes back after an earlier choice.
Consider a model scene at a mountain shelter. A caretaker offers directions by default. Players who learned that the footbridge is closed can ask about another route. A choice to borrow a lantern opens a short response and rejoins the conversation. Write down the visible options for a first visit, a visit after hearing about the bridge and a return after borrowing the lantern. The table can be three lines in a review note. Each line needs enough detail that two people can independently tell whether it passed.
Check hidden choices as well as visible ones
Run the conversation as a player who never heard about the bridge. The bridge-related option should be absent. A stray line about the bridge in the default response can leak the same information even if the choice is correctly hidden, so check the spoken text as well. Next set the story state to the informed version and make sure the question appears at the right point. Check that choosing it reaches the response promised by the wording.
A useful expected result describes a specific moment. “At the first shelter menu, the alternate-route question is present only after the bridge conversation” is easier to test than “the branching works.” Use the same approach when drafting expected results for game fixtures.
Follow branches back into the shared scene
When two choices rejoin, look at the first common line. A player who refused the lantern should hear a line that makes sense without carrying it. A player who accepted it should see any relevant follow-up. If both branches deliberately receive the same farewell, read that line once in each state. Small assumptions in shared copy tend to show up here.
Check that each branch changes exactly the state it is meant to change. In the shelter example, choosing the alternate-route question should leave lantern ownership alone. Borrowing the lantern should not mark the bridge conversation as heard. If an assistant drafts variants, include these conditions with the task and compare its changes against the approved state names. The quest objective guide covers a related handoff between the player's instructions and game state.
Test the runtime handoff as a separate step
Run the scene in the writer's preview to check text and routing. Then run it through the game integration. The official ink repository documents the runtime interface for reading story output and selecting a choice. The game still owns how those choices are rendered, selected and restored within its interface.
In the integrated build, test keyboard or controller selection as applicable, and try leaving the conversation at a supported exit. If your game saves this state, save and reopen after borrowing the lantern. Check both story state and the game inventory. An integration can restore one and miss the other. If the game disallows saving inside conversations, test the point where saving is actually available.
What belongs in a review record?
Keep the starting state, choices made, expected visible options and the final visible result. Add the build or story revision so someone can rerun the case. For a failed case, include the earliest step where actual and expected diverged. In the shelter, that could be the choice appearing too soon, the loan flag firing twice or the wrong common line after the rejoin.
Use that record on the next revision when the writer changes a line, a programmer changes how variables synchronize or localization adds a longer option. A compact set of cases helps a team preserve good dialogue as it changes the scene. See the QORPO development blog for more production workflows.