Quests

A quest is authored as a graph, but where a dialogue graph models a conversation, a quest graph models progress: which objectives exist, when they're introduced, what completes them, and what happens once they do. Playing a quest means walking the graph the same way a dialogue does — entering at its start and following whichever connection the current node leads to, until flow reaches an ending.

Every quest graph has exactly one Quest Node, its entry marker.

Objectives

The step-by-step content of a quest — the things a player actually works through:

• Objective — introduces one step to the player ("Kill the Jarl") and continues immediately. On its own it doesn't wait for anything; declaring an objective and completing it are two separate moments in the graph.
• Update Objective — patches an objective already introduced: marks it complete or failed, or reopens one that was. Placed wherever the graph decides that change has happened.

An objective can be optional — it enriches the quest but never blocks completion — and hidden, kept out of the quest log until something reveals it. It can also belong to a named group, for organizing a long quest's log into sections like "Act 1" and "Act 2".

The common shape for "wait until this happens, then mark it done" is an Objective, followed by a Gate holding the condition that means it's finished, followed by the matching Update Objective. It's normal for other nodes to sit between the Objective and its Gate — the gate only has to be reachable eventually, not immediately after.

Branching and pacing

• Gate — pauses the flow until a condition becomes true, then continues on its own. The same node a dialogue uses, doing the same job.
• Hub Node — branches immediately based on conditions on its outputs, with no waiting involved.
• Fork — splits into more than one path that all run at once, rather than choosing between them. Use it for objectives that start together and can be completed in any order.
• Event Listener — sits outside the main flow and reacts whenever the game state it's watching changes, rather than blocking anything on the spine of the quest. This is what an optional objective usually wants: a Gate would hold up the rest of the quest until it's satisfied, where a listener lets the quest carry on and only acts once its condition fires.
• Return — hands control back from an Event Listener, or ends one branch of a Fork.
• Jump Node — redirects flow to another node in the same graph, the same as in a dialogue.
• Instruction Node — sets a variable or calls a function without waiting on anything.

Ending a quest

Complete Quest is a quest's terminal node, marked success or fail. A quest needs at least one; several, one per distinct ending, is normal.

Splitting a quest across graphs

Two nodes send flow to another quest graph, for different reasons:

• Start Quest Fragment — dives into a separate Quest Fragment graph and returns here when it finishes, under this quest's own identity the whole time. Use it to split a large quest into manageable pieces, the way a subroutine splits up a long function.
• Start Quest (Async) — starts a different quest outright, in its own right, and continues immediately without waiting for it. Reach for this only when a second, independent quest should actually begin — not as a way to run something in the background of the current one; a Fork or an Event Listener covers that instead.

A Quest Fragment is a quest graph created with that distinction set — the Add menu offers it alongside Dialogue and Quest.

Working with dialogue

Quests and dialogues share the same variables, so the two stay in sync without either calling into the other. A quest can hand off to a specific conversation with a Start Dialogue node — either the dialogue's own start or a specific point inside it — and flow returns to the quest once that conversation ends.

Just as often, a quest and a dialogue are connected only implicitly: a conversation sets a variable the quest is waiting on, without the quest graph ever naming that dialogue at all. See Variables and conditions for how that shared state works.

Custom nodes

Some effects belong to your game rather than to Narratyr — playing a sound, loading an area. A Custom Node fires an event carrying whatever data you've defined for it, and either waits for your game to say it's finished or continues on its own, depending on how you've set it up. Which custom nodes are available depends on what your own project has defined.

Debugging

The simulator steps through quest progression the same way it steps through a conversation — showing which transition fired, and which condition let it, including branches the player never triggered and why.

Next

Build a quest walks through the smallest version of that shape — objective, gate, update, completion — a node at a time. Build a multi-objective quest extends it with several concurrent objectives, dialogue, and multiple endings. Variables covers the shared state underneath both, and Dialogues covers the other half of the model.