Path tester

The Path Tester runs many random walks through your project and reports back on what it found: which nodes never got visited, which choices led to a dead end, which variable conditions never fired. Reach for it when you want coverage numbers or a list of structural problems, not when you want to click through one path yourself.

What’s not here: the Simulator is what you use to drive a single playthrough by hand (simulator). Static analysis without any simulated play lives on validation (structural errors and expression problems) and tests (writer-authored scenarios against specific expressions).

The tab in one shot

  1. Scope picks where the run starts. See start a run.
  2. Paths, Seed, Strategy, Locale control how the walks are generated. See start a run.
  3. Run kicks off N walks at the given seed and returns when they finish.
  4. Summary line reports how many walks completed, coverage percentage, and duration bounds.
  5. Issues list is where structural findings surface, grouped and sorted by severity.

Start a run

Scope

Four values, each starting the walk from a different point:

  • Active scene starts every walk at the scene currently open in Node Graph.
  • Pick scene lets you choose a starting scene from the picker.
  • All scenes runs walks from every scene in the project and reports per-scene results.
  • Full project starts at the project entry scene and follows the world layer through scene transitions. This is the mode that matches how a shipped project plays.

The fixture on this page has a single scene, so Active scene and Full project produce the same walks but present the results in different shapes: Active scene gives you a per-scene issues list with an expanded Coverage Heatmap; Full project adds a Project Run block at the top with aggregated coverage across the world layer.

Paths and Seed

Paths is the number of walks the tester runs. Every walk starts fresh and makes independent choices, so more paths give a wider sample.

Seed makes the run reproducible. The same seed at the same path count against the same project produces the same walks every time, which is what you want when you’re comparing two runs across an edit.

Practical numbers: 100 paths for quick iteration between edits, 500 to 1000 before you consider a section ready to ship, 5000 or more for a whole-project sweep before a milestone.

Strategy

Four choices, each biasing what the walks pick when a node has multiple visible children:

  • Random picks uniformly. Best default. Coverage plateaus quickly and unusual paths surface early.
  • Defaults always picks the first visible child, which verifies the golden path completes without surprises.
  • Coverage-guided biases toward nodes with fewer prior visits, so it reaches rare branches faster than Random, at the cost of walks that no longer reflect how players actually pick.
  • Greedy goal-seeking aims at a specific target you pick, either a scene to reach or a variable expression to satisfy. Adds a target picker below the Strategy control.

Locale

Rerun the tester in a different locale to surface untranslated strings and locale-specific evaluator issues. Leave the picker on Source to run in the project’s authoring locale.

Read the results

The summary line

After a run, the summary line reports paths completed, coverage percentage, and duration bounds. “Completed” means the walk reached a Complete Project event, not that it stopped somewhere. A walk that runs into a dead end or a max-steps limit counts against your total but not against the completed number. Coverage percentage is the fraction of player-facing nodes that at least one walk visited; the numerator in parentheses is the raw visited-over-total count. Duration bounds show the shortest and longest observed walk in playing time, along with the average.

The issues list

  1. Issue label names the issue type; its color signals severity. Red is a correctness problem, amber is an author-hygiene warning.
  2. Count badge and expand indicator report how many walks reproduced the issue and toggle the details drawer.
  3. Shortest Path is the shortest observed sequence that reproduced the issue, from run start to the failing node.
  4. Jump-to-node arrow takes you to that node in Node Graph so you can fix what’s wrong.

Writer-relevant issue types you’ll see most:

  • Dead End fires when a walk runs out of anything to do (no visible choices, no world moves) without a Complete Scene or Complete Project event firing. Fix is usually a missing follow-up node, or an On exhausted node on the scene that chains forward to a completion event.
  • Unreachable fires when a node was never visited across all walks. Might be a legitimate deep branch behind unlikely variable state, or a node whose incoming path got severed by an edit somewhere upstream.
  • Infinite Loop fires when a walk got stuck cycling and hit the max-step limit. Almost always a jump that returns you to a node whose choices haven’t changed.
  • Unassigned Media and Unused Media flag Play Sequence events pointing at nothing, or media entries you defined but never played.
  • Unused Event flags events attached to a node whose condition never evaluated true. Common causes: a leftover condition after a rewrite, or a variable that ships write-only.
  • Duration Mismatch and Dropped Timed Event flag Play Sequence events whose media does not match the timings on their child events.

The Coverage Heatmap

  1. Mode selector switches what the color scale measures (Presented / Selected / Visited).
  2. Heatmap is the scene’s node graph, filled by coverage. Hotter nodes were reached by more walks; the coldest gray fills mark nodes no walk visited.
  3. Legend maps color to percentage, so you can eyeball the tail without hovering every node.

The three mode-selector values measure different things:

  • Presented counts walks where the node appeared as a visible choice.
  • Selected counts walks where the player picked it.
  • Visited counts walks where the runtime executed its events.

Presented minus Selected is where players saw an option and passed. Selected minus Visited is unusual, and usually a bug in your visibility conditions.

Click any node on the heatmap to jump to it in Node Graph.

The specialized panels

These panels render only when the run produces data for them. The single-scene fixture on this page won’t trigger most, so the descriptions below tell you what to look for on your own project.

Skill checks

Per-skill roll counts, pass rate, and DC distribution. Appears when at least one Skill Check event resolved during a run. See skill for the entity and project settings for the default dice.

Dead ends

An aggregated dead-end report grouped by node, with the variable state history that led there. Separate from the Dead End cards in the issues list because it collapses duplicates by shortest-path prefix, which the issue cards do not.

Location reachability

A matrix of which locations were reached from which starts. Appears when the project has locations wired up on the world layer.

Encounter reachability

Which encounters fired across which walks. Check it when an encounter should trigger reliably and something upstream is blocking it.

Scene call graph

Which scenes transitioned to which, and how often; scenes that never fire in a Full project run stand out here.

Under the details toggles

The rows below the specialized panels open collapsible sections with author-hygiene diagnostics. Open the one you want and leave the rest closed; each is a targeted view a writer will usually want once or twice per project rather than every run.

  • Node Lifecycle shows selection ratios and how often repeatable nodes fire more than once; look here when a one-shot node fires twice.
  • Bottleneck Nodes lists nodes that most walks pass through: the choice points everyone converges on.
  • Branch Points lists nodes with many visible children and reports how choices split between them.
  • Variable Analysis flags variables that are written but never read, or read but never written. The first surfaces cut content; the second surfaces broken conditions.
  • Mutual Exclusion Groups reports how often each option in a Choice Group won across walks.
  • Unused Media counts media entries with zero Play Sequence hits across the run.
  • Hook Coverage reports how often each Hook event fired. Integration-focused; bring it to the handoff with your engineers.
  • Condition Complexity flags dense visibility expressions and long jump chains that may become author-maintenance problems.
  • Performance diagnostics breaks down where the runtime spent its time during the run. Rarely relevant to writers, but a leading indicator that a scene will feel sluggish in the shipped game.

Where the reports go

After each run the Path Tester writes three files under the project’s reports/ folder: path-test-latest.json (the latest result), path-test-results.json (an accumulating log of every run), and path-test-report.md (a human-readable summary). The Markdown summary is the easiest way to share findings with an engineer without shipping the whole project.

See also

  • simulator: drive one path by hand while the Path Tester runs many automatically.
  • scenes and visit state: what “path completed” means in a Full project run.
  • world layer: the model Full project scope walks through as it moves between scenes.
  • skill: the entity the Skill checks panel rolls against.
  • project settings: default dice picked up by the Skill checks panel.
Docs last synced: 2026-07-08
Screenshot viewer