Home A - Z Create page
Page Index

An Otter Wiki

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 bounded implementation/evidence packet uses the existing R01 Dock Mouth → R02 Cargo Turn ⇄ R03 Collar Control opening, E01/P01, the one Fork and isolation bridge, the four-part opening rig, current oxygen/capacity quantities and two deliberately different legal configurations. A second authored local arrangement exposes existing R09 Release Walk at R01's changed free frontier after death while preserving the compact R02/R03 group. Its size is an evidence scope, not a promised vertical slice, a new content slice or final opening. It should expose the discovery/build/crowd/persistence tradeoffs before the team authors or implements 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 and the catalogue. 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 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 And Options, 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. Do successive expeditions continue to offer new discoveries and build decisions? Specify a representative sequence with connected objectives, meaningful revisits, clue consequences and part acquisition. Record the different decisions each return is intended to unlock; keep repetition and adjacency-hunting risks visible. Once the required content and phase are authorized, observe real players across that sequence: what understanding and builds change, why they choose another objective, what earlier knowledge they reuse, and where repetition replaces a new decision. Keep this player evidence separate from authoring-cost and hardware measurements. If novelty or build choices run out, reopen reuse, gates, acquisition cadence or the content band before expansion. Mixed results call for a narrower comparison of the suspected cause, not a favorable average that hides it. A positive result supports this sequence and these players only; it does not establish the full campaign's depth or the30/90/100–200-hour ambitions.
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.

Proposed first bounded implementation/evidence packet — unauthorized

This packet is concrete enough for a future owner phase decision, but no implementation, prototype, simulation, technical test, asset work, recruitment or player session is authorized now.

Revision-specific dependency set

Campaign36 is not a packet dependency: its evidence crosswalk is still under focused correction. This packet uses only the already accepted R-3 window observation and its stated limit; it does not copy the pending evidence-entry count.

Player decisions and included content

The future packet would implement only these existing definitions and states:

  1. Prepare. At the ship, choose the proposed retrieval-ready or air-heavy manifest under 10 C/4 A, with the four opening parts, one or two 8 O canisters and the 12 O suit. The display separates C, A, exact O and the player-set reserve defaulting to 4 O.
  2. Observe and choose at R02. Read the board outputs, P01 preview, Fork location, bridge size and noisy final stage. Choose either:
    • keep Threat Sensor → Pulse Projector automatic fire and Manual Trigger → Barrier Plate, then install Fork in the board so rack and shutter hold; or
    • reclaim and fit Fork as Sensor → Fork → Projector + Barrier, moving Manual Trigger inactive, losing manual Barrier timing and leaving the infrastructure selector to hold only one branch. The one independent ordinary-launch rule, world-time edit and carried-versus-installed cost stay visible.
  3. Act under E01 pressure. Two separated Pressers, one Caller and P01 supply the accepted finite crowd. Automatic Projector fire, deliberate Barrier use, the Caller warning, the noisy fastener and the option to cut/dog/withdraw create a meaningful crowd/work decision. The journal fully pauses oxygen, enemies, warnings, readiness and work without completing any of them.
  4. Commit or withdraw. Completed fasteners, alarm/dog work, board state, Fork location and bridge location persist. The player may extract the 2 C bridge, leave it, or retreat after a checkpoint. Oxygen transfer, breathing and reserve cues use the accepted proposed arithmetic without claiming balance.
  5. Return or die and revisit. A living return keeps the current arrangement. A death returns every still-carried object once, leaves installed Fork and uncollected bridge at their actual locations, keeps spent gas spent, loses only an unfinished stage and shifts once. R01 remains fixed; R02/R03 remain a compact pair; the limited alternate places existing R09 Release Walk at R01's free frontier to demonstrate changed unbound adjacency without pretending to solve the 40-room generator or implementing R09's wider O3 dependencies.

Normal case. Install Fork in R02, finish enough work to free and carry the bridge, survive to R01, and return alive. Revisit in the same arrangement to see exact committed work and reclaim or leave the one Fork.

Contrary/recovery case. Keep Fork carried or die after one committed fastener but before bridge pickup. The carried set returns once; installed/dropped/source objects do not teleport; the unfinished stage is lost; the compact pair remains intact while R01's free frontier changes. The player follows current cues to rediscover the known compact apparatus and continue from the committed checkpoint. A duplicate item, restored spent gas, broken compact group, invisible shot, journal-time completion or silently lost object is a correctness failure, not a harsher variant.

Explicit exclusions and pending choices

No survivor, rescue transfer, home project, language chain, story/core answer, final connection, R26/R33 converter, special enemy, R08/E03/P03 content beyond R09's corridor identity, full save-slot policy, full forty-room arrangement space or Campaign36 evidence ledger is included. The five owner choices—40/40 stabilization, Yeva/Aster first, found working parts versus fabrication, continue-before-departure versus permanent ending, and protected alive/unsent retreat—can remain unresolved because none changes this bounded R01–R03 correctness/experience question. The packet adopts no retained-charge-across-death rule.

