The idea in one sentence

A dialogue tree is a map of a conversation: the NPC says something, the player picks a reply, and that reply jumps to the next thing the NPC says. You author every line and every path, so the conversation can never go anywhere you didn't write.

The three pieces

• Node - one thing the NPC says, plus the list of replies available there. A node has a key (a short id like greet), the NPC line, and flags for entry and terminal.
• Response - one reply the player can pick at a node. It has the player's text, a goto (which node it jumps to next), an optional sets clue (a clue flag it hands the party), and optional gate conditions.
• Gate condition - a rule that hides a response or clue until it's met (reputation, a prior flag, a party class, an item). No conditions means it's always shown.

How the player moves through it

The game shows the entry node's line and its responses. The player picks one. If that response has a goto, the game jumps to that node and shows its line and responses. A response with no goto (or a node marked terminal) ends the conversation. That's the whole loop - say, pick, jump, repeat.

Building one, step by step

The player clicks - never types

This is the part that's easy to miss: the player never types anything. Every line on both sides of the conversation is one you wrote here.

• The NPC speaks first. The entry node's line is what the NPC says when the party walks up - not the party's words.
• The responses are buttons. The player is shown the node's responses as a list of clickable options and picks one. They choose which of your written lines to say - they don't compose their own.
• Information flows NPC → player. The player's pick is usually just the question or prompt ("What's wrong on the east road?"). The answer - the clue, the rumor, the lore - comes back from the NPC as the reward for asking.

This is exactly why the system is canon-safe: there's no free text to wander off-script, so an NPC can only ever say what you authored and only ever hand over a clue you planted.

A worked example

Hessa Brand, the tavern keeper. Her tree:

The "tower lights" reply stays hidden until the party has accepted the quest. Picking "I'll look into it" hands over the disappearances clue and returns to the greeting so Hessa can be asked more.

Where a response goes (goto)

Every response has a "then go to" setting. It can point three ways:

• Loop back (e.g. to greet) - the player returns to the menu and can ask something else. This is the most common choice and it's not a mistake.
• Chain forward - point to a deeper node to continue the conversation before the menu comes back.
• End the talk - point to a node marked "ends talk," or set goto to (ends the talk). Either closes the conversation.

Goto stays inside this one NPC. It can't jump to another character's conversation. Talking to a different NPC happens naturally when the player walks up to them - their own greeting fires.

What "hands over clue" does

When a response has a clue set on it, picking that response writes a flag into the save - the party now permanently knows that piece of the mystery. That one flag can then:

• Unlock other dialogue - another NPC's response that's locked to that flag now appears.
• Fill the clue log - the player can review what they've pieced together.
• Advance the story - the mystery is the flag graph; collect the right flags and the next region opens.

This is the bridge from talking to the mystery actually moving. Without it the conversation is just flavor; with it, asking the right question changes the game.

Locks, in detail

A lock hides a response (or a clue) until a rule is true. No lock = always shown. A lock has four parts, and the tool writes the plain-English version for you as you fill them:

• type - what to check: flag, reputation, alignment, item, or class.
• name - which specific one (the flag's name, the faction, the item, the class).
• comparison - is set for on/off things like flags; or at least / at most / exactly for numbers like reputation.
• value - the number to compare against (only needed for reputation-style checks).

Three examples:

The one rule that trips everyone up

Don't lock your payoff response - the one that hands over a clue. That's the line you want the player to be able to click; locking it hides the very thing you're trying to give them. Locks belong on responses that should stay hidden until the party has progressed (like the "tower lights" line before the quest is accepted), not on baseline questions or clue-dispensing replies.

Why the menu changes each visit

When the player loops back to a node, its responses are re-checked against their locks at that moment. Ungated responses always reappear; locked ones appear or vanish as flags flip. So one greet node quietly becomes a "before the quest" menu and an "after the quest" menu - without you writing two of them.

Rules & gotchas

• Exactly one entry node. Checking entry on a node clears it from the others.
• Every node needs a key, unique within the NPC - the "then go to" dropdowns are built from them.
• You can only hand over clues this NPC holds. If a clue isn't in the dropdown, add it in the Clues card first.
• Loops are good. Returning to greet is how the player keeps asking - it's not a mistake.
• A response that goes to (ends the talk) closes the conversation, same as an "ends talk" node.
• Multiple locks on one response all must pass (AND). Need an either/or? Make two responses.
• Don't lock the response that gives a clue. Locks hide things until progression; payoffs stay open.