Commit 6977c5
2026-09-08 17:42:57 Anonymous: Publish first-pass development and validation handoff for focused review| /dev/null .. hold the flood/development and validation handoff.md | |
| @@ 0,0 1,50 @@ | |
| + | # Hold The Horde — Development and Validation Handoff |
| + | |
| + | **Status: first-pass proposal, plan only.** This article orders the evidence the team will need before committing to the full game. It authorizes no implementation, prototype, simulation, assets or player test. Current work remains design only. The owner decides when to enter another phase and its scope. No AI art is permitted, including concepts and placeholders. |
| + | |
| + | The design aims to make discoveries change what the player understands and does, while reusable equipment produces expressive builds and hordes give those builds meaningful work. Written examples demonstrate possible choices. They do not establish that those choices are enjoyable, readable, balanced, technically feasible or capable of sustaining the desired campaign length. |
| + | |
| + | ## The next phase should answer a few consequential questions |
| + | |
| + | The proposed first playable experiment is one small expedition with an observation that changes a later use, two contrasting legal rigs, an ordinary crowd, a mechanism, a return/death and one local shift. Its size is an evidence scope, not a promised vertical slice or final opening. Use the current selected opening direction and existing free assets only when their use is appropriate and authorized. It should expose the central tradeoffs before the team authors an entire campaign around them. |
| + | |
| + | Do not build that experiment yet. Finish a readable core contract, identify the exact unresolved alternatives it would compare, and give the owner a concrete implementation scope and estimate first. A full v1 wiki is needed for a complete development handoff, but a separately bounded early experiment could be authorized before v1 if its dependencies are sufficiently specified. Neither waiting for every detail nor assuming early authorization is the default. |
| + | |
| + | ## Prioritized risk and evidence map |
| + | |
| + | These priorities reflect dependency and the cost of being wrong, not measured risk probabilities. Every later study needs a recorded source revision, a specific question, an observation plan and a decision it can change. The outcomes below are interpretations to examine; they are not claims that those results have occurred. |
| + | |
| + | | Priority and question | Preparation possible in design now | Smallest useful later evidence | What contrary results would change | |
| + | |---|---|---|---| |
| + | | **1. Can discovery remain the main experience during oxygen pressure and hordes?** | Specify one observation, two plausible interpretations and an action whose useful consequence differs between them. Protect thought with the full journal pause. | With real consenting players unfamiliar with the solution, observe a small expedition with both ordinary travel crowds and a quiet observation opportunity. Record what they notice, why they change approach and where they abandon inquiry. Compare a specific pacing alternative if attention repeatedly fails. | If players can act on the discovery but mainly experience waiting or interruptions, change encounter placement/observation access before adding clues. If they never infer the useful relationship, change evidence rather than simply remove pressure. Do not interpret a successful scripted instruction as discovery. | |
| + | | **1. Do the parts permit player-created builds rather than a few authored recipes?** | Reconcile controllers, payload allocation, storage, readiness, fixture interfaces and carrying costs using [Build Rules](/Hold%20The%20Flood/Build%20Rules) and the [catalogue](/Hold%20The%20Flood/Equipment%20Catalogue). | Offer a bounded common part set and the same objective to real players, without supplying the three example rigs. Record their intended effects, actual constructions, revisions and uses. Separately exercise feedback/readiness boundaries in implementation. | If materially different constructions achieve intended purposes, preserve that freedom even when ordinary crowds become easy. If one construction dominates every relevant cost or other combinations cannot be understood, revise interfaces, encounters or parts. A high build count alone is not diversity or fun. | |
| + | | **1. Do shifts preserve mystery while permanent connections produce mastery?** | Supply at least two feasible small station constructions, a wrong-join recovery and explicit identity/persistence rules. Keep final-layout behavior visibly conditional on the owner's choice. | After authorization, inspect generated/authored state transitions and let players revisit a small shifting area, then deliberately assemble a useful group. Observe their explanation of what changed, retained work and next chosen objective. | If players cannot distinguish changed geography from lost progress, fix identity cues/rules. If desired adjacencies cause repeated unproductive deaths, compare a bounded alternative rather than add death penalties. A solved small construction does not establish the whole-station puzzle's depth or duration. | |
| + | | **1. Can every death/save transition preserve the promised state?** | Write the separate save/identity contract: carried versus deposited/installed/consumed objects, completed work, historical records, joins and unresolved survivor outcomes. Name the commit boundaries. | Technical checks around interruption/save/resume at those boundaries, followed by reproducible recovery checks. Test each resolved transition and combinations that could duplicate, lose or roll back state. | A duplicated or missing carried item, repaired cut bolt, lost confirmed join or invented survivor result blocks expansion of the affected state system. Fix the contract or implementation before writing many dependent scenes. This article does not choose the unresolved rescue order. | |
| + | | **2. Are oxygen and carrying decisions legible and worth making?** | Use [Survival And Loadout](/Hold%20The%20Flood/Survival%20And%20Loadout) to distinguish capacity, active rig area, fill, prepared surplus and spent resources. Define two viable packing intentions. | In the same small expedition, ask players to choose a loadout, judge a return/continue decision and explain transfer/refill outcomes. Observe mistakes and their causes, including interrupted actions and journal use. | If decisions are understood but oxygen mainly forces repetitive travel, change quantity/route opportunities. If amounts or states are misunderstood, fix the explanation first. Do not silently discard retained gas or add loot loss to create stakes. Deliberate death may remain a legitimate chosen return. | |
| + | | **2. Can players read and control meaningful horde combat?** | Specify valid automatic targets, manual special inputs, warnings, cover, displacement and local causes of arrivals. Preserve clean victories by strong builds. | Observe the same crowd under two different legal builds and readable density conditions, including a warned special enemy or trap. Compare what players believed would happen with actual targeting and interruption. | If automatic targeting defeats intended positioning, revise targeting/feedback before adding mandatory manual ordinary fire. If cues vanish in density, reduce or separate competing effects. Enemy health alone does not resolve unreadable causes. | |
| + | | **2. Do language clues support a warranted change of belief?** | For each representative chain, list observed evidence, competing readings, the discriminating action, correction route and useful later consequence. Separate an operational response from proof of a request, person or god. | Test a small chain with unfamiliar real players; record hypotheses before and after evidence and whether they can use the result in another context without being told its answer. | If the chain supports several meanings equally, strengthen discriminating evidence or retain honest ambiguity. If players solve by interface labels rather than observation, revise those labels or the learning objective. Agent agreement about a fictional sentence is not player evidence. | |
| + | | **2. Does one short rescue create interest in a person and life aboard?** | Resolve one specific living/abort/death crossing contract and write a motive, disagreement and later contribution for the selected survivor. Preserve the owner's short-rescue direction. | Observe the bounded rescue and a short later home interaction. Ask what the player remembers, expects and wants to do with that person; measure the actual crossing burden rather than calling it short. | If the person is remembered only as a mechanical unlock or the rescue feels like an escort chore, change character interaction and crossing before extending the cast. Do not create survivor mortality or a colony upkeep tax merely to manufacture concern. | |
| + | | **2. Can essential information work through the chosen accessible controls and cues?** | Produce the cue/interaction inventory from [Player Information](/Hold%20The%20Flood/Player%20Information), including alternative channels, input options and unavailable/unconfirmed states. Keep factual limits equivalent. | After implementation authorization, inspect the actual supported input/display modes and evaluate relevant tasks with real consenting players, including people who use the intended accessibility options. Define representative devices and conditions before claiming coverage. | If a cue only works through one unavailable channel, add a useful equivalent without revealing hidden routes, translations or conclusions. A simulator, checklist, narrated agent walkthrough or a second visual cue cannot by itself establish accessibility. | |
| + | | **3. Can the finite campaign be authored and run within a chosen production scope?** | Deduplicate the SMALL inventory, name reuse and state complexity, identify asset categories and target-platform constraints, and prepare explicit scope cuts. | After authorization, author representative room/puzzle/encounter/cast content through the actual pipeline and measure revision burden. Run representative technical workloads on specified target hardware, including hordes, connected builds, shifts and save state. | If content or technical cost is too high, cut repeated variants or simplify costly systems before extrapolating to the campaign. Re-estimate using actual distinct work and reuse. External game length, agent writing speed and room counts do not demonstrate our playtime or performance. | |
| + | |
| + | Story endings and resurrection consequences remain owner choices. Evidence can show whether a proposed causal chain is understandable and what tradeoff an ending communicates; it cannot decide the owner's preferred theme by majority vote. Irreversible consequences require a visible decision boundary in the design before they appear in any later experiment. |
| + | |
| + | ## Handoff gates and responsibilities |
| + | |
| + | 1. **Design package ready for a phase decision.** PM assembles the exact core article revisions, selected owner requirements, provisional defaults, unresolved interfaces and a bounded proposed build scope. Systems supplies observable mechanical contracts; the responsible narrative/campaign author supplies the clue and scene; a reviewer checks dependencies and contrary cases. Uncreated future specialists are not counted as available staff. |
| + | 2. **Owner authorizes a named scope.** The owner chooses whether to proceed and which implementation, technical checks, assets and player evaluation are included. Approval of the wiki or of this plan is not approval of all later activities. Purchases and rare custom assets remain separate owner decisions. Prepare costs, staffing and deliverables before seeking that decision; no permission question is being asked by this article. |
| + | 3. **Implement and inspect the permitted small scope.** The responsible developer demonstrates state correctness and enough observable behavior to answer the chosen questions. Technical checks do not establish player experience. Stop expansion when a core contradiction prevents a meaningful trial; do not hide it with a scripted successful path. |
| + | 4. **Obtain the permitted evidence, then disposition it.** Record task conditions, participant experience, assistance, failures, observations and limitations. Distinguish behavior from interpretation. PM and the relevant designer state which belief changed, which contrary evidence remains and what decision follows; the owner retains creative and scope authority. |
| + | 5. **Expand only the justified scope.** Use what was learned to revise v1, estimates and the next concrete package. A positive small trial supports that setting and population, not the entire campaign, all accessibility needs or the 30/90/100–200-hour ambitions. |
| + | |
| + | Before a trial begins, choose operational measures and decision thresholds appropriate to its question. Do not invent a universal pass percentage now or set success criteria after seeing favorable results. Small qualitative sessions identify problems and hypotheses; they do not support precise population claims. Use representative differences rather than recruiting a quota that cannot answer the question. No recruitment or contact with testers is currently assigned. |
| + | |
| + | ## First handoff packet |
| + | |
| + | The packet must name its owner, exact design revisions, intended player decisions, included/excluded states, equipment/content/assets, target conditions, open assumptions, implementation and evaluation work, stop criteria and output artifacts. Include both a normal case and a plausible failure/recovery case. For any comparison, say what differs and keep irrelevant changes limited enough to interpret the result. Keep a path to reject or simplify the proposal; the purpose is to reduce uncertainty rather than confirm the team's favorite design. |
| + | |
| + | Full-v1 readiness additionally requires every major area in [Design Coverage](/Hold%20The%20Flood/Design%20Coverage) to have an actual first-pass design and compatible interfaces. This evidence plan does not close the separate save/authoring contract, content inventory, asset suitability review or detailed campaign specification. |
| + | |
| + | **Planning estimate for this first-pass plan:** PM authoring4–8 role-hours, one independent review2–3 and one author response1–2; total7–13. This narrower first pass contributes to the outline's original6–12-hour authoring allowance; do not add both in full. Later completion of the v1-specific handoff packet needs a fresh remaining-work estimate once its sources and implementation scope exist. Technical implementation, test execution, recruitment, assets, player sessions and detailed production planning are excluded and unestimated here. These are planning allowances, not measured labor or calendar turnaround. |
| + | |
| + | The wiki v1 forecast remains22 September2026, likely18–29 September. There is no authorized development start date or defensible date for validated full-game completion. Estimate the next permitted experiment when a concrete scope and available development team can be reviewed, rather than transferring a documentation forecast onto game production. |