2026-09-10 17:26:19
Anonymous:
Remove review history and align superseded prose with current design rules
hold the flood/player information.md ..
@@ 1,168 1,5 @@
-
# Hold The Horde — Player Information
+
# Player Information
-
**Status.** A proposed information layer covering what the player is shown, what they may do about it, how the game confirms or refuses an action, and what the interface deliberately declines to work out for them. It follows the owner's selected opening, the owner-required journal pause and automatic-fire decision, and the current [Build Rules](/Hold%20The%20Flood/Build%20Rules), [Combat Rules](/Hold%20The%20Flood/Combat%20Rules), [Oxygen and Observation](/Hold%20The%20Flood/Oxygen%20and%20Observation), [Language and Journal](/Hold%20The%20Flood/Language%20and%20Journal), [Rescue Rules](/Hold%20The%20Flood/Rescue%20Rules) and [Death and Persistence](/Hold%20The%20Flood/Death%20and%20Persistence). Layouts, wording, control schemes and the accessibility baseline are proposals. This states an intended information policy; it does not establish that the policy is usable, legible or compliant with any standard, and no player has been observed.
+
The current interface and control proposal is [What the Astronaut Sees and Controls](/Hold%20The%20Flood/Player%20Information%20And%20Options). It covers combat cues, equipment editing, oxygen, records, rescue status and accessibility options.
-
## The information policy
-
-
**The interface presents readings, never conclusions.** Everything it shows carries its provenance and its known limit:
-
-
- **Direct observation** — what the astronaut can presently sense, including the face of an instrument they are standing at.
-
- **The player's own records** — what they framed and committed, with the place and the life it was taken in.
-
- **Attributed testimony** — a survivor's statement, their stated basis, and what is their interpretation.
-
- **Instrument and software reports** — a computed result shown as that instrument's claim with its limit stated. The ship's R-3 bearing is one: it reports a live pressure pulse in a direction, without distance or a walking route. Its detailed reliability and failure reporting remain to be designed; the separate pressure receiver's failure modes are not automatically this instrument's rules.
-
-
These are provenance labels, not four separate screens, and the line between them is not always sharp — a dial the astronaut reads is both an observation and an instrument's claim. What must never blur is **reading versus conclusion**.
-
-
Bounded computation is allowed and expected: a bearing derived from a pulse, a validity check on one proposed link, a labelled software suggestion that two already-captured records look alike. What is excluded is the conclusion — no translation of either script, no note marked right or wrong, no assertion that a route is safe or walkable, no map of ground the player has not covered, and no prediction of what an assembled rig will do.
-
-
**Where nothing is shown, nothing is available here** — no observation, record, testimony or instrument report bears on it. That is honest and useful, and it is weaker than it sounds: it is not evidence that the place is unvisited, unexamined or unrecorded, only that the player has nothing to hand.
-
-
## One expedition, six moments
-
-
The thread is the second expedition. The isolation bridge is aboard, so the ship can separate R-3's live pressure pulse from the collar fault, and the player is going to find the ward. The person in R-3 is called Yeva here for concreteness; she is the occupant of one of the two unselected versions in [First Survivor](/Hold%20The%20Flood/First%20Survivor), and nothing in this information flow depends on which version or which person the owner picks.
-
-
### 1. Preparing aboard
-
-
**Sees.** A manifest of everything carried against **overall carrying capacity** — canisters, rig parts and empty loot space in one shared total, as the owner required — and, separately, **active rig area**, which installation also consumes. The two figures are shown as two figures, because a part moved to inactive cargo frees area without freeing capacity. Suit condition. Stored records from the first life, each marked with the life it was taken in. One instrument report: R-3's bearing, a direction from the collar, no distance and no path.
-
-
**Action.** Repack; install or uninstall parts; decide whether the Fork Relay left at Cargo Turn is worth walking back for.
-
-
**Confirmation / refusal.** Ship-side editing is free and reversible; anything exceeding either figure is refused with the offending item still visible, never by silently dropping it. The Fork is listed as **installed at Cargo Turn**, not as carried property, so the player can see in advance why it will not come home if they die.
-
-
**Cannot infer.** Whether this loadout is enough, what the trip will cost in oxygen, or whether a route to the bearing exists at all.
-
-
### 2. Arranging the rig
-
-
**Sees.** Each part's ports, its inspected individual behaviour, and the links already drawn. Nothing about the assembly as a whole — no damage figure, no rating, no name for the build.
-
-
**Action.** Draw or cut one directed link between two visible ports.
-
-
**Confirmation / refusal.** Preview answers exactly one question: *is this proposed direct link between these two accessible endpoints valid?* A valid link previews and can be committed; an invalid one visibly refuses **before** commitment, at no cost. It does not evaluate the chain, warn of a bad idea or rank alternatives. Aboard this is instant; in the station the same edit is a world action with oxygen and threats running, and the journal's paused diagram cannot complete it.
-
-
**Cannot infer.** What the finished rig will do. That is the point: the player authored the causal path and finds out by firing it.
-
-
### 3. Moving, fighting and doing noisy work
-
-
**Sees.** Oxygen, condition and free capacity continuously. For each ordinary actuator, readiness and — when ready — the single highlighted target it has selected, the nearest visible valid hostile. For each storage part, its stored charge and how close it is to saturation. For each manual special, availability and facing. A reverse breadcrumb along passages actually traversed this life, back to the last confirmed anchor and ultimately the ship. A hit shows condition lost and any displacement it caused.
-
-
A jammed door **on the approach** — not R-3's, which is intact and cycles — has to be cut. Before the first bolt the interface shows the current stage, that this work is loud, which connected entrance will answer, and any caller present bracing to warn.
-
-
**Action.** Move, place the barrier, keep cutting, cancel, or leave.
-
-
**Confirmation / refusal.** Each completed bolt is a visible physical checkpoint that persists. Cancelling loses the unfinished stage and nothing else. An ordinary weapon with no valid target holds fire and says so by showing no highlight; it is not broken, and the fix is positioning.
-
-
**Design decision pending; this is not text shown to the player.** Whether the player may override or reselect the automatic target is not settled in Combat Rules or the Brief. This article does not decide it; if an override exists it needs its own readable state, and the display above assumes none.
-
-
**Cannot infer.** Whether the breadcrumb is still walkable, whether an unexplored passage is shorter, or how much oxygen the way home will take. It records where the astronaut's feet went and promises nothing else.
-
-
### 4. Capturing and comparing a clue
-
-
**Sees.** Above the three-way junction, `KETH SORAN VEL`, `SORAN KETH VEL` and `TAAN`. Framing a record shows the frame and the commit progress; the world keeps running while it completes.
-
-
**Action.** Frame and commit one still with its location. Then open the journal — at which point **the rest of the game pauses: enemies, oxygen, projectiles, alerts, weapon readiness and action progress, even mid-combat**, as the owner requires. Inside, pin two records side by side, highlight the swapped group by hand, and write a note.
-
-
**Confirmation / refusal.** Capture is atomic: interrupted before commit there is no record; completed, one still and one location persist through death as knowledge. An on-request visual suggestion may surface a lookalike among *already captured* records, labelled software-generated. The note is stored with its revision history and is never parsed, graded or scored.
-
-
**Cannot infer.** What any token means. The journal will not tell the player that `KETH` is "pump", will not mark a hypothesis supported, and cannot reveal a new angle, advance the scene or finish anything — the pause buys thinking time, not world time.
-
-
### 5. The short crossing, and returning alive
-
-
The short route from the airlock corridor through one junction to R-3 has now been walked in this arrangement and in this life, which is the condition First Survivor sets for offering the crossing. If that short geometry is absent, this scene waits rather than expanding into an escort route.
-
-
**Sees.** One rescue state at a time, each named with the physical fact that established it: **Waiting**, **Prepared** (travel air connected and confirmed by the survivor, next segment traversed this life, abort refuge stocked, the encounter quiet, a retreat line armed that they can operate alone, and the handed-over canister reading at or above the route's authored full-attempt return mark), **In transfer**, **At abort refuge**, **Sent** (aboard, airlock closed). A canister committed through the equipment sleeve leaves the manifest at commitment, visibly.
-
-
**Action.** Prepare, request movement, hold the junction, or call the abort. **Either party may call it** — the astronaut from outside, Yeva from her side — and the display names who did.
-
-
**Confirmation / refusal.** A request, a radio confirmation or a crossing in progress is never shown as Sent; only the closed airlock is. Flow confirmed through the sleeve is shown as *her* confirmation, not as a system check.
-
-
**Returning alive.** At the airlock: what came home and what did not — oxygen spent, the Fork still installed at Cargo Turn, new salvage on the manifest. Shown a captured record, Yeva's answer is recorded as her statement, her stated basis, and what is her interpretation. If the player linked a route to a predicted destination and walked it, the journal attaches one factual outcome — *arrived at linked destination*, *arrived elsewhere* with the place, or *attempt incomplete* with the interruption — and none of the three says the reading was right.
-
-
**Cannot infer.** Whether Yeva is correct, or whether one confirmed arrival generalises to any other inscription.
-
-
### 6. Reviving after a shift
-
-
A separate, later life: the astronaut dies on an ordinary expedition, with no transfer in progress.
-
-
**Sees.** Everything still carried at death is aboard — the owner's rule, shown as an ordinary arrival rather than an event screen. Through the airlock, R01 Dock Mouth, unchanged: the ship's threshold is fixed and never acquires a different neighbour. The first thing learned about the new arrangement lies one step further out — what is now beyond R01's outer unbound face, or, if that face is already latched, at the nearest free frontier of the ship-rooted group reached from it. All of that is current sensed information, seen by walking to it. Every walked route from the previous life is restyled as **historical** — still readable, still located relative to its anchor, explicitly no longer a claim about the present. Persistent facts stay listed as facts: doors unlocked, bolts released, parts installed, connections latched.
-
-
**Action.** Go out again and find out where things are.
-
-
**Confirmation / refusal.** The bearing reappears as a current direction, never a path. Historical records and live instrument reports are drawn differently; showing them together must not present historical positions as current ones.
-
-
**Cannot infer.** Anything about the new arrangement that has not been walked or sensed from where the astronaut stands. No revealed neighbour list, no map filled in off-screen, no hint that a direction is now correct.
-
-
## Decision and state table
-
-
| State | What the player sees | Action available | Confirm / refuse | Deliberately not inferred |
-
|---|---|---|---|---|
-
| Packing aboard | Capacity and active rig area as two figures | Repack, edit rig freely | Exceeding either is refused with the item visible | Whether the load suits the trip |
-
| Proposed link | Two ports and their inspected behaviour | Commit or cut one direct link | Invalid link refuses before commitment, at no cost | The behaviour of the whole chain |
-
| Carried vs installed | Item marked *carried* or *installed at a named place* | Retrieve by walking to it | Retrieval costs exposed world time | Whether retrieving it is worth it |
-
| Weapon ready, target present | Readiness plus one highlighted target | Reposition | Automatic launch spends readiness | Which target is tactically best; whether override exists (undecided) |
-
| Weapon ready, no target | Readiness, no highlight | Reposition | Holds fire; nothing is wasted | Where a target will appear |
-
| Storage part | Stored charge and saturation | Configure its chosen release trigger; manually release only when so configured | A manual release starts a new wave; a rig-triggered release retains that packet's wave | Whether now is the moment |
-
| Noisy staged work | Stage, checkpoints, cued entrance, bracing caller | Continue, cancel, defend | Completed checkpoints persist; unfinished stage is lost | How many will actually come |
-
| Journal open | Frozen view and stored records | Pin, highlight, annotate | Nothing completes; readiness does not advance | Meaning, correctness, translation |
-
| Route walked this life | Reverse breadcrumb to last anchor | Follow it back | Records passage, not safety | Continued access or oxygen cost |
-
| Route from an earlier life | Same record marked historical | Read it, plan from it | Clearly distinguished from live claims | Whether it still connects |
-
| Instrument report | Current reading and that instrument's stated limit | Act on it | A fresh measurement is a current claim; earlier reports remain historical | Distance, route, walkability or sensor health beyond what it actually reports |
-
| Rescue | One named state and the fact behind it | Prepare, move, abort | Only a closed airlock reads Sent; abort names who called it | Whether the next segment will hold |
-
| After death | Carried manifest aboard; the room now beyond the airlock | Resume | Installed and consumed items stay as they were | The rest of the new arrangement |
-
-
## Late-game states, conditional on an unchosen mechanism
-
-
[Connecting The Station](/Hold%20The%20Flood/Connecting%20The%20Station) explains the current discovery direction. The pulse and roster displays below belong to the conditional technical candidate in [Death Shift And Rescue Continuity](/Hold%20The%20Flood/Death%20Shift%20And%20Rescue%20Continuity) and [Station Room And Module Inventory](/Hold%20The%20Flood/Station%20Room%20And%20Module%20Inventory); the joining mechanism and completion display remain proposals:
-
-
| State | What the player sees | Not inferred |
-
|---|---|---|
-
| Latch preview | Whether these two adjacent faces can exchange the pulse, and on refusal the visible reason — for example two opposing output arrows | Whether some other face elsewhere would work |
-
| Three states kept distinct | Walking connectivity, persistent join, and current diagnostic signal shown separately | That losing diagnostic power has undone a join |
-
| Latch roster | Counts of regions joined to the ship-rooted network, discovered but not joined, and anonymous registered regions not yet encountered | Any name, face, route or location for an anonymous region |
-
-
The proposed roster reveals that hidden spaces exist by publishing their count. This spoiler cost is described in [Station Room And Module Inventory](/Hold%20The%20Flood/Station%20Room%20And%20Module%20Inventory), and the display remains a proposal. The information rule it must obey is narrower and belongs here — **a persistent join stays known after death, because it is a fact about work already done; it must not thereby reveal an unbound adjacency the player has not yet seen.** Knowing the network is incomplete is not knowing where the gap is.
-
-
## The short rescue, and its open question
-
-
Rescue state reports **what has been confirmed**, and separates confirmation from outcome. Each state label retains whether its basis was directly witnessed or confirmed by the survivor or an instrument, with that report's limit. A survivor's flow confirmation is not silently promoted to the astronaut's direct observation.
-
-
**The factual limit stands; its reason has changed.** The ordering of a death-triggered shift against an in-progress transfer now has a conditional answer in [Death Shift and Rescue Continuity](/Hold%20The%20Flood/Death%20Shift%20And%20Rescue%20Continuity): an eligible survivor with an armed retreat reaches the named abort refuge alive and unsent, before the shift. **That changes the world, not the display.** The abort door leaves a closure tell on that refuge's local control only, and nothing is transmitted aboard — so on revival the astronaut still has only the last witnessed state and the fact that the safeguard was armed. The display must therefore still report the **last confirmed state** and mark present location and outcome **unconfirmed**, and it must not assert a refuge result the astronaut has not observed. The uncertainty is no longer 'no article establishes it'; it is that no instrument or channel reported it. Current proof comes from reaching that refuge again and observing its control or occupant in person, which reveals nothing about the route beforehand. The safeguard itself remains pending owner reaction.
-
-
## A proposed accessibility baseline
-
-
Design proposals with their expected costs. Not demonstrated usability, not a conformance claim, and the costs below are reasoned expectations rather than measured ones.
-
-
- **Full remapping and input alternatives.** Every action rebindable; no action requiring a simultaneous three-input combination; hold actions available as toggles; staged work completable without repeated rapid input. *Expected cost:* the "hold to keep cutting" tension weakens where a toggle replaces it, and each added control path multiplies the states that must stay readable.
-
- **Readable text.** Scalable interface text with a minimum size, adjustable contrast behind it, and no essential information carried only by a small in-world painted label. *Expected cost:* larger text crowds the compact suit display, and some diegetic character is lost when a value must also exist as plain text.
-
- **Colour-independent status and cues.** Every state that matters — readiness, valid target, valid versus refused link, carried versus installed, live versus historical — carries shape, position, pattern or text as well as colour. *Expected cost:* authoring discipline on every new cue and a busier display. The candidate's service signatures are currently described by colour and count; a non-colour distinguishing form would need designing in.
-
- **Alternatives to essential audio.** The caller's brace, the door grind, the connected entrance answering and alert sources each need a visible equivalent including direction. *Expected cost:* visualising directional sound can hand over spatial information that hearing players must infer, so these need tuning to match the audio cue rather than exceed it.
-
- **Presentation-intensity controls.** Reduced camera shake and flash, a cap on simultaneous full-screen effects, and an option to damp the visual density of a large horde without changing enemy numbers or difficulty. *Expected cost:* a spectacular build's payoff is partly its spectacle, so damping it plausibly reduces that payoff for players who need the option. Whether it materially costs the owner's build priority is not established here and would need observation.
-
-
Two of these — non-colour signature forms and non-audio directional cues — are cheaper to design in now than to retrofit once puzzle and encounter content is authored. That is an ordinary authoring expectation, not a costed engineering claim.
-
-
## Effort, stated in role-hours
-
-
Both estimates below are kept visible because they cover **different deliverables**, and neither is adjusted to agree with the other.
-
-
**The outline's row.** [Whole Game Outline](/Hold%20The%20Flood/Whole%20Game%20Outline) allows **8–16 author role-hours** for the UI and accessibility information contract: paper states and flows with no usability claim. That is this article's first-pass deliverable. The allowance is a planning estimate, not a timesheet. The author's later **4–8-hour closure estimate** was made before submitting the consolidated response and included that response; it must not be added as remaining work after PM preparation closeout.
-
-
**The larger deliverable my earlier figure described.** My first estimate — 8–14 design days plus 3–5 — was a broader scope, bundled authoring with review, and was given in days. Restated at six productive role-hours per day, and rescoped to authoring only:
-
-
| Follow-on work | Author role-hours |
-
|---|---|
-
| Complete cue-by-cue inventory with non-colour and non-audio equivalents | 12–20 |
-
| Journal and manifest structure at screen level — structure, not screens or art | 8–14 |
-
| Accessibility option list with defaults and their interactions | 6–10 |
-
-
Author subtotal **26–44 h**; a roughly one-third allowance of **9–15 h** for focused review and author response gives **35–59 role-hours**, about 6–10 days at that rate. Allocation of that combined allowance between reviewer and author remains to be estimated. **This is a reduction from my first figure**, and the reduction comes from separating the first-pass contract (the outline's row, largely done) from the inventory that follows it, and from removing review effort I had silently folded into an authoring number.
-
-
**Conditional increment.** If the shift-timing question is answered such that survivor-location uncertainty becomes a real state, the information-layer work is **8–14 author role-hours**: the state itself, its cues, and its effect on route and roster displays. Down from 3–5 days, because I previously included rescue-rule design that is not mine to do and should not be counted here. This conditional author range excludes separately estimated independent review.
-
-
These are estimates of writing and reviewing by someone with no implementation experience of this project. They are not a schedule, and they cover no engineering, art or validation.
-
-
## What later validation would have to settle
-
-
Whether the suit display is legible under horde pressure; whether players read an instrument bearing as a route despite its distinct treatment; whether the historical marking actually stops them trusting a stale record; whether the link preview teaches the grammar or merely gates it; whether the journal pause is used for thought or for safety; whether a published anonymous-region count reads as a spoiler or as a goal; and whether any accessibility option here helps the players it is meant for. Each needs later owner-authorised implementation and observation with real players, including players who use those options by necessity. None has occurred.
-
-
## One review finding not adopted
-
-
The review asked this page to state plainly that no screen other than the journal pauses. It does not, because that would settle something the owner has not. The owner's decision covers the journal; Oxygen and Observation records explicitly that the requirement "applies to the journal, not automatically to every other menu." General menu and pause behaviour remains unchosen, and this page confines itself to the one pause that is decided — while keeping field rig edits and record capture in running world time, as their own articles require.
+
[Build Rules](/Hold%20The%20Flood/Build%20Rules) explains mounted-link editing in the paused journal, live physical installation and the build preview. [Language and Journal](/Hold%20The%20Flood/Language%20And%20Journal) explains recording and comparing evidence.
