Commit 0b1275
2026-09-07 17:26:34 Anonymous: PM restart setup: define first design milestone and acceptance criteria| /dev/null .. hold the flood/design plan.md | |
| @@ 0,0 1,26 @@ | |
| + | # Hold The Horde — Design Plan |
| + | |
| + | The first design milestone will show how discovery, expressive builds, horde survival and caring for rescued people can support one coherent experience under the [Owner Brief](/Hold%20The%20Flood/Brief). |
| + | |
| + | This is a plan for the new team's first assignment, not a game proposal, settled mechanics or permission to implement anything. [Team setup](/Hold%20The%20Flood/Team) comes first. No previous design settles the brief's undecided systems. |
| + | |
| + | ## First delivery |
| + | |
| + | The design lead will own one short player-experience proposal, supported by a systems comparison and reviewed independently. Describe a station sortie from the ship through a clear immediate objective, meaningful horde pressure, a useful discovery and a purposeful return. Include a concrete human consequence involving an authored survivor. |
| + | |
| + | Compare **two materially different build approaches to the same objective**: what the player acquires, chooses and sacrifices; how power grows; where each approach fails; and how a learned interaction remains useful beyond one specially prepared room. Preserve the desired tradeoff between equipment and salvage. Enemy manipulation may contribute without becoming the main subject of experimentation. |
| + | |
| + | Show what the player knows and can do after the discovery that changes a later decision. Separate readable survival information and controls from intentionally unresolved mysteries. Keep proposed mechanics and persistence rules explicitly provisional. Do not select the central mystery's answer merely to complete the document. |
| + | |
| + | Aim for a readable proposal of roughly 1,200 words plus a compact comparison; useful clarity matters more than an exact quota. A full design bible, detailed balance numbers, fixed district counts and elaborate lore are premature. |
| + | |
| + | ## Acceptance |
| + | |
| + | - Faithful to the astronaut, hostile unofficial station, limited carried oxygen/unlimited ship oxygen, unexplained revival, rescued community and alien-language premise. |
| + | - Discovery first and expressive builds second are visible in player decisions; ordinary horde combat matters. |
| + | - The two approaches create different meaningful decisions, costs and weaknesses, rather than cosmetic variants or permission to trigger one scripted event. |
| + | - Systems do not contradict one another, and the immediate goal and survival information remain understandable. |
| + | - Unknowns and the largest content/scope risks are explicit. The 30/90/100–200 hour ambitions remain unvalidated. |
| + | - An independent review identifies any material objection and the author responds with reasons. Acceptance never requires unanimity. |
| + | |
| + | PM will integrate a coherent provisional direction, retain important unresolved tradeoffs and ask the owner only the decisions that materially affect it. Later development or player validation requires explicit owner authorization; written descriptions cannot establish gameplay quality. |