Quests

A quest is a list of steps, each with an optional condition and a list of rule steps that fire on completion.

Two kinds of stage

A step with a condition completes synchronously the moment the condition holds. Precise, instant, and cheap.

A step with no condition is judged by the model — it completes when the story says it did. That is what lets "convince the harbourmaster to look the other way" be a real objective rather than a flag hunt.

You can mix them freely in one quest, and most good quests do: hard gates where precision matters (has the relic, is at the lighthouse), narrative judgment where it does not.

Rewards

Two channels:

• Per-step rule steps fire as each stage completes.
• rewardSteps on the quest itself is the payoff at the end.

The reward text is player-visible — the NPC pitching the quest has to be able to mention it.

Driving quests from world state

The durable way to build a multi-stage quest is to have player actions write world state, and gate later stages on those flags:

$.setWorldState({ key: "harbour", value: "closed" })

State written that way survives across sessions and is visible to every other system — so a location, an NPC's schedule and a quest stage can all react to the same fact without knowing about each other.

Worked example

The lighthouse keeper's silence

1. Talk to the keeper. No condition — the model judges when the conversation has actually happened.
2. Find the logbook. Condition: hasItem Logbook. Reward step: $.setWorldState({ key: "knows_about_tides", value: "yes" })
3. Confront the harbourmaster. No condition — judged. The narrator knows the player has the logbook because step 2 wrote a flag every system can see.
4. Reward: $.grantXp(50) and an item.

Next

Plugins — bundling rules into a system you can share.