Campaign Authoring Workflow

A campaign is not finished when the JSON parses. The practical workflow moves through creative decisions, implementation, validation, independent review, runtime testing, and a human release decision.

You can perform every stage by hand. The project also provides focused AI prompts for the stages where a structured assistant is most useful. Those prompts do not replace the human campaign owner, the validator, or playtesting.

The lifecycle

Stage	Primary owner	Working artifact	Exit condition
1. Creative brief	Human campaign owner	Premise, player fantasy, scope, ending	The desired experience and boundaries are explicit.
2. Campaign design	Creative Director	Campaign Design Document	Major story and progression decisions are approved.
3. Implementation	Technical Implementer	Campaign JSON and supporting assets	Approved intent is represented with supported contract values.
4. Validation	Technical Implementer	Validator report	Errors are fixed; warnings are understood and dispositioned.
5. Independent review	Campaign Reviewer	Review report and dependency ledger	References, fidelity, and likely progression paths are assessed independently.
6. Human playtest	Human campaign owner and testers	Playtest notes	Required normal, repeated, and out-of-order paths have observed evidence.
7. Revision	Appropriate owner for each finding	Updated design or payload	Findings are corrected without silently changing approved intent.
8. Release decision	Human campaign owner	Evidence summary and known-risk list	The owner explicitly approves release or sends the campaign back for work.

These stages are gates, not a rigid waterfall. A playtest can reveal a design problem. A review can expose an engine limitation. A validator error can reveal that an implementation assumption was never supported.

AI helpers for stages 2–5

The supplied prompts establish separate roles so one AI conversation does not blur creative decisions, implementation claims, and review conclusions.

Stage	Optional helper	What to provide
2. Campaign design	Campaign Creative Director prompt	Your creative brief, required ideas, exclusions, desired length, and any non-negotiable decisions.
3. Implementation	Campaign Technical Implementer prompt	The approved Campaign Design Document and any existing campaign payload being revised.
4. Validation and correction	Campaign Technical Implementer prompt plus the Author validator	The exact validator output, the current JSON, and a request for localized corrections rather than a wholesale rewrite.
5. Independent review	Campaign Reviewer prompt	The approved design, implemented payload, validator output, dependency notes, and planned playtest paths.

Keep the roles separate

Do not ask the Creative Director to invent JSON, and do not treat the Technical Implementer’s confidence as an independent review. A single AI model may perform several roles, but each role should receive the correct artifacts and start from a clean instruction context when practical.

The validator remains authoritative

An AI assistant can explain an error and propose a correction. Only the actual Author validator demonstrates whether the revised payload passes the current validation rules.

1. Define the creative brief

Write down:

• the campaign premise,
• the player fantasy,
• intended length,
• expected party strength,
• the main locations and cast,
• the ending condition,
• deliberate exclusions.

Scope is part of design quality. A short campaign with a clear ending is better teaching material—and often a better player experience—than a sprawling campaign made of unfinished ideas.

2. Resolve design before implementation

The Campaign Design Document should answer creative questions before JSON fields begin driving the conversation.

For example:

• May the player find the courier’s letter before accepting the quest?
• Must Lysa be recruited?
• Does defeating the Echo Warden end the campaign immediately?
• What should the player see after victory?
• Which paths are intentionally unsupported?

The Creative Director prompt can turn a clear brief into a structured Campaign Design Document. The human campaign owner must still approve the names, scope, progression decisions, and ending before implementation begins.

The Technical Implementer may raise feasibility problems, but should not silently rewrite those decisions.

3. Implement with supported declarative data

Translate the approved design into:

• stable, namespaced IDs,
• known registry values,
• explicit references,
• ordered dialogue conditions,
• durable progression state,
• verified placement models.

The Technical Implementer prompt is designed for this translation. Give it the approved design and tell it whether you are creating a new payload or making a localized revision.

Prefer a small working payload that grows through checkpoints. Large first drafts make it harder to identify which addition introduced a failure.

4. Validate early and repeatedly

Validate after each meaningful checkpoint, not only at the end.

A useful validation cycle is:

edit → parse → validate → correct → validate again

Use the Author tools for the actual validation pass. When errors appear, give the Technical Implementer the exact messages and current payload. Ask for the smallest correction that resolves the reported problem without regenerating unrelated content.

Do not import a campaign merely because the file looks reasonable. JSON syntax errors and reference mistakes are cheaper to fix before runtime state is involved.

5. Review independently

The Campaign Reviewer should not be the same reasoning pass that authored the implementation.

The Campaign Reviewer prompt traces dependencies such as:

player action
→ event or dialogue condition
→ flag, item, or quest state
→ objective completion
→ next reachable action
→ ending condition

The reviewer identifies likely failures and evidence gaps. The reviewer does not replace human playtesting.

6. Playtest adversarially

Test the expected route, then behave like a curious player:

• explore before accepting a quest,
• repeat conversations,
• revisit chests,
• recruit, dismiss, and re-recruit companions,
• defeat unrelated enemies,
• enter unrelated locations,
• save and reload between milestones,
• continue playing after the ending.

The Drowned Bell’s most important progression lesson came from opening the courier’s satchel before speaking with Mara.

7. Revise without destabilizing IDs

Change copy, conditions, actions, placement, and balance as needed. Avoid casually renaming IDs after they have entered saves or published revisions.

When an ID must change, treat that as compatibility work rather than ordinary editing.

8. Record the evidence honestly

A release summary should distinguish:

• Contract-checked: supported shape and values were reviewed.
• Validator-checked: named validator output was recorded.
• Runtime-tested: a regression or observed runtime path demonstrated behavior.
• Human-playtested: a person completed the required scenarios.
• Known risk: a remaining limitation is understood and accepted.

“Validated” by itself is too vague.

The iteration rule

When evidence disagrees with intention, believe the evidence first.

A campaign that validates but cannot be completed is not complete. A campaign that matches the design document but confuses every tester needs a design revision. A runtime bug discovered by a campaign should be corrected in the engine when it could affect other campaigns.

Continue

Read Roles and Evidence for the handoff boundaries, or begin The Drowned Bell tutorial.