Branching dialogue

Branching dialogue is what you author inside a node: the events that fire when the node plays, the Conditions that gate individual events, the Jumps that wire one node to the next. “Branching” here means a tree of choices the player picks through; the Node Graph is the bird’s-eye view, and this page is what you compose inside each card.

This page focuses on two event types, Dialogue and Jump, because they carry every player-facing dialogue tree. For the full event catalog, see Event types.

Build a dialogue node

  1. Events list: every event you’ve authored on this node, in fire order.
  2. Collapsed event: an event shown as a header without its composer body.
  3. Expanded event: click a header to open its composer in place; click again to collapse.
  4. Add event: a menu of every event type the node can carry.

The Inspector’s events list is where you author what a node does. Each event fires in list order when the node plays. Reorder events by dragging a row in the events list. The most common shape is a stack of dialogue events with a jump at the bottom.

  1. Speaker: which character says this line. Leave blank to show the line as Narration without a character name.
  2. Text: the line itself.
  3. Voice clip: an optional audio clip the runtime plays alongside the line.
  4. Duration: an optional auto-hide timer in seconds. Leave blank and the line stays up until the next event advances it.
  5. Condition: an optional expression. The event only fires when the expression is true; the rest of the events on the node are unaffected.

The runtime fires a Dialogue event to the studio for every dialogue line, with the speaker, text, voice clip, and duration filled in. How the studio renders these is up to the game; see Dialogue for the full Dialogue event field reference.

Stack dialogues on one node

A node can carry several dialogue events with different Speakers, like the Inspector shot above. When the node plays, every dialogue event fires in order: a Narrator setup, then an NPC line, then a Player response, all from one node.

This is different from splitting the same lines across separate nodes. Each node is a unit the writer gates with Visible when; if you want the Player response to be a choice the player picks, it belongs on its own node. If the lines are a single beat the player watches play out, stack them on one node.

Gate individual events with a Condition

Every event has a Condition field at the bottom of its composer (see the dialogue composer above). When the Condition is set, the event only fires if the expression is true at the moment the node plays. Other events on the same node are unaffected.

Use Condition when one line inside a node should change based on history, but the node itself should still appear as a choice. Reach for it for variant lines, “first time only” tags, or skill-aware reactions.

The rule of thumb: if every line on a node would change based on the same condition, split the node and gate it with Visible when instead. If only one line differs, gate that line with a Condition.

See Event types for the full Condition reference, which applies the same way to every event type.

Make a node a choice

A node shows up as a choice the player can pick when its Visible when is true at the moment the runtime is presenting choices. There is no separate choice-node type; any visible node is a choice. Hidden nodes (empty Visible when) are reachable only via Jump.

For the conceptual model (what visibility means, when it’s evaluated, what counts as “current choices”), see Nodes and visibility.

Choices can also be grouped. A Choice group lives in the project data, and the host game’s UI uses it to group related choices, for example as a sub-menu. Choice groups don’t change which nodes are visible or what the simulator returns. See Choice group for the entity reference.

Connect with Jumps

Most nodes finish naturally when the runtime exhausts their events. Use a Jump event when you need control to land on a different node afterwards: a hidden response node, a continuation scene, a shared cleanup beat.

  1. Target Node: the node to jump to. The picker lists every node in the same scene as the source.
  2. Return after jump: on by default. When on, the runtime returns to the source node after the target finishes and runs any events you’ve added after the Jump. When off, the runtime stops the source node and skips anything after the Jump.
  3. Condition: optional, like every event. The Jump only fires when the condition is true.

To draw a Jump from the Node Graph, drag from the bottom of a node to another node. This creates a Jump event on the source with Return on by default. Hold Shift while dragging to create a non-return Jump instead.

Right-click a Jump Connection in the Node Graph to delete it.

Dependencies vs Jump Connections

  1. Dependency: a line anchored at the top of the card. The target node’s Visible when references Played(...) of the source. Read it as: “this node becomes a choice after the source has played.”
  2. Inverse dependency: also anchored at the top of the card, drawn with a slash. The target’s Visible when references !Played(...) of the source. Read it as: “this node stops being a choice once the source has played.”
  3. Top vs bottom of the card: where a Connection meets the node. Lines anchored at the top are Dependencies or Inverse dependencies (drawn as a Visible when reference); lines anchored at the bottom are Jump Connections (drawn as a Jump event).
  4. Jump Connection: a line anchored at the bottom of the card. Backed by a Jump event on the source. Read it as: “control flows from the source to the target.”

Lines anchored at the top reflect Visible when; lines anchored at the bottom reflect Jump events. Right-click any line to remove it. For Dependencies and Inverse dependencies, that means editing the source’s Visible when expression; for Jump Connections, it means deleting the Jump event.

See also

  • Nodes and visibility: the conceptual model behind Visible when, hidden nodes, and what counts as a current choice.
  • Expressions: the syntax for what goes in Visible when and Condition fields.
  • Node: the full Node entity reference.
  • Character: Speakers reference characters.
  • Choice group: the entity reference for grouping related choices in the host UI.
  • Event types: the full event catalog.
  • Node Graph: the editor mode this page composes inside.
  • Error messages: Dialogue and text: panel messages about empty Body fields and dialogue or template text that exceeds the runtime cap.
Docs last synced: 2026-07-08
Screenshot viewer