Hold the Flood — Design Tasks
Maintainer: PM. Revision: design-only reset, 2026-09-06 UTC. States: Ready, In progress, In review, Accepted, Blocked, Deferred, Superseded. A proposed agent is not assumed to exist. PM accepts design work; the owner authorizes a phase change.
Active design sequence
| ID | Deliverable | Responsible role | Current state | Dependencies / review criteria |
|---|---|---|---|---|
| PM001 | Original wiki kickoff | PM | Accepted historically | Four original pages published and checked at the previous address |
| OWN001 | Initial creative and production brief | Owner | Accepted | Follow-up supplies genre, priorities, references, engine, platform, asset rules, and phase gate |
| PM002 | Revised brief, team prompts, tasks, approval gate | PM | Accepted | Four revised pages published via the wiki's documented agent interface and their saved source verified |
| DES101 | Two compact concept directions and one recommendation | Lead Game and Systems Designer | Blocked on agent invocation | Each: player fantasy, main actions, survival pressure, discovery, build expression, progression, one distinct interaction, major scope cuts / critic + PM |
| WLD101 | Exploration and mystery contribution | World and Mystery Designer | Blocked on agent invocation | Can start alongside DES101; show a complete clue-to-deduction-to-action chain, knowledge progression, and pressure/curiosity tradeoff / lead + critic |
| OWN101 | Steer the recommended concept | Owner, facilitated by PM | Waiting for concept packet | Confirm or adjust premise and priorities; this is not development approval |
| DES102 | Integrated game design document draft | Lead Game and Systems Designer | Waiting for working concept | Integrate accepted world/mystery work; meet the document criteria below / critic + PM |
| REV101 | Independent design critique | Independent Design Critic | Blocked on agent invocation and first draft | Start with DES101/WLD101 when available; identify specific contradictions, weak choices, asset/scope risks and corrections / PM |
| DES103 | Revised owner-facing design document | Lead Game and Systems Designer | Waiting for integrated draft and critique | Resolve material findings; preserve explicit unknowns; concise pitch plus supporting detail / PM |
| OWN102 | Design verdict and possible development authorization | Owner | Waiting for reviewed document | Revise / reject / approve design; development remains gated until explicitly authorized |
DES101 and WLD101 begin from the confirmed brief; they may propose assumptions for undecided setting details. The critic need not wait for the entire document to identify early contradictions.
Superseded or deferred work
| Previous ID / assignment | New status | Reason |
|---|---|---|
| DES001: smallest playable experiment specification | Superseded by DES101 and DES102 | Current deliverable is a compelling game design |
| ENG001: build inventory / technical experiment | Deferred | Assume nothing exists; written feasibility only if PM assigns it |
| QA001: prototype checks | Superseded by REV101 | Current review concerns design documents |
| ENG002: playable implementation | Deferred; not authorized | D007 owner gate |
| QA002: executed prototype review | Deferred; not authorized | D007 owner gate |
| OWN002: prototype play session | Deferred; not authorized | D007 owner gate |
Do not take old Ready/Blocked build tasks as authorization to execute them. No technical spike, prototype, playable mockup, simulation, or build setup is an exception.
What the design document must make clear
- Identity: player fantasy, intended experience, premise, and a compelling reason this game exists. Explain it in its own terms, with references as supporting context.
- Core play: player actions, controls as a design proposal, readable feedback, immediate decisions, pressure, failure, retreat/end conditions, and return/retry.
- Exploration: world organization, route choices, landmarks, revisiting, and how a discovery changes future action.
- Experimentation: proposed rules and combinations, limits/costs, at least three genuinely different build examples, and an example where a plausible experiment fails for an understandable reason.
- Mystery: one fully specified example with clues, a fair deduction, the action it enables, and the consequence. Mark solutions as designer spoilers. Explain what knowledge persists and how discovery avoids simple stat locks.
- Progression: separate what resets, what remains as resources/world/colony state, and what persists as player knowledge. Explain any colony loop's actual decisions and cost.
- Integration: one clearly labeled illustrative expedition, followed by a later expedition changed by what was learned. Show causal links between pressure, gathering, build choices, exploration, and mystery. Do not invent playtest outcomes.
- Presentation and assets: coherent direction, essential asset categories and reuse strategy, plausible existing-asset routes, coverage gaps, and requests needing owner approval. Asset availability and usage terms must not be invented.
- Scope: minimum complete intended experience, optional extensions, explicit cuts, complexity drivers, and cheap alternatives. Avoid huge item/lore catalogues before the rules justify them.
- Honesty: contradictions resolved or explicitly presented for a decision; uncertain runtime feel/balance/performance marked for later validation. No claims of tested enjoyment.
The owner packet should open with a short pitch and concrete play example, followed by enough detail to assess the game. Quality is determined by specificity, coherence, and appeal to the owner, not document length.
Review criteria
A useful critique identifies the exact section/revision, the claim or interaction in question, the conflict or missing causal link, its player/scope consequence, and the smallest constructive correction. Separate violation of an owner requirement, internal contradiction, under-specified design, taste judgment, and future empirical uncertainty.
PM requests revision when central systems compete without a resolved design, all builds amount to different damage numbers, mysteries lack a fair discovery path, scope depends on unapproved assets, or prose hides missing rules. Document review does not establish actual balance, feasibility, or fun.
Progress report
Task ID; artifact/revision; changed decisions; sources or written reasoning; outstanding risks; next handoff; one exact PM request if blocked. Stop repetitive reports and unbounded polishing; PM decides the next useful revision.