Blame
|
1 | # Hold The Horde — Design Plan |
||||||
| 2 | ||||||||
| 3 | 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). |
|||||||
| 4 | ||||||||
|
5 | This is the initial design assignment for the registered [team](/Hold%20The%20Flood/Team), not settled game mechanics or permission to implement anything. No previous design settles the brief’s undecided systems. |
||||||
|
6 | |||||||
| 7 | ## First delivery |
|||||||
| 8 | ||||||||
|
9 | 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. For this initial comparison, use a representative sortie to recover useful station salvage and return. This is a proposed design exercise, not a mandated opening mission; its exact fiction remains open. |
||||||
|
10 | |||||||
|
11 | Compare **two materially different build approaches to the same objective**: what the player acquires, chooses and sacrifices; how power grows; what limits or failure cases remain; 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. |
||||||
|
12 | |||||||
| 13 | 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. |
|||||||
| 14 | ||||||||
| 15 | 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. |
|||||||
| 16 | ||||||||
| 17 | ## Acceptance |
|||||||
| 18 | ||||||||
| 19 | - Faithful to the astronaut, hostile unofficial station, limited carried oxygen/unlimited ship oxygen, unexplained revival, rescued community and alien-language premise. |
|||||||
| 20 | - Discovery first and expressive builds second are visible in player decisions; ordinary horde combat matters. |
|||||||
|
21 | - The two approaches create materially different player decisions and power payoffs beyond a single scripted event. Describe actual costs and limits without requiring symmetrical weaknesses or weakening spectacular builds to fit a template. |
||||||
|
22 | - Systems do not contradict one another, and the immediate goal and survival information remain understandable. |
||||||
| 23 | - Unknowns and the largest content/scope risks are explicit. The 30/90/100–200 hour ambitions remain unvalidated. |
|||||||
| 24 | - An independent review identifies any material objection and the author responds with reasons. Acceptance never requires unanimity. |
|||||||
| 25 | ||||||||
|
26 | Lead and Systems draft in parallel, with one writer per article. Before review, reconcile shared assumptions about carrying burden, extraction conditions and relevant hazards. PM resumes Lead for an integration pass once Systems is ready, then gives the reviewer the exact reconciled revisions. 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. |
||||||
