Branch coverage is not a single percentage with a universal meaning. A team might count passages visited, choices selected, conditions exercised or endings reached. Choose the unit before interpreting the result.
Separate the graph from its conditions
Begin with a structural graph: scenes or passages are nodes, and possible transitions are edges. This exposes missing destinations, isolated passages and unexpected cycles. Then annotate the edges with their guards and effects. A line on the graph becomes a possible player transition only when the relevant conditions can hold at that point.
Our key example gives Mara ownership after the transfer. Suppose the gate branch requires both Mara's ownership and a flag meaning the player has never transferred the key. Under the current rules, those requirements conflict. But if another character can give Mara a duplicate, the contradiction may disappear. The model must include those alternative actions before a strong conclusion is justified.
Define the starting world
Record the initial state, available chapter entry points and supported imported saves. A passage unreachable from a new game may be reachable from a legitimate later checkpoint. A debug jump is useful for inspecting a scene but is not evidence that a player can reach it through normal play.
Version the starting assumptions alongside the test. Difficulty settings, downloadable content and character selection may alter the graph. Avoid pooling traces from different configurations into one apparently comprehensive coverage figure. State which configuration each result describes.
Illustrative route A: give Mara the key
Start with key_owner=player. Select give_key. Confirm key_owner=Mara. Attempt the north-gate transition and record each evaluated guard. This route tests whether the handover unlocks the intended scene.
Illustrative route B: keep the key
Leave key_owner=player. Visit the same gate. Confirm the alternative line or blocked transition matches the design. This is a separate test, not proof supplied by route A.
Search with explicit limits
A breadth-first search can explore a finite state model, storing each relevant state and available action. The difficulty lies in deciding which states are equivalent. Two visits to the courtyard may look identical but differ in a hidden promise flag that changes a later scene. Collapsing them too aggressively creates misleading coverage.
Loops, timers, random events and unbounded counters can make exhaustive exploration impractical. Set a depth, time or state-count bound and publish it with the result. “No route found within this model and bound” is accurate. “This scene is impossible” requires a stronger argument about the complete model.
Use constraint tools where the model supports them
A solver such as Z3 can check whether encoded conditions are jointly satisfiable. It can be valuable when a branch depends on many flags. It cannot discover omitted rules or know whether your encoding matches the game. A satisfiable condition also does not automatically provide a valid sequence of actions from the starting state.
Alloy offers another way to explore bounded relational models. The TLA+ ecosystem supports reasoning about state transitions. These are general modelling tools, not turnkey narrative validators. Integration effort and modelling skill determine whether they are appropriate for a project.
Give AI a narrow assignment
A model can suggest unusual choice combinations, explain complex guards in plain language or draft a list of boundary cases. Ask it to cite the exact conditions behind each proposed route. Then run those routes in a harness or the game. A fluent route description may contain an unavailable choice or quietly skip a required scene.
Use generated routes as test candidates. Keep actual execution logs distinct from proposed paths. If the model predicts a route that fails, preserve that failure as evidence about the route or model, not automatic evidence that the game is broken.
Measure what was exercised
Useful reporting distinguishes structural node coverage, traversed edges and condition outcomes. Visiting a passage once does not test every line inside it. Choosing both visible options does not necessarily exercise every hidden guard. An ending can be reached while important intermediate states remain unexplored.
| Measure | What it establishes | What it does not establish |
|---|---|---|
| Passage visited | A trace entered the passage | Every conditional line ran |
| Edge traversed | A transition occurred | All enabling states work |
| Guard outcomes | Observed true and false evaluations | Every combination is valid |
Finish with a player-relevant explanation
For a blocked branch, describe what the player loses: an intended quest resolution, a required item or an optional conversation. Include the guard trace and the smallest known setup. Ask design whether the scene is obsolete before labelling unused material a defect. Deliberately retired passages and future content should not inflate the issue queue.
Finally, rerun neighbouring routes after a fix. Relaxing one condition may restore the missing scene while allowing it too early. Reachability and continuity are linked: the right scene must be available in the right state, not merely reachable somehow.