From e90ab07e64c356af1c121a1a3beb68c8ad3097f2 Mon Sep 17 00:00:00 2001 From: Frank Tovar Date: Thu, 14 May 2026 02:12:26 +0200 Subject: [PATCH] Align campaign with core design rules --- docs/CAMPAIGN.md | 856 ++++++++++++++++++++--------------------------- docs/design.md | 151 +++++---- 2 files changed, 459 insertions(+), 548 deletions(-) diff --git a/docs/CAMPAIGN.md b/docs/CAMPAIGN.md index cbf3eeb..e794dd9 100644 --- a/docs/CAMPAIGN.md +++ b/docs/CAMPAIGN.md @@ -1,757 +1,641 @@ # Reactor Maintenance Campaign Design -This document prepares the handcrafted campaign for implementation. The scope is a two-week game jam, so the campaign favors small, readable levels that reuse the same props in increasingly demanding combinations instead of requiring a large set of bespoke mechanics. +This document prepares the handcrafted campaign for implementation. It references `docs/design.md` terminology directly; campaign text should not introduce mechanics that are absent from the design document. ## Campaign Goals -- Teach one concept at a time, then ask the player to combine concepts under pulse pressure. -- Keep movement, inspection, and all-seeing-eye use calm and free. -- Make every environment-changing action produce one pulse. -- Make the tutorial a single-action demonstration. -- Make campaign levels increasingly choice-rich: early levels have a small number of plausible actions, mid levels have tradeoffs, and late levels require sequencing. -- Avoid dead-end puzzle states unless the level is already lost by terminal rules. -- Keep every level authorable with existing grid, network, prop, leak, door, sprinkler, terminal, remedy, and reactor concepts. +- Teach one `LengthyAction` grammar at a time, then combine systems. +- Keep `MoveRobot`, inspection, and visible-state reading calm and free. +- Make every environment-changing action trigger exactly one `Pulse`. +- Keep `Forecast` output systemic and available only at an active `AllSeeingEyeTerminal`. +- Avoid treating missing `ReactorReadiness` as a failure state; it only blocks `Ready`. +- Use `UnsafeEntryLoss` only when `MoveRobot` enters an unsafe destination `SurfaceHazard`. +- Keep the campaign small enough for a two-week game jam. ## Campaign Structure -The campaign uses one tutorial plus seven level groups. Each group contains three levels with increasing complexity. +The campaign uses one tutorial plus six groups. Group 1 intentionally has two levels; Groups 2-6 have three levels each. | Group | Levels | Networks | Main Lesson | | ----- | ------ | -------- | ----------- | -| Tutorial | 1 | Fuel | A lengthy action triggers a pulse, then reactor activation wins. | -| 1 | 3 | Fuel | Pressure-fed leaks, isolation, repair, reactor feed, and startup timing. | -| 2 | 3 | Coolant | Consumers, service starvation, sprinkler water, evaporation, and pressure tradeoffs. | -| 3 | 3 | Electricity | Voltage-fed leaks, wall access, doors, terminals, and routing risk. | -| 4 | 3 | Fuel + Coolant | Heat, suppression, evaporation, and fuel dilution. | -| 5 | 3 | Fuel + Electricity | Ignition, electrical containment, and fuel source control. | -| 6 | 3 | Coolant + Electricity | Wet conduction, drying through evaporation, and terminal-informed routing. | -| 7 | 3 | Fuel + Coolant + Electricity | Full reactor startup with all cascades present. | +| Tutorial | 1 | `Fuel` | `LengthyAction` triggers `Pulse`; `Ready` then `ActivateReactor` wins. | +| 1 | 2 | `Fuel` | `FlowProp`, `IsolationValveProp`, reachable leaks, and direct `ReactorReadiness`. | +| 2 | 3 | `Coolant` | `ConsumerProp`, `Producing`, wall-mounted `CoolantSprinklerValve`, `SprinklerWater`, pressure recovery. | +| 3 | 3 | `Electricity` | wall `Electricity` leaks, repair faces, powered `DoorProp`, and `AllSeeingEyeTerminal`. | +| 4 | 3 | `Fuel` + `Electricity` | first dual-system interaction: `Ignite` creates recurring `Heat`. | +| 5 | 3 | `Coolant` + `Electricity` | `SprinklerWater`, `Evaporation`, and wet-electricity `Conduct` risk. | +| 6 | 3 | `Fuel` + `Coolant` + `Electricity` | full startup with fire, suppression, wet conduction, and terminal-local `Forecast` use. | ## Authoring Rules -Every non-tutorial level must name at least two plausible first lengthy actions. The later the campaign, the more often both first actions should be valid but lead to different second-step obligations. +Before `AllSeeingEyeTerminal` appears in 3-3, all levels must be readable from surface props and visible effects alone. Use simple branches, clear source positions, visible leak access, and obvious valve placement. -Level timelines describe intended reasoning, not forced scripting. If a player finds a different valid sequence, the systems should allow it. +Every non-tutorial level must offer at least two plausible first `LengthyAction` choices. The later the group, the more those choices should require sequencing rather than a single obvious answer. -Choice count should grow roughly like this: - -- Tutorial: one prompted lengthy action. -- Group 1: two plausible first actions and a short recovery sequence, with no required consumers yet. -- Group 2: two to three plausible first actions, introducing consumers and making starvation visible. -- Group 3: three plausible first actions and information or containment tradeoffs. -- Groups 4-6: three to four plausible first actions, with two-network consequences. -- Group 7: four or more plausible first actions and multi-pulse sequencing. - -## Level Format - -Each level should be implemented with: - -- one clear reactor control site, -- only the networks listed for its group, -- a compact reachable floor plan, -- forecast text for the most important selected actions, -- visible failure cause when lost, -- no required fast-forward action. +Do not author level-specific forecast strings. The campaign can require that systemic `Forecast` output is useful, but the level spec must describe the underlying state that fixed forecast rules can detect. Each level below includes: - `Purpose`: the reason the level exists. - `Setup`: authored starting conditions. -- `Timeline`: intended chronological choices and pulse consequences. -- `Win`: exact success condition. -- `Lose`: intended failure pressures. -- `Implementation Notes`: content details that matter when building the level data. +- `Timeline`: intended reasoning and `Pulse` consequences. +- `Win`: required `ReactorReadiness` and `ActivateReactor` condition. +- `Lose`: terminal failure or `UnsafeEntryLoss` conditions. +- `ImplementationNotes`: content constraints for level data. ## Tutorial: First Pulse ### T0 - Wake The Feed -Purpose: Teach that an environment-changing action triggers a visible pulse and can make the reactor ready. +Purpose: Teach that one accepted `LengthyAction` triggers one `Pulse`, after which `Ready` can be activated. Setup: -- Networks: fuel only. -- One disabled fuel flow prop feeds the reactor control. -- No leak, no heat, no doors, no terminal. -- Robot starts next to the fuel flow prop. -- The reactor is unready because fuel service is missing. +- Networks: `Fuel`. +- One disabled `Fuel` `FlowProp` feeds the `ReactorControlProp`. +- Required consumer counts are zero. +- No leaks, no `SurfaceHazard`, no `DoorProp`, no `AllSeeingEyeTerminal`. +- Robot starts a few floor cells away from the `FlowProp`. Timeline: -1. Player freely moves and inspects the flow prop and reactor control. -2. Player toggles the fuel flow prop. -3. One pulse propagates fuel to the reactor control. -4. The reactor becomes ready. -5. Player activates the reactor. +1. Player uses `MoveRobot` and inspection freely. +2. Player uses `InteractProp` on the `Fuel` `FlowProp`. +3. One `Pulse` propagates `Fuel` to the `ReactorControlProp`. +4. Level enters `Ready`. +5. Player uses `ActivateReactor`. -Win: Activate the ready reactor. +Win: `ReactorControlProp` has positive `Fuel` amount and pressure, required consumer counts are zero, and `ActivateReactor` changes level state to `Won`. -Lose: No practical lose condition beyond invalid actions; this is a guided tutorial. +Lose: No designed loss condition beyond invalid actions; this is guided tutorial content. -Implementation Notes: +ImplementationNotes: -- This is the only single-action level. -- Prompt text should explicitly distinguish quick movement from a lengthy interaction. -- Pulse playback should be short and obvious: source lights up, pipe fills, reactor ready badge appears. +- This is the only single-action setup. +- Do not include `Forecast`; no `AllSeeingEyeTerminal` exists. -## Group 1: Fuel Network +## Group 1: `Fuel` -Group 1 teaches that fuel is useful reactor feed and dangerous surface material. Fuel-only levels do not use required consumers yet and should not use heat ignition from other systems. The pressure-fed leak behavior is the main source of consequence. +Group 1 teaches pressure-fed `Fuel` faults with no required `ConsumerProp` instances and no `Forecast`. Branches must be visually obvious from `FlowProp`, `IsolationValveProp`, leak access, and `ReactorControlProp` placement. ### 1-1 - Bleed Line -Purpose: Teach that a fed leak keeps growing until the branch is isolated or repaired. +Purpose: Teach that an enabled `FlowProp` can both satisfy `ReactorReadiness` and feed a visible leak. Setup: -- Networks: fuel only. -- One fuel source, one reactor control, one leaking fuel segment on a side branch. -- One isolation valve upstream of the leak. -- Reactor needs fuel at the control and zero required consumers. -- Initial fuel source is disabled. +- Networks: `Fuel`. +- One disabled `Fuel` `FlowProp`. +- One `ReactorControlProp` on the main branch. +- One leaking `Fuel` segment on a short side branch with a reachable floor access cell. +- One `IsolationValveProp` on the side branch before the leak. +- Required consumer counts are zero. Timeline: -1. Plausible first action A: enable the fuel source. Pulse feeds the reactor control, but also injects fuel from the leak. -2. Plausible first action B: close the isolation valve. Pulse prevents leak growth but keeps the reactor starved. -3. If source was enabled first, player should close the valve or repair the leak before fuel reaches critical surface amount. -4. If valve was closed first, player enables source, sees safe service but starved branch, then repairs or leaves the isolated branch closed if reactor requirements are satisfied. -5. Player activates reactor once reactor control receives fuel. +1. First choice A: enable the `FlowProp`; `Pulse` feeds the `ReactorControlProp` and injects `LeakedFuel`. +2. First choice B: close the leak-branch `IsolationValveProp`; `Pulse` prevents fresh leak injection but leaves `ReactorReadiness` missing until fuel is enabled. +3. Player either repairs the leak or keeps it isolated. +4. Player ensures the `ReactorControlProp` has positive `Fuel` amount and pressure. +5. Player uses `ActivateReactor`. -Win: Reactor control fed by fuel, reactor activated. +Win: `ReactorReadiness` is true for `Fuel` with zero required consumers, then `ActivateReactor`. -Lose: Fuel surface hazard reaches robot-terminal level or forecasted critical growth is ignored until terminal failure. +Lose: `Heat` terminal failure is not present; `UnsafeEntryLoss` occurs only if the player moves into unsafe `LeakedFuel`. -Implementation Notes: +ImplementationNotes: -- Forecast for enabling source should say `Leak will grow`. -- Forecast for closing valve should say `Leak isolated; downstream fuel may starve`. -- Keep the leak access on a floor cell adjacent to the main route so repair is readable. +- The leak branch must be visually identifiable without underground visibility. +- Surface `LeakedFuel` amount should become unsafe only after a player mistake, not immediately. -### 1-2 - Wrong Side Of The Valve +### 1-2 - Valve Choice -Purpose: Teach that isolation can starve required service if used too broadly. +Purpose: Teach branch-specific isolation versus over-isolating the main feed. Setup: -- Networks: fuel only. -- One fuel source feeds a fork: one branch to the reactor control and one branch to a leaking segment. -- One isolation valve before the fork and one isolation valve only on the leak branch. -- Fuel source starts enabled. -- Small initial fuel puddle exists at the leak access. +- Networks: `Fuel`. +- One enabled `Fuel` `FlowProp` feeds a fork. +- One fork branch reaches the `ReactorControlProp`. +- The other fork branch reaches a leaking `Fuel` segment. +- One main `IsolationValveProp` before the fork. +- One leak-branch `IsolationValveProp` before the leaking segment. +- Required consumer counts are zero. Timeline: -1. Plausible first action A: close the main valve. Pulse stops leak growth but also starves the reactor. -2. Plausible first action B: close the leak-branch valve. Pulse stops leak growth while preserving reactor feed. -3. Plausible first action C: repair the leak immediately. Pulse leaves pressure on the damaged area; repair succeeds, but the player learns root pressure can still matter later. -4. Player restores or preserves fuel service. -5. Player activates reactor when reactor control is supplied. +1. First choice A: close the main `IsolationValveProp`; `Pulse` stops fresh leak injection and also removes `ReactorReadiness`. +2. First choice B: close the leak-branch `IsolationValveProp`; `Pulse` stops fresh leak injection while preserving the main feed. +3. First choice C: repair the leak; `Pulse` preserves current network pressure and leaves existing `LeakedFuel` unchanged. +4. Player restores direct `Fuel` feed to the `ReactorControlProp`. +5. Player uses `ActivateReactor`. -Win: Reactor fuel feed present, reactor activated. +Win: `ReactorReadiness` is true for `Fuel` with zero required consumers, then `ActivateReactor`. -Lose: Ignoring the leak lets fuel become terminal, or standing in unsafe fuel after a pulse loses the level. +Lose: `UnsafeEntryLoss` from moving into unsafe `LeakedFuel`; terminal failure if fixed rules mark the level `Lost`. -Implementation Notes: +ImplementationNotes: -- The two valves should be spatially distinct and named through inspector text: `Main Fuel Valve` and `Leak Branch Valve`. -- This level should make the better valve choice visible without requiring the all-seeing-eye terminal. +- Use surface labels or prop placement to distinguish main valve and leak-branch valve. +- Describe a closed main feed as missing `ReactorReadiness`. -### 1-3 - Pressure Choice +## Group 2: `Coolant` -Purpose: Teach sequencing between source control, isolation, repair, and activation. - -Setup: - -- Networks: fuel only. -- Two optional fuel endpoints exist as readable branch targets, but consumer requirements are still zero. -- One damaged weakened fuel segment will become leaking if high pressure remains after a pulse. -- One existing small leak blocks a short route. -- One fuel neutralizer supply is available. -- Reactor control is on the main line. - -Timeline: - -1. Plausible first action A: repair the visible leak. Pulse keeps pressure high and may create a new leak on the weakened segment. -2. Plausible first action B: close an isolation valve near the weakened branch. Pulse protects that branch but may starve one optional endpoint. -3. Plausible first action C: pick up fuel neutralizer. Pulse gives time cost while leaks grow slightly. -4. Player chooses whether to stabilize the network first or accept minor fuel spread to reach reactor readiness faster. -5. Player activates reactor after reactor feed is stable. - -Win: Reactor fuel feed present, reactor activated. - -Lose: Fuel hazard reaches terminal amount or robot ends a pulse on unsafe fuel. - -Implementation Notes: - -- This is the first level where a non-perfect solution is acceptable. -- Forecast should warn when structural integrity is expected to become a new leak. - -## Group 2: Coolant Network - -Group 2 raises complexity because coolant-only mechanics would otherwise echo fuel-only leakage. This group introduces consumers as first-class reactor requirements and teaches that coolant is a service network plus a sprinkler resource. Coolant surface output is sprinkler water: useful, temporary, and able to evaporate. +Group 2 introduces `ConsumerProp` requirements and `CoolantSprinklerValve` pressure tradeoffs. Since `Coolant` alone is not a fire system yet, these levels focus on `Producing` consumers, `SprinklerWater`, `Evaporation`, and pressure recovery. ### 2-1 - Prime The Pump -Purpose: Introduce required consumers and starvation using a non-lethal coolant network. +Purpose: Introduce `ConsumerProp` as a required production checklist. Setup: -- Networks: coolant only. -- One coolant source, two coolant consumers, one reactor control. -- Reactor requires one producing coolant consumer. -- One isolation valve can cut off the closer consumer while preserving the reactor feed. -- No leaks, no sprinkler valve yet. +- Networks: `Coolant`. +- One disabled `Coolant` `FlowProp`. +- Two visible `Coolant` `ConsumerProp` instances. +- One `ReactorControlProp`. +- Required consumers: one `Coolant`. +- One branch `IsolationValveProp` can cut off one consumer while leaving another consumer and the control feed available. Timeline: -1. Plausible first action A: enable coolant source. Pulse feeds both consumers and reactor control. -2. Plausible first action B: toggle the isolation valve. Pulse demonstrates starvation without immediate danger. -3. If the player starves the required path, they must reopen the valve and spend another pulse. -4. Player observes consumer state: starved versus producing. -5. Player activates reactor once any required coolant consumer is producing and reactor control is fed. +1. First choice A: enable the `FlowProp`; `Pulse` allows at least one `ConsumerProp` to become `Producing` and can make the level `Ready`. +2. First choice B: toggle the branch `IsolationValveProp`; `Pulse` demonstrates that consumer production depends on supply. +3. Player sets valve/source state so at least one `Coolant` `ConsumerProp` is `Enabled` and `Producing`. +4. Player uses `ActivateReactor`. -Win: One coolant consumer producing, reactor coolant feed present, reactor activated. +Win: `ReactorControlProp` has positive `Coolant` amount and pressure, at least one required `Coolant` `ConsumerProp` is `Enabled` and `Producing`, then `ActivateReactor`. -Lose: No intended terminal hazard; excessive wrong actions only delay readiness. +Lose: No designed terminal pressure; only invalid actions or explicit terminal rules. -Implementation Notes: +ImplementationNotes: -- This level is forgiving but not one-action because the valve is a tempting alternate first action. -- The inspector should explicitly show `Coolant consumer: Starved` and `Producing`. +- This level introduces `ConsumerProp` before any `CoolantSprinklerValve`. +- Use visible prop placement; no `AllSeeingEyeTerminal`. ### 2-2 - Sprinkler Debt -Purpose: Teach sprinkler discharge as a tradeoff: surface help now, coolant pressure loss this pulse. +Purpose: Teach that an enabled wall-mounted `CoolantSprinklerValve` can reduce pressure until disabled or isolated. Setup: -- Networks: coolant only. -- One coolant source feeds one required coolant consumer, reactor control, and one sprinkler valve. -- A harmless hot surface patch exists as a preview target for future heat interactions. -- Activating sprinkler valve wets outlet cells and causes a temporary local coolant pressure drop. +- Networks: `Coolant`. +- One enabled `Coolant` `FlowProp`. +- One wall-mounted `CoolantSprinklerValve` starts `Enabled`. +- The sprinkler has one adjacent floor outlet/access face and emits `SprinklerWater`. +- One `Coolant` `ConsumerProp` and the `ReactorControlProp` are on the same pressure-sensitive branch. +- Required consumers: one `Coolant`. +- One upstream `IsolationValveProp` can shut the sprinkler branch without shutting the consumer branch. Timeline: -1. Plausible first action A: activate the sprinkler valve. Pulse wets the hot patch and shows evaporation/cooling, but coolant pressure drops and may starve the consumer. -2. Plausible first action B: enable or preserve the main coolant feed first. Pulse makes reactor nearly ready but leaves hot patch unchanged. -3. Player chooses whether to spend one pulse demonstrating suppression or go directly for readiness. -4. If sprinkler caused starvation, the recovery path is another useful network action, such as toggling a valve or source, that triggers a pulse and lets evaporation or pressure recovery resolve. -5. Player activates reactor after coolant consumer and reactor feed are supplied. +1. First choice A: disable the `CoolantSprinklerValve`; `Pulse` stops discharge and allows pressure recovery. +2. First choice B: close the sprinkler-branch `IsolationValveProp`; `Pulse` stops discharge by cutting supply to the sprinkler. +3. First choice C: enable/adjust the main `FlowProp` first if authored disabled; `Pulse` keeps sprinkler debt visible. +4. `SprinklerWater` evaporates through normal `Step` rules during pulses caused by useful actions. +5. Player reaches `ReactorReadiness` after `Coolant` pressure and required consumer production recover. +6. Player uses `ActivateReactor`. -Win: Coolant consumer producing, reactor coolant feed present, reactor activated. +Win: `ReactorControlProp` has positive `Coolant` amount and pressure, one `Coolant` `ConsumerProp` is `Enabled` and `Producing`, then `ActivateReactor`. -Lose: Heat patch is intentionally below terminal level; loss should be unlikely unless robot ends on an unsafe cell. +Lose: No authored `Heat` or fire; avoid loss pressure except explicit terminal rules. -Implementation Notes: +ImplementationNotes: -- This level introduces evaporation visually before heat becomes a central system. -- Forecast for sprinkler should say `Outlet wets; local coolant pressure drops this pulse`. +- Do not author standalone `Heat` in this `Coolant`-only level. +- Sprinkler is wall-mounted with exactly one outlet/access floor face. +- This level visually teaches `SprinklerWater` and `Evaporation` without suppression yet. ### 2-3 - Split Flow -Purpose: Teach that coolant service has routing priorities and that not every consumer must be active unless required. +Purpose: Teach `JunctionProp` routing and consumer requirements in a readable `Coolant` network. Setup: -- Networks: coolant only. -- One coolant source, one junction, three coolant consumers, one reactor control. -- Reactor requires two producing coolant consumers. -- One branch includes a weakened coolant leak that creates sprinkler water if fed. -- One isolation valve can protect the damaged branch while sacrificing one consumer. +- Networks: `Coolant`. +- One enabled `Coolant` `FlowProp`. +- One `JunctionProp` controls two consumer branches. +- Three visible `Coolant` `ConsumerProp` instances. +- One wall-mounted `CoolantSprinklerValve` starts `Disabled`. +- Required consumers: two `Coolant`. +- One branch has a weakened or leaking `Coolant` segment that emits `SprinklerWater` when fed. Timeline: -1. Plausible first action A: cycle the junction toward the damaged branch. Pulse feeds more consumers but starts coolant leakage. -2. Plausible first action B: close damaged-branch isolation. Pulse prevents leakage but leaves only two possible consumers. -3. Plausible first action C: repair the coolant leak first. Pulse consumes time while current routing continues. -4. Player balances enough producing consumers against leak control. -5. Player activates reactor when two coolant consumers and the reactor control are fed. +1. First choice A: cycle the `JunctionProp`; `Pulse` changes which consumers can become `Producing`. +2. First choice B: close the damaged branch `IsolationValveProp`; `Pulse` stops fresh `SprinklerWater` injection but reduces available production paths. +3. First choice C: repair the `Coolant` leak; `Pulse` stops future leak injection but does not remove existing `SprinklerWater`. +4. Player configures routing so two `Coolant` consumers are `Enabled` and `Producing`. +5. Player uses `ActivateReactor`. -Win: Two coolant consumers producing, reactor coolant feed present, reactor activated. +Win: `ReactorControlProp` has positive `Coolant` amount and pressure, two `Coolant` `ConsumerProp` instances are `Enabled` and `Producing`, then `ActivateReactor`. -Lose: Robot loses by unsafe final surface state if the route is flooded enough to be unsafe, or terminal rules mark failure. +Lose: `UnsafeEntryLoss` only if the player moves into an unsafe `SurfaceHazard`; otherwise no designed terminal pressure. -Implementation Notes: +ImplementationNotes: -- Keep the coolant leak readable as sprinkler water, not as generic damage. -- This level should cement consumers before electricity appears. +- Keep all relevant branches readable from surface prop placement. +- No `Forecast`; no `AllSeeingEyeTerminal`. -## Group 3: Electricity Network +## Group 3: `Electricity` -Group 3 teaches electricity as fast, directional danger. Electricity leaks can emit from walls, voltage matters, and doors/terminals enter because information and containment are more important now. +Group 3 introduces wall `Electricity` leaks, powered `DoorProp` behavior, and then `AllSeeingEyeTerminal`. Levels 3-1 and 3-2 must remain readable without underground visibility. ### 3-1 - Live Face -Purpose: Introduce electricity wall leaks and repair access from an adjacent floor face. +Purpose: Teach wall `Electricity` leak access and repair from the adjacent emission face. Setup: -- Networks: electricity only. -- One electricity source, one electricity consumer, one reactor control. -- One wall-based electricity leak with a clearly marked accessible floor face. -- One isolation valve can cut voltage to the leaking segment. +- Networks: `Electricity`. +- One disabled `Electricity` `FlowProp`. +- One wall-based `Electricity` leak with exactly one adjacent floor emission/repair face. +- One `Electricity` `ConsumerProp`. +- One `ReactorControlProp`. +- Required consumers: one `Electricity`. +- One `IsolationValveProp` can cut voltage to the leaking wall segment. Timeline: -1. Plausible first action A: enable electricity source. Pulse powers consumer and reactor but emits electricity from the wall leak. -2. Plausible first action B: close isolation valve. Pulse prevents emission but starves the consumer. -3. Player moves to the safe repair face and repairs the leak, or keeps it isolated if reactor feed can bypass it. -4. Player restores power and activates reactor. +1. First choice A: enable the `FlowProp`; `Pulse` powers the consumer/control and emits `LeakedElectricity`. +2. First choice B: close the leak `IsolationValveProp`; `Pulse` prevents emission but leaves required electricity production missing until a valid powered path exists. +3. Player repairs the leak from the marked floor face or keeps it isolated if another path can satisfy readiness. +4. Player achieves `Electricity` consumer production and local control feed. +5. Player uses `ActivateReactor`. -Win: Electricity consumer producing, reactor electricity feed present, reactor activated. +Win: `ReactorControlProp` has positive `Electricity` amount and voltage, one `Electricity` `ConsumerProp` is `Enabled` and `Producing`, then `ActivateReactor`. -Lose: Robot ends a pulse on unsafe electricity, or electricity reaches terminal state. +Lose: `UnsafeEntryLoss` from moving into unsafe `LeakedElectricity`; terminal failure if fixed rules mark `Lost`. -Implementation Notes: +ImplementationNotes: -- Access face must be visually unambiguous. -- Forecast for source enable should call out `Wall leak will energize this face`. +- Emission/repair face must be visually unambiguous. +- No `Forecast`; no `AllSeeingEyeTerminal`. -### 3-2 - Breaker Door +### 3-2 - Powered Door -Purpose: Introduce doors as surface propagation blockers without adding a second network. +Purpose: Introduce `DoorProp` toggling as an electricity-dependent action. Setup: -- Networks: electricity only. -- One source and one required electricity consumer. -- A closed door sits in a corridor between a possible electricity spill and the robot route. -- One door action can open a shorter path but also allows surface electricity propagation through the corridor. -- One isolation valve can de-energize the hazardous branch. +- Networks: `Electricity`. +- One `Electricity` `FlowProp` feeds a `DoorProp` local supply branch. +- One `Electricity` `ConsumerProp` and one `ReactorControlProp`. +- Required consumers: one `Electricity`. +- One `DoorProp` begins `Closed`; it can be toggled only while its local `Electricity` feed is positive. +- One wall `Electricity` leak is positioned so the closed door blocks surface propagation across the corridor. Timeline: -1. Plausible first action A: open the door. Pulse improves robot routing but may let electricity spread across the corridor. -2. Plausible first action B: isolate the hazardous branch first. Pulse makes opening the door safer but may starve the consumer. -3. Plausible first action C: repair the wall leak first. Pulse costs time while voltage remains active. -4. Player sequences isolation, door, repair, and power restoration. -5. Player activates reactor when consumer and reactor feed are powered. +1. First choice A: power the door branch, then toggle the `DoorProp`; `Pulse` changes surface propagation boundaries. +2. First choice B: isolate or repair the wall leak first; `Pulse` reduces `LeakedElectricity` risk before opening. +3. First choice C: keep the door `Closed` and power the required consumer path first. +4. Player sequences powered door operation with leak management. +5. Player uses `ActivateReactor`. -Win: Electricity consumer producing, reactor electricity feed present, reactor activated. +Win: `ReactorControlProp` has positive `Electricity` amount and voltage, one `Electricity` `ConsumerProp` is `Enabled` and `Producing`, then `ActivateReactor`. -Lose: Unsafe electricity reaches the robot route or terminal failure occurs. +Lose: `UnsafeEntryLoss` from entering unsafe `LeakedElectricity`; terminal failure if fixed rules mark `Lost`. -Implementation Notes: +ImplementationNotes: -- Door preview should show blocked or unblocked surface propagation. -- This is the first level where a mobility action that is lengthy can reshape hazard propagation. +- Use an authored wall `Electricity` leak for surface electricity risk. +- The door’s electric supply should be obvious from nearby surface props before terminal access exists. ### 3-3 - The All-Seeing Eye -Purpose: Introduce the all-seeing-eye terminal as optional information, not a magic solution. +Purpose: Introduce terminal-local underground visibility and systemic `Forecast`. Setup: -- Networks: electricity only. -- Two visually similar branches are hidden until terminal access. -- One branch feeds the reactor safely; the other branch reaches a weakened high-voltage segment. -- An all-seeing-eye terminal is reachable through a side room. -- Reactor requires one electricity consumer. +- Networks: `Electricity`. +- One `AllSeeingEyeTerminal` in a side room. +- One route powers the required `Electricity` `ConsumerProp`; another route reaches a weakened high-voltage segment. +- One `DoorProp` or `IsolationValveProp` can change which route is used. +- Required consumers: one `Electricity`. Timeline: -1. Plausible first action A: activate the all-seeing-eye terminal. Pulse reveals underground topology and forecasts the safer branch. -2. Plausible first action B: enable source immediately. Pulse may feed the correct path or reveal danger through voltage and leak warnings. -3. Plausible first action C: toggle a suspected isolation valve before seeing topology. Pulse may protect the weak branch or starve the consumer. -4. Player uses revealed topology or observed consequences to choose the correct valve/source sequence. -5. Player activates reactor once electricity service is stable. +1. First choice A: activate the `AllSeeingEyeTerminal`; `Pulse` advances the environment and enables terminal-local underground visibility plus systemic `Forecast`. +2. First choice B: route power without terminal information; `Pulse` may power the correct path or expose visible consequences. +3. First choice C: isolate the visibly risky branch first; `Pulse` may preserve safety but delay required production. +4. While at the active terminal, player uses `Forecast` and underground visibility to choose route state. +5. Player restores required production and control feed. +6. Player uses `ActivateReactor`. -Win: Electricity consumer producing, reactor electricity feed present, reactor activated. +Win: `ReactorControlProp` has positive `Electricity` amount and voltage, one `Electricity` `ConsumerProp` is `Enabled` and `Producing`, then `ActivateReactor`. -Lose: High voltage creates a leak and unsafe electricity reaches the robot, or terminal failure occurs. +Lose: `UnsafeEntryLoss` from unsafe `LeakedElectricity`, terminal `Heat` if generated by fixed rules, or another fixed terminal rule. -Implementation Notes: +ImplementationNotes: -- This level should not require terminal use, but terminal use should be clearly advantageous. -- Underground overlay is introduced here and should be reused in all later groups. +- This is the first campaign level with `Forecast`. +- `Forecast` output must be systemic; do not author level text. -## Group 4: Fuel + Coolant +## Group 4: `Fuel` + `Electricity` -Group 4 introduces heat as the first major two-network consequence. Fuel creates burn risk; coolant sprinkler water dilutes fuel, quenches heat, and evaporates. +Group 4 introduces the first dual-system interaction: `Fuel` and `Electricity` can `Ignite`, generating recurring `Heat`. From this point onward, `Heat` is a recurring campaign problem. -### 4-1 - Steam Test +### 4-1 - First Spark -Purpose: Teach heat, quenching, and evaporation in a contained fuel/coolant scenario. +Purpose: Teach that combining `LeakedFuel` and `LeakedElectricity` can create `Heat`. Setup: -- Networks: fuel and coolant. -- One fuel source and consumer, one coolant source and consumer, one reactor control under both networks. -- A small heat patch sits near a fuel leak. -- One sprinkler valve can wet the heat patch. -- Reactor requires one fuel and one coolant consumer. +- Networks: `Fuel`, `Electricity`. +- One visible `Fuel` leak emits near a corridor. +- One wall `Electricity` leak emits toward the same corridor. +- One `Fuel` `ConsumerProp`, one `Electricity` `ConsumerProp`, and one `ReactorControlProp` on both networks. +- Required consumers: one `Fuel`, one `Electricity`. +- One `IsolationValveProp` can isolate either damaged branch. Timeline: -1. Plausible first action A: activate sprinkler. Pulse quenches heat and evaporates some water, but may starve coolant consumer temporarily. -2. Plausible first action B: isolate or repair fuel leak first. Pulse slows fuel growth but leaves heat. -3. Plausible first action C: enable fuel service first. Pulse may bring reactor closer but grows fuel near heat. -4. Player suppresses or removes the immediate heat/fuel interaction, then restores both services. -5. Player activates reactor when fuel and coolant requirements are met. +1. First choice A: enable `Fuel`; `Pulse` grows `LeakedFuel`. +2. First choice B: enable `Electricity`; `Pulse` grows `LeakedElectricity`. +3. First choice C: isolate or repair one leak before both networks are active. +4. If both leaked values meet, fixed surface rules can `Ignite` and create `Heat`. +5. Player stabilizes at least one leak path, restores required production, and activates. -Win: One fuel consumer and one coolant consumer producing, reactor fed by both networks, reactor activated. +Win: `ReactorReadiness` is true for `Fuel` and `Electricity`, required consumers are `Enabled` and `Producing`, then `ActivateReactor`. -Lose: Heat reaches terminal threshold, ignition occurs from unmanaged fuel/heat, or robot ends on unsafe hazard. +Lose: terminal `Heat`, `UnsafeEntryLoss` from unsafe `LeakedFuel` or `LeakedElectricity`, or fixed terminal failure. -Implementation Notes: +ImplementationNotes: -- This is the first level where coolant is clearly helpful against another system. -- Forecast should say whether sprinkler causes `Reactor ready delayed by coolant pressure drop`. +- Use only designed interactions from the hazard pair table. +- `Heat` appears as a consequence of `Ignite`, not as an arbitrary authored patch. -### 4-2 - Dry Window +### 4-2 - Break Before Make -Purpose: Teach that wet cells do not remain wet by timer; evaporation depends on water and heat values. +Purpose: Teach source sequencing: fixing or isolating first can be safer than powering both networks. Setup: -- Networks: fuel and coolant. -- A hot corridor separates robot from a fuel repair site. -- Sprinkler outlets can cool the corridor, but water evaporates quickly on high-heat cells. -- Fuel service and coolant service are both required. +- Networks: `Fuel`, `Electricity`. +- `Fuel` source starts enabled and a small visible `LeakedFuel` patch exists. +- `Electricity` source starts disabled. +- One wall `Electricity` leak is near the fuel patch. +- One powered `DoorProp` can contain surface spread if operated before electricity/fuel overlap grows. +- Required consumers: one `Fuel`, one `Electricity`. Timeline: -1. Plausible first action A: sprinkler corridor first. Pulse lowers heat and opens a safer movement route, but coolant consumer may starve. -2. Plausible first action B: repair or isolate fuel leak first. Pulse reduces future fuel but leaves corridor heat dangerous. -3. Plausible first action C: adjust coolant routing to preserve consumer feed before sprinkler use. -4. Player uses the cooled movement window to reach fuel repair or activation path. -5. Player restores both services and activates reactor. +1. First choice A: enable `Electricity`; `Pulse` may create `Heat` if leaked values interact. +2. First choice B: close or open a powered `DoorProp` to change surface propagation before energizing. +3. First choice C: isolate or repair the `Fuel` leak first. +4. Player prevents or contains `Ignite`, then restores both required services. +5. Player uses `ActivateReactor`. -Win: Required fuel and coolant consumers producing, reactor fed by both, reactor activated. +Win: `ReactorReadiness` is true for `Fuel` and `Electricity`, required consumers are `Enabled` and `Producing`, then `ActivateReactor`. -Lose: Heat rebounds or spreads to terminal level; robot ends a pulse on unsafe heat. +Lose: terminal `Heat` or `UnsafeEntryLoss`. -Implementation Notes: +ImplementationNotes: -- The level should visually prove evaporation by shrinking wet overlays during pulse playback. -- Avoid making timing real-time; the window is about pulse consequences and movement position. +- Door mechanics are centered on electricity supply: the `DoorProp` can only toggle while powered. +- If an `AllSeeingEyeTerminal` is present, its `Forecast` is optional and terminal-local. -### 4-3 - Dilution Route +### 4-3 - Hot Bypass -Purpose: Teach coolant/fuel same-cell interaction before electricity makes wetness dangerous. +Purpose: Combine structural integrity, route choice, and fire risk. Setup: -- Networks: fuel and coolant. -- A fuel leak threatens to pool across a required walkway. -- Sprinkler outlets can dilute fuel but create water that evaporates over later pulses. -- Two fuel consumers exist; one is safer but farther through a valve sequence. -- Reactor requires one fuel and one coolant consumer. +- Networks: `Fuel`, `Electricity`. +- Two visible branches can satisfy each required consumer set. +- One high-voltage branch threatens structural degradation near a `Fuel` leak path. +- One `DoorProp` can contain `Heat` or `LeakedElectricity` propagation if powered and closed. +- Required consumers: one `Fuel`, one `Electricity`. +- One `HeatShield` supply is available for movement safety. Timeline: -1. Plausible first action A: sprinkler the fuel pool. Pulse dilutes fuel, possibly creating a safe path, but coolant pressure drops. -2. Plausible first action B: isolate fuel branch. Pulse stops new fuel but may starve the only currently fed fuel consumer. -3. Plausible first action C: reroute fuel to the safer consumer first. Pulse delays cleanup but may satisfy reactor requirements. -4. Player chooses between cleanup-first and service-first sequencing. -5. Player activates reactor after both services are met and path to control is safe. +1. First choice A: route `Electricity` through the high-voltage branch; `Pulse` may create a new wall leak by fixed integrity rules. +2. First choice B: isolate the `Fuel` bypass; `Pulse` reduces ignition risk but changes available production path. +3. First choice C: pick up `HeatShield`; `Pulse` improves future movement safety but does not solve the system. +4. Player chooses one stable production route per network. +5. Player uses `ActivateReactor`. -Win: Fuel and coolant requirements met, reactor control reachable and fed, reactor activated. +Win: `ReactorReadiness` is true for `Fuel` and `Electricity`, required consumers are `Enabled` and `Producing`, then `ActivateReactor`. -Lose: Fuel hazard or heat reaches terminal state; robot ends in unsafe fuel or heat. +Lose: terminal `Heat`, `UnsafeEntryLoss`, or fixed terminal failure. -Implementation Notes: +ImplementationNotes: -- Keep electricity absent so wetness is unambiguously helpful here. -- This prepares the contrast for Group 6. +- `HeatShield` only affects movement safety; it does not quench `Heat`. +- Avoid perfect cleanup requirements. -## Group 5: Fuel + Electricity +## Group 5: `Coolant` + `Electricity` -Group 5 teaches ignition risk. Fuel plus electricity can create heat/fire, so the player must decide which source to energize, isolate, or repair first. +Group 5 teaches that `SprinklerWater` is useful system material but dangerous with `Electricity`. `Evaporation` becomes important without adding a wait command. -### 5-1 - Spark In The Line +### 5-1 - Charged Water -Purpose: Introduce fuel/electricity ignition in a small, readable layout. +Purpose: Teach wet-electricity `Conduct`. Setup: -- Networks: fuel and electricity. -- One fuel leak and one electricity wall leak threaten the same corridor from different sides. -- One fuel consumer and one electricity consumer are required. -- Reactor control is under both networks. +- Networks: `Coolant`, `Electricity`. +- One wall-mounted `CoolantSprinklerValve` can wet a corridor. +- One wall `Electricity` leak emits toward that corridor. +- Required consumers: one `Coolant`, one `Electricity`. +- One `IsolationValveProp` can cut voltage to the leak branch. Timeline: -1. Plausible first action A: enable fuel source. Pulse feeds fuel service but grows fuel near the electric face. -2. Plausible first action B: enable electricity source. Pulse powers service but may energize the leak face. -3. Plausible first action C: isolate either damaged branch first. Pulse reduces ignition risk but starves one service. -4. Player prevents overlap by isolating or repairing at least one leak before both services are active. -5. Player restores both services and activates reactor. +1. First choice A: enable the `CoolantSprinklerValve`; `Pulse` adds `SprinklerWater`. +2. First choice B: isolate or repair the `Electricity` leak first. +3. First choice C: energize electricity production first while keeping the sprinkler disabled. +4. If `LeakedElectricity` reaches wet cells, fixed rules use `Conduct`. +5. Player restores both required services and activates. -Win: Fuel and electricity consumers producing, reactor fed by both, reactor activated. +Win: `ReactorReadiness` is true for `Coolant` and `Electricity`, required consumers are `Enabled` and `Producing`, then `ActivateReactor`. -Lose: Fuel/electricity ignition creates terminal heat, or robot ends on unsafe hazard. +Lose: `UnsafeEntryLoss` from wet-electric unsafe cells or fixed terminal failure. -Implementation Notes: +ImplementationNotes: -- Forecast must clearly call out `Ignition risk` before the player combines fuel and electricity. +- No authored forecast prose; terminal-local systemic `Forecast` may warn about wet conduction if a terminal exists. -### 5-2 - Dark Start +### 5-2 - Dry Before Live -Purpose: Teach that powering information or doors can worsen fuel hazards. +Purpose: Teach that `Evaporation` can be part of useful action sequencing. Setup: -- Networks: fuel and electricity. -- All-seeing-eye terminal is present but requires reaching or powering a side branch. -- A fuel leak is visible; the electricity topology is partially hidden until terminal use. -- A door can contain surface fuel spread if kept closed. -- Reactor requires one fuel and one electricity consumer. +- Networks: `Coolant`, `Electricity`. +- Initial `SprinklerWater` exists on a floor route near an `Electricity` leak face. +- A wall-mounted `CoolantSprinklerValve` starts `Enabled`, maintaining wetness and pressure debt. +- A powered `DoorProp` can contain electrical surface propagation. +- Required consumers: one `Coolant`, one `Electricity`. Timeline: -1. Plausible first action A: activate terminal. Pulse reveals a safer electric route but gives fuel another pulse to spread. -2. Plausible first action B: close or keep door containment while repairing fuel. Pulse contains fuel but delays information. -3. Plausible first action C: energize electricity blind. Pulse may power the terminal path but risks ignition near hidden leak face. -4. Player uses containment plus information to choose source order. -5. Player restores both networks and activates reactor. +1. First choice A: disable the `CoolantSprinklerValve`; `Pulse` stops new `SprinklerWater` and allows `Evaporation`. +2. First choice B: close an upstream `IsolationValveProp`; `Pulse` cuts sprinkler supply and changes coolant pressure. +3. First choice C: power and operate the `DoorProp` before energizing the leak branch. +4. Player uses meaningful network actions while `Evaporation` reduces wetness. +5. Player energizes safely, restores both services, and activates. -Win: Required fuel and electricity consumers producing, reactor fed by both, reactor activated. +Win: `ReactorReadiness` is true for `Coolant` and `Electricity`, required consumers are `Enabled` and `Producing`, then `ActivateReactor`. -Lose: Fire/heat reaches terminal threshold or unsafe electricity/fuel traps the robot. +Lose: `UnsafeEntryLoss` from wet-electric unsafe cells or fixed terminal failure. -Implementation Notes: +ImplementationNotes: -- This level asks the player to value information without making it mandatory. -- Door state should be visible in forecast as a surface spread blocker. +- Do not add a wait or fast-forward action. +- Do not author standalone `Heat`; drying comes from `Evaporation` rules during pulses. -### 5-3 - Hot Bypass +### 5-3 - Eye In The Storm -Purpose: Create a richer two-network routing puzzle using optional consumers and structural integrity. +Purpose: Combine `AllSeeingEyeTerminal` with wet-conduction routing. Setup: -- Networks: fuel and electricity. -- Two fuel consumers and two electricity consumers exist; one of each is required. -- A high-voltage route weakens an electricity segment near a fuel bypass. -- A fuel isolation valve can protect the bypass but starves the closest fuel consumer. -- One heat shield supply is present. +- Networks: `Coolant`, `Electricity`. +- One `AllSeeingEyeTerminal` is reachable but requires a `Pulse` to activate. +- Two wall-mounted `CoolantSprinklerValve` instances affect different outlet faces. +- One `Electricity` route overlaps one wettable corridor underground. +- Required consumers: one `Coolant`, one `Electricity`. Timeline: -1. Plausible first action A: route electricity through high-voltage branch. Pulse satisfies power but may create a leak near fuel. -2. Plausible first action B: isolate fuel bypass first. Pulse lowers ignition risk but requires a longer fuel service route. -3. Plausible first action C: pick up heat shield. Pulse gives safety margin while hazards evolve. -4. Player sequences routing and repair so the two networks do not overlap unsafely. -5. Player activates reactor once one consumer of each type is producing. +1. First choice A: activate the `AllSeeingEyeTerminal`; `Pulse` enables terminal-local visibility and systemic `Forecast`. +2. First choice B: disable or isolate the nearest sprinkler without terminal information. +3. First choice C: isolate electricity before changing sprinkler state. +4. Player uses terminal-local information to avoid wet conduction and restore required production. +5. Player uses `ActivateReactor`. -Win: One fuel and one electricity consumer producing, reactor fed by both, reactor activated. +Win: `ReactorReadiness` is true for `Coolant` and `Electricity`, required consumers are `Enabled` and `Producing`, then `ActivateReactor`. -Lose: Ignition creates terminal heat, structural leak cascade becomes unrecoverable, or robot ends unsafe. +Lose: `UnsafeEntryLoss` from wet-electric unsafe cells, or fixed terminal failure. -Implementation Notes: +ImplementationNotes: -- This is a late two-network difficulty spike, but keep the grid small. -- Heat shield should be useful for movement, not a solution to the system problem. +- Terminal should reveal why one sprinkler/electric route combination is riskier. +- `Forecast` remains systemic and terminal-local. -## Group 6: Coolant + Electricity +## Group 6: Full Startup -Group 6 reframes coolant as both protection and electrical risk. Wet cells conduct electricity faster, and evaporation becomes a strategic cleanup mechanic. +Group 6 uses `Fuel`, `Coolant`, and `Electricity`. `Heat` can arise from `Fuel` + `Electricity`; `CoolantSprinklerValve` and `SprinklerWater` provide suppression while creating pressure and wet-conduction tradeoffs. -### 6-1 - Charged Floor +### 6-1 - Three-Key Start -Purpose: Teach wet-electricity conduction in isolation from fuel. +Purpose: First all-network level with one readable problem per network. Setup: -- Networks: coolant and electricity. -- Sprinkler valve can wet a corridor. -- Electricity leak can energize one end of that corridor. -- One coolant consumer and one electricity consumer are required. +- Networks: `Fuel`, `Coolant`, `Electricity`. +- `ReactorControlProp` sits on all three networks. +- Required consumers: one `Fuel`, one `Coolant`, one `Electricity`. +- One visible `Fuel` leak, one enabled wall-mounted `CoolantSprinklerValve`, and one wall `Electricity` leak. +- One optional `AllSeeingEyeTerminal` is off the direct route. Timeline: -1. Plausible first action A: activate sprinkler. Pulse cools and wets corridor, but creates a possible conduction path. -2. Plausible first action B: isolate or repair electricity leak first. Pulse makes later sprinkler use safer but delays power service. -3. Plausible first action C: enable electricity first. Pulse powers consumer but makes wet corridor dangerous if sprinkler was used. -4. Player prevents electricity from entering wet cells, or uses other useful actions to let evaporation reduce wetness before energizing. -5. Player activates reactor after both services are producing. +1. First choice A: isolate or repair the `Fuel` leak. +2. First choice B: disable or isolate the `CoolantSprinklerValve` to restore pressure. +3. First choice C: isolate or repair the `Electricity` leak before wet cells conduct. +4. First choice D: activate the `AllSeeingEyeTerminal` for terminal-local `Forecast`. +5. Player restores required production for all three carriers. +6. Player uses `ActivateReactor`. -Win: Coolant and electricity consumers producing, reactor fed by both, reactor activated. +Win: `ReactorReadiness` is true for all three carriers, one required `ConsumerProp` per carrier is `Enabled` and `Producing`, then `ActivateReactor`. -Lose: Wet conduction reaches robot or terminal electrical failure occurs. +Lose: terminal `Heat`, `UnsafeEntryLoss`, wet-electric terminal failure, or other fixed terminal failure. -Implementation Notes: +ImplementationNotes: -- Forecast should use distinct wording: `Wet cells will conduct electricity`. +- Keep this forgiving and compact. +- Do not require hazard cleanup after `Ready`. -### 6-2 - Dry Before Live +### 6-2 - Cascade Lockout -Purpose: Teach that evaporation can be part of sequencing without adding fast-forward. +Purpose: Require ordering because one fix can worsen another surface interaction. Setup: -- Networks: coolant and electricity. -- A previously wet area blocks the safest electrical route. -- Heat patch is present only to accelerate evaporation, not as a third network. -- A door can contain electrical spread while wet cells dry. -- Reactor requires one coolant and one electricity consumer. +- Networks: `Fuel`, `Coolant`, `Electricity`. +- A `Fuel` leak can meet an `Electricity` leak and `Ignite`. +- A wall-mounted `CoolantSprinklerValve` can quench or dilute but creates `SprinklerWater`. +- A powered `DoorProp` can contain one surface spread path. +- One `AllSeeingEyeTerminal` is reachable. +- Required consumers: one per carrier. Timeline: -1. Plausible first action A: open the door and energize route. Pulse risks electrical spread through wet cells. -2. Plausible first action B: perform coolant routing or valve action that also lets one pulse of evaporation occur. Pulse reduces wetness while changing service state. -3. Plausible first action C: close containment door first. Pulse buys a safer electrical boundary. -4. Player uses useful network actions to create a dry-enough route before energizing. -5. Player activates reactor when both services are supplied. +1. First choice A: use the sprinkler to suppress/dilute; `Pulse` creates wet-conduction risk. +2. First choice B: isolate electricity before using sprinkler; `Pulse` delays electricity production. +3. First choice C: power and toggle the `DoorProp` to change containment. +4. First choice D: activate the `AllSeeingEyeTerminal` for systemic `Forecast`. +5. Player chooses containment, suppression, isolation, and production order. +6. Player uses `ActivateReactor`. -Win: Coolant and electricity requirements met, reactor control fed by both, reactor activated. +Win: `ReactorReadiness` is true for all three carriers, one required `ConsumerProp` per carrier is `Enabled` and `Producing`, then `ActivateReactor`. -Lose: Wet electrical spread reaches terminal hazard or robot safety failure. +Lose: terminal `Heat`, `UnsafeEntryLoss`, wet-electric terminal failure, or other fixed terminal failure. -Implementation Notes: +ImplementationNotes: -- Do not add a wait button; all drying happens as a consequence of meaningful actions. -- The heat patch should be described as environmental heat, not a fuel-system mechanic. +- This is the main test of previous group lessons in one compact level. +- Door operation must depend on local `Electricity` supply. -### 6-3 - Eye In The Storm +### 6-3 - Critical Path -Purpose: Combine terminal information with wet-conduction routing. +Purpose: Final capstone with multiple valid solution orders. Setup: -- Networks: coolant and electricity. -- All-seeing-eye terminal reveals which wet corridor overlies the live conduit. -- Two sprinkler valves exist: one useful, one dangerous if electricity is active. -- One coolant and one electricity consumer are required. +- Networks: `Fuel`, `Coolant`, `Electricity`. +- `ReactorControlProp` sits on all three networks. +- Two `ConsumerProp` instances per carrier exist; one per carrier is required. +- One `Fuel` leak, one enabled wall-mounted `CoolantSprinklerValve`, one wall `Electricity` leak, one powered `DoorProp`, and one weakened structural segment. +- One `AllSeeingEyeTerminal`, one `HeatShield`, and one relevant `RemedySupplyProp` are available. Timeline: -1. Plausible first action A: use all-seeing-eye terminal. Pulse reveals hidden overlap and forecasts the safe sprinkler choice. -2. Plausible first action B: activate nearest sprinkler without information. Pulse may wet the dangerous corridor. -3. Plausible first action C: isolate electricity first. Pulse makes sprinkler choice safer but starves electricity consumer. -4. Player decides whether to gather information, isolate, or take a calculated sprinkler action. -5. Player restores both services and activates reactor. +1. First choice A: activate the `AllSeeingEyeTerminal`; `Pulse` grants terminal-local topology and `Forecast` while hazards advance. +2. First choice B: isolate or repair the `Fuel` leak before `Ignite`. +3. First choice C: disable or isolate the sprinkler before energizing wet areas. +4. First choice D: isolate or repair electricity before using sprinkler suppression. +5. First choice E: pick up `HeatShield` or a `RemedySupplyProp` for movement/access safety. +6. Player selects a minimum viable producing consumer set and stabilizes the most terminal interaction. +7. Player uses `ActivateReactor` as soon as `Ready` appears. -Win: Coolant and electricity consumers producing, reactor fed by both, reactor activated. +Win: `ReactorReadiness` is true for all three carriers, one required `ConsumerProp` per carrier is `Enabled` and `Producing`, then `ActivateReactor`. -Lose: Wet conduction cascade becomes terminal or robot ends unsafe. +Lose: terminal `Heat`, `UnsafeEntryLoss`, wet-electric terminal failure, or other fixed terminal failure. -Implementation Notes: +ImplementationNotes: -- This is the capstone for terminals before the full-system endgame. -- Terminal should reveal both underground layers at once. - -## Group 7: Full Reactor Startup - -Group 7 uses all three networks. The final levels should feel like compact crisis management, not sprawling labyrinths. - -### 7-1 - Three-Key Start - -Purpose: First all-network level with one clear problem per network. - -Setup: - -- Networks: fuel, coolant, electricity. -- Reactor control sits on all three networks. -- One required consumer per network. -- Fuel has a leak, coolant has a sprinkler pressure tradeoff, electricity has a wall leak. -- One all-seeing-eye terminal is available but off the direct route. - -Timeline: - -1. Plausible first action A: isolate fuel leak. Pulse reduces fuel growth but may starve fuel consumer. -2. Plausible first action B: repair electricity leak. Pulse delays fuel/coolant response but prevents ignition and wet conduction problems. -3. Plausible first action C: use sprinkler. Pulse suppresses heat/fuel but may starve coolant and creates wet electrical risk. -4. Plausible first action D: activate terminal. Pulse reveals best sequence but allows all hazards to advance. -5. Player stabilizes the most dangerous interaction first, then restores all three services. -6. Player activates reactor. - -Win: One consumer of each network producing, reactor fed by fuel/coolant/electricity, reactor activated. - -Lose: Terminal heat, wet electricity, ignition, or robot safety failure. - -Implementation Notes: - -- This level should be forgiving: one hazard per network, short distances, strong forecasts. - -### 7-2 - Cascade Lockout - -Purpose: Require deliberate ordering because solving one system can worsen another. - -Setup: - -- Networks: fuel, coolant, electricity. -- Fuel leak threatens heat. -- Coolant sprinkler can suppress heat but wets the floor near an electric leak. -- Electricity route powers the all-seeing-eye terminal and required consumer. -- Door can contain either fuel spread or electricity spread, depending on when opened. -- Reactor requires one consumer of each network. - -Timeline: - -1. Plausible first action A: sprinkler fuel/heat area. Pulse reduces fire risk but creates wet conduction risk. -2. Plausible first action B: isolate electricity leak. Pulse makes sprinkler safer but starves electricity consumer and terminal. -3. Plausible first action C: close/open door for containment. Pulse changes surface propagation boundaries. -4. Plausible first action D: activate terminal before suppression. Pulse reveals topology but lets fuel/heat grow. -5. Player chooses containment, suppression, isolation, then service restoration in a coherent order. -6. Player activates reactor when all networks are producing and the route to control is safe. - -Win: All three required consumers producing, reactor fed by all three networks, reactor activated. - -Lose: Fire or wet-electricity cascade reaches terminal state; robot route becomes unsafe at pulse end. - -Implementation Notes: - -- This is the main campaign test of two-network lessons inside a three-network level. -- Forecast text should identify which consequence is worse: heat growth or wet conduction. - -### 7-3 - Critical Path - -Purpose: Final compact capstone: choose a startup sequence under multiple interacting failures. - -Setup: - -- Networks: fuel, coolant, electricity. -- Two consumers per network exist; one per network is required. -- Reactor control requires all three feeds. -- One fuel leak near heat, one coolant sprinkler with pressure drop, one electric wall leak near a wettable corridor, one weakened structural segment. -- One all-seeing-eye terminal, one heat shield, and one relevant neutralizer are available. - -Timeline: - -1. Plausible first action A: all-seeing-eye terminal. Pulse reveals the safest consumer set and weakened segment, but all hazards advance. -2. Plausible first action B: isolate fuel/heat branch. Pulse prevents fire growth but may force a longer fuel route. -3. Plausible first action C: isolate electricity before sprinkler use. Pulse prevents wet conduction but delays power service. -4. Plausible first action D: sprinkler first. Pulse suppresses heat/fuel but creates wetness and coolant pressure debt. -5. Plausible first action E: pick up heat shield or neutralizer. Pulse improves robot access while systems continue changing. -6. Player selects one consumer path per network, stabilizes the interaction that would become terminal first, then restores minimum required services. -7. Player activates reactor as soon as all three feeds and consumer requirements align. - -Win: At least one fuel, coolant, and electricity consumer producing; reactor control fed by all three networks; reactor activated. - -Lose: Reactor heat reaches terminal threshold, wet electricity reaches the robot, ignition creates unrecoverable heat, or structural leak cascade makes required service impossible before activation. - -Implementation Notes: - -- Final level should have multiple valid solution orders, but each order should require respecting the same causal rules. -- Do not require perfect cleanup. Winning with controlled remaining hazards is desirable. -- Use strong forecast summaries because this level has the highest choice count. +- Winning with controlled remaining hazards is valid. +- `Forecast` output should come only from fixed systemic rules while at the active terminal. ## Implementation Checklist -- Add campaign manifest entries in this exact order once level data exists. -- Keep level names stable because save data and UI can use them. -- Implement one tutorial level first, then one representative level from each group before filling all three per group. -- Prioritize mechanics in this order for jam delivery: - 1. Pulse playback and forecast wording. - 2. Fuel source, isolation, repair, and reactor activation. - 3. Coolant consumers, sprinkler discharge, pressure drop, and evaporation. - 4. Electricity wall leaks and robot safety. - 5. Doors and all-seeing-eye terminal. - 6. Heat, ignition, dilution, quenching, wet conduction. +- Add campaign manifest entries in this document order once level data exists. +- Use stable level names because save data and UI can reference them. +- Implement one tutorial level first, then one representative level from each group before filling every group. +- Prioritize mechanics in this order: + 1. `Pulse` playback and `ReactorReadiness`. + 2. `Fuel` source, leak, repair, isolation, and `ActivateReactor`. + 3. `Coolant` `ConsumerProp`, wall-mounted `CoolantSprinklerValve`, pressure drop, and `Evaporation`. + 4. `Electricity` wall leaks, `UnsafeEntryLoss`, powered `DoorProp`. + 5. `AllSeeingEyeTerminal` and terminal-local systemic `Forecast`. + 6. `Ignite`, `Heat`, `Dilute`, `Quench`, and wet-electric `Conduct`. 7. Full campaign content pass. -- If scope tightens, ship Tutorial, Group 1, one level each from Groups 2-6, and all Group 7 levels only if the interaction systems are stable. +- If scope tightens, ship tutorial, Group 1, one level each from Groups 2-5, and one final Group 6 level. ## Test Expectations Campaign implementation should add tests for: - every level loading and validating, -- required consumer counts matching networks present in each level, -- tutorial solvable with exactly one lengthy action before reactor activation, -- every non-tutorial level exposing at least two valid first lengthy actions, +- required consumer counts matching intended group mechanics, +- tutorial solvable with exactly one `LengthyAction` before `ActivateReactor`, +- every non-tutorial level exposing at least two valid first `LengthyAction` choices, - win criteria reachable for each authored level, - no level requiring a wait or fast-forward command, +- no `Forecast` visible away from an active `AllSeeingEyeTerminal`, +- no pulse-only stationary robot hazard loss, - campaign manifest order matching this document. diff --git a/docs/design.md b/docs/design.md index c3bb82f..6a76a62 100644 --- a/docs/design.md +++ b/docs/design.md @@ -14,21 +14,41 @@ The simulation core is built from: - transport network structural integrity, - deterministic fixed simulation rules and forecasts. -The game should feel logical, tactical, readable, and systemic. It should avoid randomness, action pressure, and hidden information once the player reaches an all-seeing-eye terminal. +The game should feel logical, tactical, readable, and systemic. It should avoid randomness, action pressure, and hidden information while the player is using an active `AllSeeingEyeTerminal`. + +## Terminology + +Design and campaign documents use these PascalCase keywords when referencing shared mechanics: + +- `Fuel`, `Coolant`, and `Electricity`: underground carrier networks. +- `Heat`, `LeakedFuel`, `SprinklerWater`, and `LeakedElectricity`: surface values stored on floor cells. +- `SurfaceHazard`: any unsafe floor-cell surface value or value combination. +- `Step`: one low-level deterministic simulation iteration. +- `Pulse`: the player-facing environment response after one accepted lengthy action. +- `QuickAction`: a player action that does not mutate the environment and does not trigger a `Pulse`. +- `LengthyAction`: a player action that mutates the environment and triggers one `Pulse`. +- `MoveRobot`: the quick action that moves the robot to an adjacent floor cell. +- `InteractProp`, `InteractLeak`, `ApplyHeatShield`, and `ActivateReactor`: player commands that can be accepted or refused by fixed rules. +- `FlowProp`, `IsolationValveProp`, `ConsumerProp`, `JunctionProp`, `DoorProp`, `AllSeeingEyeTerminal`, `RemedySupplyProp`, `CoolantSprinklerValve`, and `ReactorControlProp`: authored surface prop categories. +- `Enabled`, `Disabled`, `Open`, `Closed`, `Supplied`, `Starved`, and `Producing`: prop or service states. +- `Forecast`: a systemic warning generated by deterministic simulation over copied state. +- `ReactorReadiness`: the derived condition that allows `ActivateReactor`. +- `Stable`, `Caution`, `Critical`, `Ready`, `Lost`, and `Won`: derived level states. +- `UnsafeEntryLoss`: terminal loss caused when `MoveRobot` enters an unsafe destination cell. ## Action Economy There is no action budget. Player choices are either quick or lengthy. -Quick actions do not mutate the environment and do not trigger a pulse: +`QuickAction` commands do not mutate the environment and do not trigger a `Pulse`: -- `MoveRobot`: move the robot to an adjacent floor cell, reduce heat immunity movement steps if applicable, and reject movement into walls or out of bounds, +- `MoveRobot`: move the robot to an adjacent floor cell, reduce heat immunity movement steps if applicable, reject movement into walls or out of bounds, and apply `UnsafeEntryLoss` if the destination floor cell is unsafe, - selection and inspection: change only UI selection state, -- all-seeing-eye viewing: when the robot is at an all-seeing-eye terminal, allow the player to view every surface and underground layer. +- `AllSeeingEyeTerminal` viewing: when the robot is at an active terminal, allow the player to view every surface and underground layer. -Lengthy actions commit an intervention and immediately trigger one pulse: +`LengthyAction` commands commit an intervention and immediately trigger one `Pulse`: -- `InteractProp`: toggle flow props, toggle isolation valves, toggle consumers, cycle junction ratios, open or close doors, pick up remedy supplies, or activate all-seeing-eye access from a terminal, +- `InteractProp`: toggle `FlowProp` state, toggle `IsolationValveProp` state, toggle `ConsumerProp` state, cycle `JunctionProp` ratios, open or close powered `DoorProp` instances, pick up `RemedySupplyProp` instances, toggle `CoolantSprinklerValve` state, or activate `AllSeeingEyeTerminal` access from a terminal, - `InteractLeak`: repair a reachable leak or apply a matching elemental remedy, - `ApplyHeatShield`: spend one heat shield and set heat immunity movement steps, - `ActivateReactor`: activate a ready reactor at the current reactor control prop. @@ -45,25 +65,25 @@ Movement, inspection, and layer viewing do not trigger pulses. The campaign loop ## Goal And Failure -Each reactor starts offline. A reactor becomes ready when: +Each reactor starts offline. `ReactorReadiness` is true and the level enters `Ready` when: -- every underground network present beneath the reactor control cell has positive amount and intensity, -- the level has the required number of enabled, fed, producing fuel consumers, -- the level has the required number of enabled, fed, producing coolant consumers, -- the level has the required number of enabled, fed, producing electricity consumers, -- reactor heat is below the terminal condition. +- every underground network present beneath the `ReactorControlProp` cell has positive amount and positive pressure or voltage, +- the level has the required number of `Enabled` and `Producing` `Fuel` consumers, +- the level has the required number of `Enabled` and `Producing` `Coolant` consumers, +- the level has the required number of `Enabled` and `Producing` `Electricity` consumers, +- `Heat` is below the terminal condition. The required consumer counts are level properties. The reactor is not explicitly bound to any consumer positions. -When a reactor is ready, the level shows `REACTOR READY`. The player wins by activating the ready reactor at the reactor control site. +When `ReactorReadiness` is true, the level shows `REACTOR READY`. The player wins by using `ActivateReactor` at the `ReactorControlProp`, changing the level from `Ready` to `Won`. The level is lost when: -- reactor heat reaches the terminal threshold, -- the robot occupies an unsafe final hazard state without applicable protection, +- `Heat` reaches the terminal threshold, +- `MoveRobot` enters an unsafe destination floor cell without applicable protection, causing `UnsafeEntryLoss`, - fixed simulation rules mark terminal failure. -Consumer starvation blocks readiness but does not directly cause loss. +Missing `ReactorReadiness`, including missing `ReactorControlProp` feed or missing required `ConsumerProp` production, blocks `Ready` but does not directly cause `Lost`. ## Campaign Progression @@ -72,7 +92,7 @@ The campaign grows by teaching one intervention grammar at a time. A guided tuto Early levels can still use one carrier, but they need a real systems choice: - feed the service now and risk worsening a pressure-fed fault, -- isolate the damaged branch and temporarily starve a consumer or reactor feed, +- isolate the damaged branch and temporarily disable a required feed or required `ConsumerProp` production, - repair the leak while the root pressure remains unresolved, - reroute or rebalance the network before restoring service. @@ -84,10 +104,12 @@ Campaign authoring should answer two questions for each level: Recommended progression: 1. Tutorial: one safe guided action may teach that lengthy actions trigger pulses. -2. First campaign level: one carrier, one pressure-fed leak, one source, one isolation valve, one repair site, and reactor activation. -3. Next single-carrier levels: add routing, junction ratios, doors, or limited remedies. -4. Mid campaign: add heat and coolant sprinkler tradeoffs. -5. Late campaign: add electricity, wet conduction, multi-service consumers, and full three-system cascades. +2. Group 1: `Fuel` source, pressure-fed leak, `IsolationValveProp`, repair site, and direct `ReactorReadiness`. +3. Group 2: `Coolant` `ConsumerProp` production, wall-mounted `CoolantSprinklerValve`, pressure recovery, `SprinklerWater`, and `Evaporation`. +4. Group 3: `Electricity` wall leaks, powered `DoorProp`, and first `AllSeeingEyeTerminal`. +5. Group 4: `Fuel` + `Electricity` interactions where `Ignite` creates recurring `Heat`. +6. Group 5: `Coolant` + `Electricity` interactions where wet cells can `Conduct`. +7. Group 6: full three-network startup with fire, suppression, wet conduction, and terminal-local `Forecast`. ## Information @@ -101,9 +123,9 @@ The player can always inspect: - remedy inventory and supply props, - consumer state: disabled, starved, supplied, producing, or unknown, - level state, -- forecasted warnings the simulation can prove. +- `Forecast` warnings only while the robot is at an active `AllSeeingEyeTerminal`. -Underground topology and numeric network values are available through all-seeing-eye viewing after the robot visits an all-seeing-eye terminal. There is no persistent lock or unlock state in the level data. +Underground topology and numeric network values are available only while the robot is at an active `AllSeeingEyeTerminal`. There is no persistent lock or unlock state in the level data. The editor always sees and authors every layer. @@ -171,7 +193,7 @@ Surface prop categories: - consumer prop, - junction prop, - door prop, -- all-seeing-eye terminal prop, +- `AllSeeingEyeTerminal` prop, - remedy supply prop, - coolant sprinkler valve prop, - reactor control prop. @@ -188,9 +210,9 @@ During network flow, an enabled flow prop injects source carrier amount and pres An isolation valve prop is bound to fuel, coolant, or electricity and sits on a floor cell whose coordinate has exactly one matching underground carrier. It can be `Open` or `Closed`. -During network flow, an open isolation valve allows carrier propagation through the underground branch normally. A closed isolation valve blocks intentional network propagation across that underground cell's connected branch boundary. Closing a valve can stop pressure or voltage from reaching a damaged segment, but it can also starve downstream consumers, sprinkler valves, or reactor feed. +During network flow, an open isolation valve allows carrier propagation through the underground branch normally. A closed isolation valve blocks intentional network propagation across that underground cell's connected branch boundary. Closing a valve can stop pressure or voltage from reaching a damaged segment, but it can also prevent downstream `ConsumerProp` production, `CoolantSprinklerValve` discharge, or `ReactorControlProp` feed. -Toggling an isolation valve is a lengthy action and triggers one pulse. The forecast and inspection UI should make the affected branch, isolated leak, and downstream service loss readable before the player commits. +Toggling an isolation valve is a lengthy action and triggers one pulse. Inspection should make visible branch effects readable before the player commits. If the robot is at an active `AllSeeingEyeTerminal`, systemic `Forecast` output should also warn about affected underground branches, isolated leaks, and downstream service loss. ### Consumer Props @@ -208,15 +230,15 @@ The aggregate consumer prop still exposes a single switch state. Per-carrier ser ### Reactor Control Props -A reactor control prop is the activation site for one reactor. Reactor readiness is derived from level-level consumer count requirements and the networks beneath the reactor control cell. +A `ReactorControlProp` is the activation site for one reactor. `ReactorReadiness` is derived from level-level consumer count requirements and the networks beneath the `ReactorControlProp` cell. -The reactor control prop itself is not bound to any individual consumer. It is considered a local consumer for any underground network present beneath its cell: +The `ReactorControlProp` itself is not bound to any individual consumer. It has a local feed requirement for any underground network present beneath its cell: -- if no underground layer is present beneath the reactor, the local reactor feed requirement is satisfied, +- if no underground layer is present beneath the `ReactorControlProp`, the local `ReactorControlProp` feed requirement is satisfied, - if one or more underground layers are present, every present layer must have positive amount and positive intensity after network propagation, -- a present but starved reactor-under-network blocks readiness but does not directly lose the level. +- a present but unfed reactor-under-network blocks `ReactorReadiness` but does not directly lose the level. -Level properties define `RequiredFuelConsumers`, `RequiredCoolantConsumers`, and `RequiredElectricityConsumers`. For each carrier, readiness requires at least that many enabled consumer props whose per-carrier service state is `Producing`. +Level properties define `RequiredFuelConsumers`, `RequiredCoolantConsumers`, and `RequiredElectricityConsumers`. For each carrier, `ReactorReadiness` requires at least that many `Enabled` `ConsumerProp` instances whose per-carrier service state is `Producing`. ### Junction Props @@ -226,38 +248,41 @@ The engine infers incoming and outgoing branch directions from valid network top ### Doors -A door is a prop on one floor cell. Its orientation is derived from opposing wall cells: +A `DoorProp` is an electric prop on one floor cell. Its orientation is derived from opposing wall cells: - north and south walls mean the door sits in an east-west corridor and blocks west/east propagation while closed, - west and east walls mean the door sits in a north-south corridor and blocks north/south propagation while closed. -A door must have exactly one valid opposing wall pair. Closed doors block fuel, coolant, electricity, and heat propagation across the corridor cell. They do not block robot movement, underground network flow, source feeding, consumer supply, or hazards already present on either side. +A `DoorProp` must have exactly one valid opposing wall pair and exactly one connected `Electricity` underground cell at its coordinate. The player can toggle a `DoorProp` only when that local `Electricity` feed has positive amount and positive voltage. If power is lost, the `DoorProp` keeps its last physical `Open` or `Closed` state. + +Closed `DoorProp` instances block `LeakedFuel`, `SprinklerWater`, `LeakedElectricity`, and `Heat` propagation across the corridor cell. They do not block `MoveRobot`, underground network flow, source feeding, consumer supply, or hazards already present on either side. Door blocking is evaluated by the door cell and its inferred corridor axis: -- east-west corridor doors block surface interaction between the west neighbor, the door cell, and the east neighbor while closed, -- north-south corridor doors block surface interaction between the north neighbor, the door cell, and the south neighbor while closed, -- open doors do not block surface interaction, -- door props on invalid terrain or with ambiguous opposing walls are validation errors. +- east-west corridor `DoorProp` instances block surface interaction between the west neighbor, the door cell, and the east neighbor while `Closed`, +- north-south corridor `DoorProp` instances block surface interaction between the north neighbor, the door cell, and the south neighbor while `Closed`, +- `Open` `DoorProp` instances do not block surface interaction, +- `DoorProp` instances on invalid terrain, with ambiguous opposing walls, or without local `Electricity` are validation errors. ### Coolant Sprinkler Valves -A coolant sprinkler valve is a surface prop that intentionally releases coolant as sprinkler water onto authored outlet floor cells. It exists to let the player trade local fire suppression for reduced coolant service. +A `CoolantSprinklerValve` is a wall-mounted surface prop that intentionally releases `Coolant` as `SprinklerWater` onto one adjacent authored floor outlet/access face. It exists to let the player trade local fire suppression for reduced `Coolant` service. Valve behavior: -- activating a valve is a lengthy action and triggers one pulse, -- the valve adds a balance-defined amount of sprinkler water to each authored outlet cell, -- every outlet must be a valid floor cell, -- the valve must be connected to a present coolant network cell, -- discharge creates a local coolant pressure drop for the pulse and can starve nearby or downstream coolant consumers or the reactor feed, -- discharge does not repair coolant pipe damage and does not permanently disable the coolant network. +- toggling a valve is a `LengthyAction` and triggers one `Pulse`, +- an `Enabled` valve adds a balance-defined amount of `SprinklerWater` to its outlet floor cell during each `Step`, +- the valve must be authored on a wall cell with exactly one adjacent valid floor outlet/access face, +- the valve must be connected to a present `Coolant` network cell, +- discharge creates a local `Coolant` pressure drop and can prevent nearby or downstream `ConsumerProp` production or `ReactorReadiness`, +- disabling the valve or closing an upstream `IsolationValveProp` can restore `Coolant` pressure on later pulses, +- discharge does not repair coolant pipe damage and does not permanently disable the `Coolant` network. -The local pressure drop is deterministic and spatial. It should be derived from the valve's connected coolant network branch so that the player can understand why nearby consumers or reactor feed become insufficient after a sprinkler use. +The local pressure drop is deterministic and spatial. It should be derived from the valve's connected `Coolant` network branch so that the player can understand why nearby consumers or `ReactorReadiness` become insufficient after sprinkler discharge. ### Terminals And Supplies -An all-seeing-eye terminal allows full underground inspection when visited. +An `AllSeeingEyeTerminal` allows full underground inspection and `Forecast` viewing while the robot is at an active terminal. Activating the terminal is a `LengthyAction` and triggers one `Pulse`; viewing is terminal-local and does not persist after the robot leaves. Remedy supply props are single-use pickups: @@ -328,7 +353,7 @@ Leaking underground cells remain part of network propagation unless isolated by During leak injection: - fed fuel leaks add leaked fuel to the accessible floor cell, -- fed coolant pipe failures and sprinkler valves add sprinkler water to valid floor cells, +- fed coolant pipe failures and enabled `CoolantSprinklerValve` instances add sprinkler water to valid floor outlet/access cells, - fed electricity leaks add leaked electricity to the stored floor emission face, - active matching remedy blocks prevent matching element entry. @@ -433,16 +458,16 @@ Repairing a leak sets the underground cell to `Intact`, sets structural integrit Data-driven rule predicates and effects are not part of level data. Effects happen through fixed systems: -- player-issued lengthy interactions toggle props, cycle junctions, use inventory, open or close doors, repair leaks, and activate reactors, +- player-issued lengthy interactions toggle props, cycle junctions, use inventory, open or close powered doors, repair leaks, activate terminals, and activate reactors, - network propagation clears transient amount and intensity, then recomputes flow from enabled sources, - consumer resolution derives per-carrier service states from present underground layers, - structural integrity resolution weakens damaged high-pressure cells and creates leaks from low-integrity positive-pressure cells, - leak injection and sprinkler discharge add carrier hazards or sprinkler water to valid floor access cells, - surface interaction resolution spreads and reacts hazards according to the hazard pair table, -- robot safety resolves terminal loss from unsafe final hazard states after surface interactions, +- robot safety resolves `UnsafeEntryLoss` when `MoveRobot` enters an unsafe destination floor cell, - reactor state derives readiness or terminal heat loss, - duration advancement reduces remedy blocks and heat immunity counters, -- forecast refresh simulates copied state over the configured pulse horizon. +- forecast refresh simulates copied state over the configured pulse horizon for active `AllSeeingEyeTerminal` viewing. Warnings are generated by fixed forecast and status systems when conditions can be proven. @@ -456,10 +481,10 @@ One accepted lengthy interaction resolves one pulse in this order: 4. Resolve consumers and service production. 5. Resolve structural integrity and automatic leak creation. 6. Resolve the configured number of deterministic steps. -7. Resolve robot safety from the final post-pulse hazard state. -8. Derive reactor readiness and level state. +7. Derive reactor readiness and level state. +8. Preserve robot position; a `Pulse` does not cause `UnsafeEntryLoss` by itself. 9. Advance remedy blocks and heat immunity once for the pulse. -10. Refresh forecasts. +10. Refresh forecasts for active `AllSeeingEyeTerminal` viewing. Each step inside the pulse resolves in this order: @@ -473,7 +498,9 @@ Each step inside the pulse resolves in this order: ## Forecasts -Forecasts are deterministic simulations over copied state. Forecasting does not mutate the actual level. +`Forecast` output is generated systemically by deterministic simulations over copied state. Forecasting does not mutate the actual level. Level data does not author bespoke forecast text. + +`Forecast` output is visible only while the robot is at an active `AllSeeingEyeTerminal`. Away from an active terminal, the player relies on visible props, visible leaks, visible surface values, consumer state, and level state. Forecast output includes: @@ -482,7 +509,7 @@ Forecast output includes: - starved required consumer warnings, - growing hazard warnings when values cross caution or critical bands, - wet-electricity spread warnings, -- isolation valve warnings for branch shutoff, restored pressure, isolated leaks, and downstream starvation, +- isolation valve warnings for branch shutoff, restored pressure, isolated leaks, and downstream service loss, - coolant pressure-drop warnings from sprinkler valve use, - structural integrity leak warnings when weakened cells are expected to leak. @@ -499,9 +526,9 @@ Validation errors: - wall cell with surface hazards, - prop on invalid terrain, - invalid required consumer counts, -- invalid door cell, +- invalid door cell or door without local electricity, - invalid leak access, -- invalid coolant sprinkler valve outlet or missing coolant network connection, +- invalid wall-mounted `CoolantSprinklerValve` outlet/access face or missing coolant network connection, - isolation valve without exactly one matching underground carrier, - junction without exactly one underground carrier, - ambiguous junction flow, @@ -530,9 +557,9 @@ The editor authors: - multi-service consumer props, - required fuel, coolant, and electricity consumer counts, - junction props and balance-defined ratio mode index, -- door props, -- coolant sprinkler valves and their authored outlet cells, -- all-seeing-eye terminals, +- electric door props, +- wall-mounted coolant sprinkler valves and their authored outlet/access floor cells, +- `AllSeeingEyeTerminal` props, - remedy supplies, - floor leaks and electricity wall leaks with authored access faces, - initial surface hazards, sprinkler water, and heat, @@ -554,6 +581,6 @@ The loader accepts only schema-valid level data and returns clear errors for mal ## Balancing And Tests -Balancing defines source strengths, falloff, ratio math, isolation valve branch blocking, consumer predicates, leak magnitudes, sprinkler discharge, coolant pressure drops, evaporation, wet-electricity conduction, structural integrity thresholds and damage scale, interaction magnitudes, display thresholds, robot safety thresholds, terminal heat thresholds, inventory capacity, remedy duration, heat immunity duration, and forecast horizon. +Balancing defines source strengths, falloff, ratio math, isolation valve branch blocking, consumer predicates, leak magnitudes, sprinkler discharge, coolant pressure drops, evaporation, wet-electricity conduction, structural integrity thresholds and damage scale, interaction magnitudes, display thresholds, unsafe-entry thresholds, terminal heat thresholds, inventory capacity, remedy duration, heat immunity duration, and forecast horizon. -Tests assert behavior against configured balance values and bands. Coverage includes validation, inferred connectivity, isolation valve branch blocking, junction effects, multi-service consumer states, reactor readiness and activation, terminal loss, robot hazard loss, heat immunity, structural integrity degradation and leak creation, pressure-fed leak injection, leak access, sprinkler valves, coolant pressure drops, coolant mitigation, evaporation, wet-electricity spread, remedies, door blocking, forecasts, campaign authoring rules, and serialization round trips. +Tests assert behavior against configured balance values and bands. Coverage includes validation, inferred connectivity, isolation valve branch blocking, junction effects, multi-service consumer states, reactor readiness and activation, terminal loss, unsafe entry loss, heat immunity, structural integrity degradation and leak creation, pressure-fed leak injection, leak access, wall-mounted sprinkler valves, coolant pressure drops, coolant mitigation, evaporation, wet-electricity spread, remedies, powered door toggling and blocking, terminal-local forecasts, campaign authoring rules, and serialization round trips.