Simulator

The Simulator is the editor’s dry-run loop. You pick where the run starts, watch the dialogue land message by message, make choices, and see what the runtime fires along the way. Use it to click through a section of your project before handing it off, and to spot the missing variable, the choice that never appears, or the scene that won’t end.

What’s not here: the conceptual model of how the runtime evaluates a step lives in evaluation cycle; how scene visit-state survives across activations is in scenes and visit state; the first-time-building walkthrough that introduces these controls in narrative form is first project.

The four panels

1. Context strip (top) gives you a one-line summary of where the run is: active scene chain, current location, and current time.
2. Dialogue area (left middle) is the scrolling message log. Messages reveal as the run advances, and activity widgets land here mid-log.
3. Choice panel (left bottom) is what the player can pick next: every visible node, grouped by speaker and (when used) by choice group.
4. State panel (right column) mirrors the runtime’s view of where the run is now: a node minimap of the active scene, a location minimap, and the active scene chain.

Sections 3, 4, 5, and 7 below dig into the controls on each panel.

Start a run

1. Restart rebuilds the run from scratch using the current Scope. Click it any time you want to start over from a fresh state.
2. Scope picks where the runtime begins. Three values: Full project runs from the project’s entry scene; Pick scene… opens a combobox of every scene in the project and treats the picked scene as the entry; Active scene uses whichever scene you most recently selected in Nodes mode, which is handy when you’re iterating on one scene and don’t want to re-pick it after every Restart.

If the project has structural errors, the Simulator refuses to start and shows the error count with an Open Validator button. The Simulator runs the actual runtime, so structural problems that the validator catches at rest will surface as cryptic runtime errors at the first step. Fix the validator findings first.

Step back through the run

Every step the runtime takes pushes a breadcrumb: the action that produced it (which choice was selected, which encounter was started), the state snapshot at that point, and the message and debug entries the step produced. The Toolbar shows the trail as a row of small breadcrumb pills: up to five recent steps from the undo trail, with the current state highlighted, followed by up to two dimmed redo pills for steps you’ve undone but could redo.

1. Breadcrumb pill: click any pill to jump the Simulator to that state. The Dialogue area, Choice panel, State panel, and debug rows all snap back to what they showed when that breadcrumb was new. From there you can take a different choice and explore a different branch without restarting.
2. Overflow trigger (...) appears at the left edge of the pill row when the trail exceeds five entries. Click it to open a dropdown listing every breadcrumb (and every redo entry) so you can jump further back than the visible row.
3. Scene combobox appears next to Scope when the scope is set to Pick scene (as it is in this shot); pick any scene from the list and the next Restart starts the run there.

Two notes:

• Rewinding doesn’t change the project. Variable writes and visit-state changes that happened in the “future” of the rewound state simply disappear from the run’s state; the project files on disk are unchanged.
• The trail resets on Restart. Use a breadcrumb to explore variations from a single starting state; use Restart when you want to start over from scratch.

Watch the run unfold

1. Advance mode picker (in the Toolbar) controls how fast the message log reveals. Four values:
   • Click to Advance (default) pauses at the first message of every step; click anywhere in the Dialogue area to reveal the next.
   • Auto Advance uses the same boundary but advances on a timer instead of a click.
   • Show All skips the pauses; every step’s full message batch reveals instantly.
   • Cinematic pauses at every message, not every step. Useful when you’re checking pacing.
2. Speaker line is the active dialogue event, with the speaker’s portrait if the character has one. Narrator lines render without a name, which matches the Dialogue composer’s Speaker-blank case in Nodes mode.
3. Message log is every revealed message for the current run, oldest at the top. Scroll back at any time.

Make choices

When the runtime is ready for the next pick, your options land in two places. Visible nodes render in the Choice panel below the Dialogue area. Activity widgets render in the Dialogue area itself, mid-log, because the runtime treats an activity as a kind of message rather than a kind of choice.

Visible nodes and choice groups

1. Choice button is one row per visible node. Click to select; selecting advances the run and adds the chosen node to the message log.
2. Choice group column appears whenever one or more visible nodes belong to a Choice group. The panel adds a parallel column for each group, labeled with the group’s name. A presentation tag appears next to the label when the group uses a non-default presentation mode. The group label is a heading, not a button; clicking a member behaves the same as any other choice.
3. Default pill marks the choice the runtime considers the default.

Choices are also grouped by speaker: each speaker gets its own column, side by side. When the project is single-player and every choice is the player’s, the panel collapses to a single column.

A node appears in the Choice panel when its Visible when expression evaluates true at the moment the runtime is presenting choices; see nodes and visibility for the rules the runtime follows.

Two end states replace the panel:

Project complete, use Restart in the toolbar to run again

Dead end, no visible nodes; add a Complete Project event to end the run, or set On exhausted

