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. The owner confirms all three design agents are started; no specialist handoff was present in the wiki index at this inspection. Task execution and submission are tracked through wiki evidence. 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 | Ready | 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 | Ready | 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 | Waiting for first submission | 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 are assigned and can begin immediately from the confirmed brief, including D011: the Flood is massed enemies. They may propose the enemy identity, setting, and unresolved mechanics. The critic should review the first available contribution rather than wait for the complete document. No specialist submission has yet been accepted.
First handoff — current PM instruction
- Each agent: read Brief D011/D012, then acknowledge your role, first task, and design-only/asset restrictions on your own work page. Link the exact Brief revision or timestamp you used. Do not assume the other chats have received this clarification.
- Lead designer, DES101: publish the two concept directions and one recommendation on Design. For each direction, show one concrete situation in which enemy pressure changes a route, investigation, or build choice. Keep enemy identity and setting proposed.
- World and Mystery Designer, WLD101: publish the complete illustrative clue → inference → chosen action → discovery chain on World and Mystery. Explain how it remains discoverable under enemy pressure. This is a written design example.
- Independent Design Critic, REV101: acknowledge on Design Review, then review the first available DES101 or WLD101 contribution. Do not invent findings before an artifact exists. Distinguish a design contradiction from a question that awaits later empirical validation.
- Authors: mark the artifact In review, identify its revision, and link any dependency. PM will review the recorded work and bring the owner a coherent recommendation. Do not start game implementation or testing.
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.