Author Guide Quick Start

The Sovereigns Codex campaign system is declarative. You describe towns, NPCs, quests, dialogue, triggers, dungeons, monsters, and endings as campaign data; the game runtime interprets that data.

This guide is tutorial-first. Its main path builds one complete campaign—The Drowned Bell—through eleven progressive chapters. The How-to, Reference, and Troubleshooting sections follow for returning authors and readers who would rather jump directly to a specific task or piece of syntax.

You do not need a private publishing account or a local development server to begin. You need a desktop browser, a text editor, and a complete campaign JSON file supplied or built through the tutorial.

Three web pages you’ll use

Page	Use it for
Guide	Learn the workflow, supported contract, design patterns, and failure modes.
Author	Validate JSON, import a browser-local campaign, inspect stored imports, and launch a playtest.
Play	Experience the campaign as a player and test actual runtime behavior.

The Author tools store imported campaigns in the current browser profile. Importing a file there does not publish it or upload it to a public campaign catalog.

Choose your route

• New campaign author: follow Build The Drowned Bell from the beginning.
• Returning author with a specific task: use the How-to Guides.
• Looking up exact syntax: use the Contract Reference.
• Something is failing, missing, duplicated, or unreachable: start with Troubleshooting.

Your first working campaign file

Chapter 1 provides the first complete teaching checkpoint. You can download that file or build the same campaign shell while following the explanation. From there, each chapter adds a small, cumulative change.

Your working loop is:

1. Read the current tutorial chapter.
2. Download its checkpoint or apply the chapter’s changes to your own source file.
3. Open the Author tools and validate the complete JSON file.
4. Correct every reported error and review every warning.
5. Import the corrected file as a local test campaign.
6. Launch Play when the chapter includes runtime verification.
7. Return to your source file, revise it, and repeat.

Keep one source file

Treat the JSON file on disk as your source of truth. Browser-local storage is a playtest destination, not your authoring workspace.

One rule to recognize before Chapter 1

You do not need to invent IDs on this page; Chapter 1 walks through that work. For now, know that every campaign needs a stable ID and every campaign-owned object should use that ID as a namespace.

The tutorial uses:

campaign: tutorial_codex
town: tutorial_codex:greyhaven
npc: tutorial_codex:mara_vey
quest: tutorial_codex:missing_courier

Names and descriptive text can change during editing. Stable IDs should not change casually after playtesting or release because saved story state refers to them.

Do not copy another campaign’s IDs

Use a namespace that belongs to your campaign. Reusing another campaign’s IDs can create reference collisions and confusing save behavior.

Know what validation does not prove

The validator catches malformed data, unsupported values, and many broken references. It cannot prove that:

• the player understands what to do,
• an objective is reachable in every order,
• an encounter is fair,
• dialogue feels natural,
• an ending resumes control correctly,
• the campaign is fun.

That is why the workflow separates contract checks, validator output, runtime tests, and human playtesting.

Next step

Read the Campaign Authoring Workflow to see where the provided AI prompts can help, then begin Chapter 1: Create the Campaign Shell.