Quest Actions

Quest Actions allow you to control quest state transitions (accept, complete, fail) through player choices in your campaign. Quest progression is driven by explicit choice buttons, not hardcoded scene numbers.

Philosophy: Your campaign is like a "Choose Your Own Adventure" book. The GM's choices drive the story and quest progression, not automatic detection based on scene numbers.

How Quest Actions Work

When a player selects a choice with quest actions:

  1. The Campaign Cookbook processes each quest action in order
  2. Quest state is updated (accepted → active, active → completed, etc.)
  3. Rewards are allocated (for complete actions)
  4. The change is logged to that party's local quest log, visible in the Party Sheet's Quest Log section
  5. The scene transitions to the next scene

Available Actions

Action Description Syntax
accept Marks quest as accepted/active accept:Quest Name
complete Marks quest as completed, allocates rewards (gold, XP, items) complete:Quest Name
fail Marks quest as failed (no rewards) fail:Quest Name

Basic Syntax

Quest actions are added to the questActions array in a choice object:

{ "text": "Accept the quest", "nextScene": "ep1-scene2", "questActions": ["accept:The Missing Merchant"] }
Format: "action:Quest Name"
  • action - One of: accept, complete, fail
  • Quest Name - Exact name from episode's questTemplates
  • Use a colon : to separate action from quest name

Quest Name Matching

Quest actions use the quest name from the episode's questTemplates:

{ "episodes": [ { "episodeNumber": 1, "questTemplates": [ { "name": "The Missing Merchant", // ← This name must match "type": "investigation", // ... } ] } ] }

Then in your scene:

{ "questActions": ["accept:The Missing Merchant"] // Matches quest name }

Multiple Quest Actions

You can trigger multiple quest actions from a single choice. Actions are processed in order:

{ "text": "Merchant found alive! (DC 12 Survival - PASSED)", "nextScene": "ep1-merchant-rescued", "questActions": [ "complete:The Missing Merchant", "accept:Rescue the Captives" ] }

This completes one quest and immediately starts the next, creating a seamless story flow.

Complete Example: Quest with DC Check

{ "sceneId": "ep1-scene3", "title": "Tracking the Merchant", "readAloud": "<div class='read-aloud'><p>You find tracks leading into the forest...</p></div>", "choices": [ { "text": "DC 12 Survival - Follow tracks successfully (PASSED)", "nextScene": "ep1-merchant-alive", "questActions": [ "complete:The Missing Merchant", "accept:Rescue the Captives" ] }, { "text": "DC 12 Survival - Trail goes cold (FAILED)", "nextScene": "ep1-merchant-dead", "questActions": [ "fail:The Missing Merchant" ] } ] }

Quest State Flow

Quest actions move quests through these states:

Successful Quest Flow

Initial State: Available (defined in episode questTemplates)

After accept: Active (quest appears in the Party Sheet's Quest Log)

After complete: Completed (rewards allocated, quest log updated)

Failed Quest Flow

Initial State: Available

After accept: Active

After fail: Failed (no rewards, marked as failed in the quest log)

When Quest Actions Execute

Quest actions are processed before the scene transition. This ensures:

Best Practices

Accept Before Complete

Always accept a quest before trying to complete it:

✓ Good: Scene 1: accept:Quest → Scene 5: complete:Quest
✗ Bad: Scene 5: complete:Quest (never accepted)

Use Exact Quest Names

Quest names in actions must exactly match names in questTemplates:

✓ Good: "accept:The Missing Merchant"
✗ Bad: "accept:Missing Merchant" (missing "The")
✗ Bad: "accept:the missing merchant" (wrong case)

One Action Type Per Quest

Don't mix complete/fail in the same choice:

✓ Good: ["complete:Quest A", "accept:Quest B"]
✗ Bad: ["complete:Quest A", "fail:Quest A"]

Provide Failure Paths

Always include failure options for DC checks:

✓ Good: Choice 1: PASS → complete
Choice 2: FAIL → fail
✗ Bad: Choice 1: PASS → complete (no failure option)

Common Patterns

Simple Quest Acceptance

{ "text": "Accept the quest", "questActions": ["accept:The Missing Merchant"] }

Quest Completion with Rewards

{ "text": "Return to quest giver", "questActions": ["complete:The Missing Merchant"] }

Chain Quests

{ "text": "Continue the investigation", "questActions": [ "complete:The Missing Merchant", "accept:Rescue the Captives" ] }

DC Check Branching

// Success path { "text": "DC 15 Investigation - PASS", "questActions": ["complete:The Missing Merchant"] } // Failure path { "text": "DC 15 Investigation - FAIL", "questActions": ["fail:The Missing Merchant"] }

See Also

Ending a campaign

A choice with no nextScene does not end anything — the story simply stays on the current scene. To actually finish a campaign, say so:

{
  "text": "The Demon Prince is destroyed. The realm is saved.",
  "questActions": ["complete:The Final Battle"],
  "endsCampaign": "victory"
}
ValueMeans
victoryThe party saw it through.
defeatThey lost. The story is finished, but not won.
abandonedThey walked away. It closes unfinished.

Three outcomes rather than a simple flag, because finished and completed are different facts. A campaign the party lost is over, and a session summary that called that a victory would be telling the table something false about their own game.

To send the party backwards instead, use nextScene. Pointing a choice at a scene they have already played is how a refused offer returns them to where they were — there is no separate “go back” field, because that is just a destination that happens to be behind them. The Campaign Writer marks those with ↵ so you can see them.
Do not set both. The engine checks endsCampaign first, so a choice carrying both ends the campaign and its nextScene is never reached. The validator reports it.

A choice with neither a destination nor an ending is legal — the scene stays put, which is sometimes what you want for a choice that only fires a quest action. But it is ambiguous to read, and it looks exactly like a forgotten nextScene, so the Writer flags it for you to confirm.