Project complete is the happy path: the runtime fired Complete Project and there is nothing else to play. Dead end (in red) is the failure mode: no visible nodes remain but no completion event fired. The fix is either a Complete Project event somewhere in the just-played chain or a scene’s On exhausted to handle the empty case.

Activity widgets

When an Activity event fires, the activity widget lands in the Dialogue area as the next message in the log. The runtime pauses there until you fill it in and click Complete; messages queued after the activity wait on the submission. The widget’s shape mirrors the activity’s authored variables and groups (see the activity reference).

Group widgets render based on the group’s minimum and maximum bounds:

1. Radio group (exactly one): one member is selected at a time; reselecting another member clears the previous.
2. Bounded checkbox group (up to a maximum): a checkbox grid. Once the max is reached, unselected checkboxes disable until you clear one.
3. Unbounded checkbox group (no maximum): every member is independently clickable.
4. Complete button: disabled here because a group with a minimum hasn’t met it yet; it stays disabled until every group’s selection satisfies its bounds.

Checkbox-group legends name the constraint and append a running (X selected) count; radio groups show Select an option until a pick lands, then Selection complete. The four constraint forms are Select N options (min equals max), Select up to N options (min is 0), Select N to M options (both bounds present and unequal), and Select at least N options (no max, min greater than 0).

Loose fields (variables that aren’t in any group) render per type:

1. Bool field: a checkbox.
2. Int field: a number input (decimals get the same widget).
3. String field: a textarea.
4. Read-only field: renders as label: value with no editing widget. The runtime owns the value; the writer can see it but can’t change it.
5. Complete button: enabled here because every mandatory field has a value. Mandatory fields are marked with a * after the label, and Complete stays disabled while any of them is empty.

When the runtime rejects a submission at the Complete step (a group’s bounds aren’t met against the runtime’s view of variable state), the offending widget or group shows a red message and the widget stays open for correction. The local UI gate catches the simple cases and disables Complete before the click; the inline-error path only fires when the runtime’s check disagrees with the UI’s pre-check, which is rare but real.

The Complete button at the bottom of the widget fires the activity’s variable writes in one batch and advances the run. Its enabled state is your quick gate-check: if it stays disabled, scan for a missing mandatory field or a group whose count is off.

Move around the world

When the run is at the world layer (no active scene), the Dialogue area is replaced by the World panel. The panel lists what the player can do at their current location.

1. Encounter row: a scene currently staged at the player’s location, with a small colored dot showing the scene’s Trigger kind (blue for character, green for item, gray for self). Clicking an encounter row starts that scene.
2. Trigger sub-label: under each encounter’s name, naming the triggering character or item.
3. Go to heading: opens the travel list.
4. Connection row: a connected location the player can travel to; click it to move there.

When neither list has rows, the panel shows Nothing to interact with here. (No visible encounters or connections at this location.)

If you’re inside a non-modal encounter, a Leave button appears below the choices so you can step out without finishing the scene. Modal encounters (the Modal scene field) don’t show it; the writer has to play the encounter through.

The world-layer authoring (Trigger kinds, Hide when resolved, the connections that build the travel graph) lives under Encounters, Locations, and World Graph; this section’s job is just to name what you see during a run.

See what fires

The Debug toggle in the Toolbar’s right half interleaves debug rows with the messages in the Dialogue area, surfacing the runtime events you normally don’t see (variable writes, jumps, hook fires). Reach for it when a choice you expected to appear didn’t, or when a variable you expected to mutate didn’t.

1. Debug toggle turns the debug rows on and off. Off by default to keep the run uncluttered.
2. Filter popover appears next to the toggle when Debug is on, labeled Debug filters. Five checkboxes, all on by default; turn one off to silence that bucket while keeping the others:
   • User actions: every step you drove (choices picked, encounters started, locations moved to, activity widgets submitted with the field values that landed). Useful for reconstructing a session.
   • Variables: SetVariable events with the new value.
   • Jumps: Jump events, including their return / no-return shape.
   • Hooks: hook events the runtime fires for the studio (named signals the studio’s engineers wire up).
   • Other events: everything else the runtime fires that isn’t a dialogue line, variable write, jump, hook, or user action (scene lifecycle, skill-check resolution, and so on).
3. Debug row: a colored row interleaved in the message log; the color and prefix name the bucket it came from.

The popover is the “find the noise” tool: when one bucket dominates the log and you’re hunting something else, turn the loud one off.

See also

• first project: the tutorial that introduces these controls in narrative form.
• editor tour: the layout shot for the editor’s modes.
• nodes and visibility: what makes a node a choice.
• evaluation cycle: what the runtime is doing on each step.
• activity reference: the entity reference for activities.
• encounters: the authoring side of the encounter affordances.
• world graph: the authoring side of the location graph.