Assets, if separately authorized, are limited to categories needed to communicate this scope: modular corridor/room surfaces and doors; astronaut, Presser and Caller representations with required silhouettes/animation tells; equipment/board/bridge props; UI type/icons; warning/impact/Barrier effects; and directional/non-directional audio equivalents. Candidate assets must be free, legally suitable and substitutable without losing mechanical cues. No AI-generated art, purchase or rare custom-authored asset is assumed. If suitable substitutions are unavailable, visual-fidelity questions are cut or the owner receives a concrete asset exception request before work expands.

Correctness evidence versus player evidence

Technical correctness checks ask whether the authored rules execute consistently: one ordinary launch per reservation; no causal-wave recursion; pause freezes without completing; exact O/C/A accounting; one-location object conservation; fastener/alarm/board commit boundaries; carried return; installed/source persistence; one shift; fixed R01; preserved R02/R03 compact pose; historical versus current route labels; suspend/resume only if that behavior is authorized in the packet. These checks can reveal a contradiction or defect. They cannot establish discovery, readability, tension, balance, accessibility or fun.

Later real-player evidence, only after separate authorization and recruitment, asks whether unfamiliar consenting players notice the board/Fork relationship, form a packing intention, understand why their chosen rig behaves differently, use automatic fire and manual Barrier deliberately amid the crowd, use the journal pause without losing state understanding, predict return/death property results and explain the local shift. Record assistance, device/options used, actions, explanations and contrary cases. Do not script the inference and then count compliance as discovery. A small sample diagnoses problems; it does not prove population rates or campaign duration.

Proposed responsibilities and staged deliverables

These are responsibilities to staff, not claims that a team, Unity expertise, hardware, assets or players already exist.

Stage Proposed responsible functions Deliverable and stop decision Effort / elapsed assumption
A. Contract and technical plan Implementation lead, Systems, content/level owner, UI/accessibility owner, technical reviewer Revision-locked state/identity/scene list, target hardware/input assumptions, asset substitutions and correctness cases. Stop if the rules or ownership cannot be made finite without reopening a core decision. 24–40 role-hours; 3–5 working days
B. Minimal runtime/content assembly Unity-capable developer(s), level/content implementer, UI/audio implementation R01–R03 plus R09 corridor identity, E01/P01 subset, two rig configurations, oxygen/journal, commit/property and two local arrangements; instrumentation sufficient for later evidence. Do not add another room/part/enemy to hide a failure. 120–200; 3–5 weeks
C. Correctness and recovery Technical QA/reviewer with Systems disposition Reproducible boundary results and defect ledger for normal and contrary cases across supported target conditions. Block player evaluation on duplication/loss, broken pause, invalid shift or unreadable required state. 40–70; 1–2 weeks, partly overlapping B
D. Player evaluation, separately authorized Research facilitator, accessibility input, session support, PM/design disposition Session protocol fixed before results, consent/recruitment record, observations/limitations and explicit keep/revise/cut decision. 35–60; 1–2 weeks after participants are available
Asset/cue integration allowance Art/audio/UI implementers using approved free sources Necessary silhouettes, tells and equivalent channels only; source/license record and substitution list. 70–120; overlaps B/C

Total future packet allowance is 289–490 role-hours, with a rough 5–8 elapsed working weeks after a named 3–5-function team, target conditions and asset plan are actually available; recruitment lead time is unknown and not hidden inside that range. Confidence is low because no implementation team, hardware, asset suitability, pipeline throughput or revision burden has been established. Combining functions may reduce handoffs but not the unique work; staffing fewer people lengthens elapsed time. This is not a development start forecast and does not alter the PM's M3/M4 documentation dates.

Expansion and rejection decisions

  • Stop and repair before player sessions if any correctness blocker remains.
  • Revise within the same packet when cues or geometry obscure the intended decision but the contracts remain sound; record the exact change so comparisons remain interpretable.
  • Prefer the smaller direct Sensor→Projector rule if early Fork branching cannot be explained without a solved recipe or consistently creates accidental control loss.
  • Cut or isolate the local shift comparison if a valid two-arrangement subset cannot preserve identities/recovery without importing the full station architecture.
  • Expand to another objective, special enemy, rescue, language chain or connection challenge only after the named packet answers its decision and the owner authorizes the next scope. A positive result supports this content and these participants only.

Full-v1 readiness still requires Campaign36's accepted crosswalk, scope37 critique/response/disposition and one whole-v1 coherence disposition. M3 is not closed by this article. The PM's F1.14 forecasts remain M2 11 September (10–14), M3 14 September (11–18), and M4 10 November (20 October–1 December). There is no authorized development start date or defensible validated-full-game completion date; the owner's 30/90/100–200-hour ambitions remain unproven.