xTr1m/zfxaction26_2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Clarify powered terminals and campaign hazards

Browse Source
This commit is contained in:
Frank Tovar
2026-05-14 02:58:54 +02:00
parent e90ab07e64
commit 670ee5c59c
2 changed files with 215 additions and 156 deletions
Download Patch File Download Diff File Expand all files Collapse all files

277
docs/CAMPAIGN.md
View File

@@ -7,9 +7,9 @@ This document prepares the handcrafted campaign for implementation. It reference
- 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`.
- Keep `Forecast` output systemic and available only at an active and powered `AllSeeingEyeTerminal`.
- Avoid treating missing `ReactorReadiness` as a failure state; it only blocks `Ready`.
- Use `UnsafeEntryLoss` only when `MoveRobot` enters an unsafe destination `SurfaceHazard`.
- Use `UnsafeEntryLoss` only when `MoveRobot` enters an `Unsafe` destination cell.
- Keep the campaign small enough for a two-week game jam.
## Campaign Structure
@@ -20,20 +20,22 @@ The campaign uses one tutorial plus six groups. Group 1 intentionally has two le
| ----- | ------ | -------- | ----------- |
| 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`. |
| 2 | 3 | `Coolant` | `ConsumerProp`, `Producing`, `SprinklerControlProp`, wall-mounted `CoolantSprinklerValve`, `SprinklerWater`, pressure recovery. |
| 3 | 3 | `Electricity` | wall `Electricity` leaks, repair faces, powered `DoorProp`, and powered `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
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.
Before `AllSeeingEyeTerminal` appears in 3-2, 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.
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.
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.
Do not describe numeric surface thresholds or campaign-specific formulas. Use `Unsafe` only as the formal movement consequence defined in `docs/design.md`.
Each level below includes:
- `Purpose`: the reason the level exists.
@@ -54,7 +56,7 @@ Setup:
- Networks: `Fuel`.
- One disabled `Fuel` `FlowProp` feeds the `ReactorControlProp`.
- Required consumer counts are zero.
- No leaks, no `SurfaceHazard`, no `DoorProp`, no `AllSeeingEyeTerminal`.
- No leaks, no surface hazards, no `DoorProp`, no `AllSeeingEyeTerminal`.
- Robot starts a few floor cells away from the `FlowProp`.
Timeline:
@@ -80,33 +82,33 @@ Group 1 teaches pressure-fed `Fuel` faults with no required `ConsumerProp` insta
### 1-1 - Bleed Line
Purpose: Teach that an enabled `FlowProp` can both satisfy `ReactorReadiness` and feed a visible leak.
Purpose: Teach that source startup, reactor feed, and leak isolation are separate decisions.
Setup:
- Networks: `Fuel`.
- One disabled `Fuel` `FlowProp`.
- One `ReactorControlProp` on the main branch.
- One `ReactorControlProp` on a main branch that starts blocked by a closed `IsolationValveProp`.
- One leaking `Fuel` segment on a short side branch with a reachable floor access cell.
- One `IsolationValveProp` on the side branch before the leak.
- One open `IsolationValveProp` on the side branch before the leak.
- Required consumer counts are zero.
Timeline:
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.
1. First choice A: enable the `FlowProp`; `Pulse` feeds the open leak branch and creates visible `LeakedFuel`, but the closed reactor-feed valve keeps `ReactorReadiness` missing.
2. First choice B: open the reactor-feed `IsolationValveProp`; `Pulse` changes the route but does not create `ReactorReadiness` because the source is still disabled.
3. First choice C: close the leak-branch `IsolationValveProp`; `Pulse` prevents fresh leak injection but leaves the reactor unfed.
4. Player isolates or repairs the leak, enables the source, and opens the reactor-feed branch.
5. Player uses `ActivateReactor`.
Win: `ReactorReadiness` is true for `Fuel` with zero required consumers, then `ActivateReactor`.
Lose: `Heat` terminal failure is not present; `UnsafeEntryLoss` occurs only if the player moves into unsafe `LeakedFuel`.
Lose: `Heat` terminal failure is not present; `LeakedFuel` alone does not cause `UnsafeEntryLoss`.
ImplementationNotes:
- The leak branch must be visually identifiable without underground visibility.
- Surface `LeakedFuel` amount should become unsafe only after a player mistake, not immediately.
- No first `LengthyAction` should make the level `Ready`.
### 1-2 - Valve Choice
@@ -116,7 +118,7 @@ Setup:
- Networks: `Fuel`.
- One enabled `Fuel` `FlowProp` feeds a fork.
- One fork branch reaches the `ReactorControlProp`.
- One fork branch reaches the `ReactorControlProp` through a closed reactor-feed `IsolationValveProp`.
- The other fork branch reaches a leaking `Fuel` segment.
- One main `IsolationValveProp` before the fork.
- One leak-branch `IsolationValveProp` before the leaking segment.
@@ -124,24 +126,24 @@ Setup:
Timeline:
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`.
1. First choice A: close the main `IsolationValveProp`; `Pulse` stops fresh leak injection and also prevents future reactor feed until reopened.
2. First choice B: close the leak-branch `IsolationValveProp`; `Pulse` stops fresh leak injection while preserving the main route.
3. First choice C: repair the leak; `Pulse` stops future leak injection but leaves the reactor-feed valve still closed.
4. Player opens the reactor-feed branch and keeps or restores the main feed.
5. Player uses `ActivateReactor`.
Win: `ReactorReadiness` is true for `Fuel` with zero required consumers, then `ActivateReactor`.
Lose: `UnsafeEntryLoss` from moving into unsafe `LeakedFuel`; terminal failure if fixed rules mark the level `Lost`.
Lose: No designed `UnsafeEntryLoss` from `LeakedFuel` alone; terminal failure only if fixed rules mark the level `Lost`.
ImplementationNotes:
- Use surface labels or prop placement to distinguish main valve and leak-branch valve.
- Describe a closed main feed as missing `ReactorReadiness`.
- The level must not begin `Ready`; the reactor-feed branch starts closed.
## Group 2: `Coolant`
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.
Group 2 introduces `ConsumerProp` requirements and `CoolantSprinklerValve` pressure tradeoffs. Since `Coolant` alone is not a fire system yet, these levels focus on `Producing` consumers, `SprinklerControlProp`, `SprinklerWater`, `Evaporation`, and pressure recovery.
### 2-1 - Prime The Pump
@@ -150,26 +152,29 @@ Purpose: Introduce `ConsumerProp` as a required production checklist.
Setup:
- Networks: `Coolant`.
- One disabled `Coolant` `FlowProp`.
- Two visible `Coolant` `ConsumerProp` instances.
- One enabled `Coolant` `FlowProp`.
- Two visible `Coolant` `ConsumerProp` instances:
- one starts `Enabled` but is behind a closed branch `IsolationValveProp`, so it is not `Producing`,
- one starts `Disabled` on a supplied branch, so it is supplied but not `Producing`.
- One `ReactorControlProp`.
- Required consumers: one `Coolant`.
- One branch `IsolationValveProp` can cut off one consumer while leaving another consumer and the control feed available.
- Required consumers: two `Coolant`.
- The `ReactorControlProp` is fed from the main branch.
Timeline:
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`.
1. First choice A: enable the supplied but disabled `ConsumerProp`; `Pulse` makes only that consumer `Producing`.
2. First choice B: open the blocked branch `IsolationValveProp`; `Pulse` supplies the already enabled consumer.
3. First choice C: close the main branch; `Pulse` demonstrates that consumer production depends on supply and delays readiness.
4. Player sets both consumer branches so both `Coolant` `ConsumerProp` instances are `Enabled` and `Producing`.
5. Player uses `ActivateReactor`.
Win: `ReactorControlProp` has positive `Coolant` amount and pressure, at least one required `Coolant` `ConsumerProp` is `Enabled` and `Producing`, then `ActivateReactor`.
Win: `ReactorControlProp` has positive `Coolant` amount and pressure, two required `Coolant` `ConsumerProp` instances are `Enabled` and `Producing`, then `ActivateReactor`.
Lose: No designed terminal pressure; only invalid actions or explicit terminal rules.
ImplementationNotes:
- This level introduces `ConsumerProp` before any `CoolantSprinklerValve`.
- This level introduces the difference between `Enabled`, `Supplied`, and `Producing` before any `CoolantSprinklerValve`.
- Use visible prop placement; no `AllSeeingEyeTerminal`.
### 2-2 - Sprinkler Debt
@@ -180,7 +185,8 @@ Setup:
- Networks: `Coolant`.
- One enabled `Coolant` `FlowProp`.
- One wall-mounted `CoolantSprinklerValve` starts `Enabled`.
- One wall-mounted `CoolantSprinklerValve` starts discharging because its linked `SprinklerControlProp` starts `Enabled`.
- One nearby `SprinklerControlProp` is the only direct sprinkler interaction.
- 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`.
@@ -188,9 +194,9 @@ Setup:
Timeline:
1. First choice A: disable the `CoolantSprinklerValve`; `Pulse` stops discharge and allows pressure recovery.
1. First choice A: disable the linked `SprinklerControlProp`; `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.
3. First choice C: enable or adjust the required `ConsumerProp` first; `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`.
@@ -202,7 +208,7 @@ Lose: No authored `Heat` or fire; avoid loss pressure except explicit terminal r
ImplementationNotes:
- Do not author standalone `Heat` in this `Coolant`-only level.
- Sprinkler is wall-mounted with exactly one outlet/access floor face.
- Sprinkler is wall-mounted with exactly one outlet/access floor face and exactly one linked `SprinklerControlProp`.
- This level visually teaches `SprinklerWater` and `Evaporation` without suppression yet.
### 2-3 - Split Flow
@@ -215,7 +221,7 @@ Setup:
- One enabled `Coolant` `FlowProp`.
- One `JunctionProp` controls two consumer branches.
- Three visible `Coolant` `ConsumerProp` instances.
- One wall-mounted `CoolantSprinklerValve` starts `Disabled`.
- One wall-mounted `CoolantSprinklerValve` starts `Disabled` because its linked `SprinklerControlProp` starts `Disabled`.
- Required consumers: two `Coolant`.
- One branch has a weakened or leaking `Coolant` segment that emits `SprinklerWater` when fed.
@@ -229,7 +235,7 @@ Timeline:
Win: `ReactorControlProp` has positive `Coolant` amount and pressure, two `Coolant` `ConsumerProp` instances are `Enabled` and `Producing`, then `ActivateReactor`.
Lose: `UnsafeEntryLoss` only if the player moves into an unsafe `SurfaceHazard`; otherwise no designed terminal pressure.
Lose: No designed `UnsafeEntryLoss` from `SprinklerWater` alone; otherwise no designed terminal pressure.
ImplementationNotes:
@@ -238,98 +244,104 @@ ImplementationNotes:
## Group 3: `Electricity`
Group 3 introduces wall `Electricity` leaks, powered `DoorProp` behavior, and then `AllSeeingEyeTerminal`. Levels 3-1 and 3-2 must remain readable without underground visibility.
Group 3 introduces wall `Electricity` leaks, powered `DoorProp` behavior, and then powered `AllSeeingEyeTerminal`. Level 3-1 must remain readable without underground visibility.
### 3-1 - Live Face
### 3-1 - Door Circuit
Purpose: Teach wall `Electricity` leak access and repair from the adjacent emission face.
Purpose: Introduce `DoorProp` power requirements while reinforcing wall `Electricity` leak handling.
Setup:
- Networks: `Electricity`.
- One disabled `Electricity` `FlowProp`.
- One enabled `Electricity` `FlowProp`.
- One `DoorProp` begins `Closed` and its local supply branch starts blocked by an `IsolationValveProp`.
- One wall-based `Electricity` leak with exactly one adjacent floor emission/repair face.
- One `Electricity` `ConsumerProp`.
- One `ReactorControlProp`.
- One `Electricity` `ConsumerProp` starts `Disabled` on the blocked door-supply branch.
- One `ReactorControlProp` is fed by the blocked door-supply branch.
- Required consumers: one `Electricity`.
- One `IsolationValveProp` can cut voltage to the leaking wall segment.
Timeline:
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.
1. First choice A: interact with the unpowered `DoorProp`; `Pulse` resolves, the door stays `Closed`, and the leak can continue.
2. First choice B: open the door-supply `IsolationValveProp`; `Pulse` powers the door and keeps the leak state readable.
3. First choice C: isolate or repair the wall leak first; `Pulse` reduces `LeakedElectricity` risk before door operation.
4. Player powers and toggles the `DoorProp`, then restores consumer production and reactor feed.
5. Player uses `ActivateReactor`.
Win: `ReactorControlProp` has positive `Electricity` amount and voltage, one `Electricity` `ConsumerProp` is `Enabled` and `Producing`, then `ActivateReactor`.
Lose: `UnsafeEntryLoss` from moving into unsafe `LeakedElectricity`; terminal failure if fixed rules mark `Lost`.
Lose: `UnsafeEntryLoss` from moving into `Unsafe` `LeakedElectricity`; terminal failure if fixed rules mark `Lost`.
ImplementationNotes:
- Emission/repair face must be visually unambiguous.
- No `Forecast`; no `AllSeeingEyeTerminal`.
- Door supply and leak isolation must be readable from nearby props.
### 3-2 - Powered Door
### 3-2 - The First Eye
Purpose: Introduce `DoorProp` toggling as an electricity-dependent action.
Setup:
- 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. 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: `ReactorControlProp` has positive `Electricity` amount and voltage, one `Electricity` `ConsumerProp` is `Enabled` and `Producing`, then `ActivateReactor`.
Lose: `UnsafeEntryLoss` from entering unsafe `LeakedElectricity`; terminal failure if fixed rules mark `Lost`.
ImplementationNotes:
- 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 terminal-local underground visibility and systemic `Forecast`.
Purpose: Introduce powered `AllSeeingEyeTerminal` access and terminal-local `Forecast`.
Setup:
- 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.
- The terminal's local supply branch starts blocked by an `IsolationValveProp`.
- One `Electricity` `ConsumerProp` starts `Disabled` on a clearly separate supplied branch.
- One `ReactorControlProp` starts blocked by a closed reactor-feed `IsolationValveProp`.
- Required consumers: one `Electricity`.
- One simple wall `Electricity` leak is visible from the surface.
- One optional `DoorProp` is present only if its powered state remains obvious without terminal visibility.
Timeline:
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`.
1. First choice A: interact with the unpowered `AllSeeingEyeTerminal`; `Pulse` resolves, but no underground view or `Forecast` appears.
2. First choice B: power the terminal branch; `Pulse` makes later terminal use effective.
3. First choice C: isolate or repair the visible leak first; `Pulse` reduces visible risk but delays terminal information.
4. Player activates the powered terminal, uses systemic `Forecast`, restores required production and control feed.
5. Player uses `ActivateReactor`.
Win: `ReactorControlProp` has positive `Electricity` amount and voltage, one `Electricity` `ConsumerProp` is `Enabled` and `Producing`, then `ActivateReactor`.
Lose: `UnsafeEntryLoss` from unsafe `LeakedElectricity`, terminal `Heat` if generated by fixed rules, or another fixed terminal rule.
Lose: `UnsafeEntryLoss` from entering `Unsafe` `LeakedElectricity`; terminal failure if fixed rules mark `Lost`.
ImplementationNotes:
- This is the first campaign level with `Forecast`.
- `Forecast` output must be systemic; do not author level text.
- The level remains solvable from visible information, but powering the terminal should clearly improve confidence.
### 3-3 - Blind Grid
Purpose: Require powered `AllSeeingEyeTerminal` use in a complex electricity routing puzzle.
Setup:
- Networks: `Electricity`.
- One `AllSeeingEyeTerminal` starts unpowered on a branch that can be energized early.
- Two required `Electricity` `ConsumerProp` instances sit on different branches.
- One `DoorProp` contains surface propagation along a useful route and requires local power.
- One visible wall `Electricity` leak and one weakened high-voltage segment are on different possible routes.
- Required consumers: two `Electricity`.
Timeline:
1. First choice A: power the terminal branch; `Pulse` enables a later useful terminal interaction while other risks advance.
2. First choice B: interact with the unpowered terminal first; `Pulse` changes nothing and demonstrates the cost of missing power.
3. First choice C: route power toward visible consumers without terminal information; `Pulse` may feed one consumer while worsening the hidden weak route.
4. Player activates the powered terminal, reads underground topology and systemic `Forecast`, then chooses which branches to isolate, repair, or power.
5. Player produces both required consumers and powers the `ReactorControlProp`.
6. Player uses `ActivateReactor`.
Win: `ReactorControlProp` has positive `Electricity` amount and voltage, two `Electricity` `ConsumerProp` instances are `Enabled` and `Producing`, then `ActivateReactor`.
Lose: `UnsafeEntryLoss` from `Unsafe` `LeakedElectricity`, terminal `Heat` if generated by fixed rules, or another fixed terminal rule.
ImplementationNotes:
- This is the first level where terminal use is essential rather than optional.
- The visible-only read should be plausible but incomplete.
## Group 4: `Fuel` + `Electricity`
@@ -358,7 +370,7 @@ Timeline:
Win: `ReactorReadiness` is true for `Fuel` and `Electricity`, required consumers are `Enabled` and `Producing`, then `ActivateReactor`.
Lose: terminal `Heat`, `UnsafeEntryLoss` from unsafe `LeakedFuel` or `LeakedElectricity`, or fixed terminal failure.
Lose: terminal `Heat`, `UnsafeEntryLoss` from `Unsafe` `Heat`, `LeakedElectricity`, or wet-electric cells, or fixed terminal failure.
ImplementationNotes:
@@ -388,7 +400,7 @@ Timeline:
Win: `ReactorReadiness` is true for `Fuel` and `Electricity`, required consumers are `Enabled` and `Producing`, then `ActivateReactor`.
Lose: terminal `Heat` or `UnsafeEntryLoss`.
Lose: terminal `Heat` or `UnsafeEntryLoss` from `Unsafe` cells.
ImplementationNotes:
@@ -418,7 +430,7 @@ Timeline:
Win: `ReactorReadiness` is true for `Fuel` and `Electricity`, required consumers are `Enabled` and `Producing`, then `ActivateReactor`.
Lose: terminal `Heat`, `UnsafeEntryLoss`, or fixed terminal failure.
Lose: terminal `Heat`, `UnsafeEntryLoss` from `Unsafe` cells, or fixed terminal failure.
ImplementationNotes:
@@ -436,26 +448,28 @@ Purpose: Teach wet-electricity `Conduct`.
Setup:
- Networks: `Coolant`, `Electricity`.
- One wall-mounted `CoolantSprinklerValve` can wet a corridor.
- One wall-mounted `CoolantSprinklerValve` starts discharging because its linked `SprinklerControlProp` starts `Enabled`.
- Initial `SprinklerWater` is visible in a corridor between the sprinkler outlet and an electricity emission face.
- 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. 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.
1. First choice A: disable the linked `SprinklerControlProp`; `Pulse` stops new `SprinklerWater` and allows pressure recovery.
2. First choice B: isolate or repair the `Electricity` leak first; `Pulse` reduces wet-conduction risk before drying.
3. First choice C: energize electricity production first; `Pulse` shows why wet cells and `LeakedElectricity` are a bad combination.
4. If `LeakedElectricity` reaches wet cells, fixed rules use `Conduct`.
5. Player restores both required services and activates.
Win: `ReactorReadiness` is true for `Coolant` and `Electricity`, required consumers are `Enabled` and `Producing`, then `ActivateReactor`.
Lose: `UnsafeEntryLoss` from wet-electric unsafe cells or fixed terminal failure.
Lose: `UnsafeEntryLoss` from `Unsafe` wet-electric cells or fixed terminal failure.
ImplementationNotes:
- No authored forecast prose; terminal-local systemic `Forecast` may warn about wet conduction if a terminal exists.
- No authored forecast prose; terminal-local systemic `Forecast` may warn about wet conduction if a powered terminal exists.
- Do not present sprinkler activation as the intended first solution; the problem starts from an already wet corridor.
### 5-2 - Dry Before Live
@@ -465,13 +479,13 @@ Setup:
- 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 wall-mounted `CoolantSprinklerValve` maintains wetness and pressure debt because its linked `SprinklerControlProp` starts `Enabled`.
- A powered `DoorProp` can contain electrical surface propagation.
- Required consumers: one `Coolant`, one `Electricity`.
Timeline:
1. First choice A: disable the `CoolantSprinklerValve`; `Pulse` stops new `SprinklerWater` and allows `Evaporation`.
1. First choice A: disable the linked `SprinklerControlProp`; `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.
@@ -479,7 +493,7 @@ Timeline:
Win: `ReactorReadiness` is true for `Coolant` and `Electricity`, required consumers are `Enabled` and `Producing`, then `ActivateReactor`.
Lose: `UnsafeEntryLoss` from wet-electric unsafe cells or fixed terminal failure.
Lose: `UnsafeEntryLoss` from `Unsafe` wet-electric cells or fixed terminal failure.
ImplementationNotes:
@@ -493,22 +507,22 @@ Purpose: Combine `AllSeeingEyeTerminal` with wet-conduction routing.
Setup:
- Networks: `Coolant`, `Electricity`.
- One `AllSeeingEyeTerminal` is reachable but requires a `Pulse` to activate.
- Two wall-mounted `CoolantSprinklerValve` instances affect different outlet faces.
- One `AllSeeingEyeTerminal` is reachable but must be powered before activation reveals `Forecast`.
- Two wall-mounted `CoolantSprinklerValve` instances affect different outlet faces through linked `SprinklerControlProp` instances.
- One `Electricity` route overlaps one wettable corridor underground.
- Required consumers: one `Coolant`, one `Electricity`.
Timeline:
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.
1. First choice A: power the `AllSeeingEyeTerminal` branch; a later terminal interaction enables terminal-local visibility and systemic `Forecast`.
2. First choice B: disable the nearest `SprinklerControlProp` or isolate its coolant supply 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: `ReactorReadiness` is true for `Coolant` and `Electricity`, required consumers are `Enabled` and `Producing`, then `ActivateReactor`.
Lose: `UnsafeEntryLoss` from wet-electric unsafe cells, or fixed terminal failure.
Lose: `UnsafeEntryLoss` from `Unsafe` wet-electric cells, or fixed terminal failure.
ImplementationNotes:
@@ -528,26 +542,29 @@ Setup:
- 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.
- One visible `Fuel` leak, one wall-mounted `CoolantSprinklerValve` whose linked `SprinklerControlProp` starts `Enabled`, and one wall `Electricity` leak.
- One optional `AllSeeingEyeTerminal` is off the direct route and requires positive `Electricity` flow.
- One `HeatShield` and one relevant `RemedySupplyProp` are available for short-term mitigation.
Timeline:
1. First choice A: isolate or repair the `Fuel` leak.
2. First choice B: disable or isolate the `CoolantSprinklerValve` to restore pressure.
2. First choice B: disable the linked `SprinklerControlProp` or isolate the sprinkler branch 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`.
4. First choice D: power the `AllSeeingEyeTerminal` branch for later terminal-local `Forecast`.
5. First choice E: pick up `HeatShield` or a `RemedySupplyProp` to buy access to one risky intervention.
6. Player restores required production for all three carriers.
7. Player uses `ActivateReactor`.
Win: `ReactorReadiness` is true for all three carriers, one required `ConsumerProp` per carrier is `Enabled` and `Producing`, then `ActivateReactor`.
Lose: terminal `Heat`, `UnsafeEntryLoss`, wet-electric terminal failure, or other fixed terminal failure.
Lose: terminal `Heat`, `UnsafeEntryLoss` from `Unsafe` cells, wet-electric terminal failure, or other fixed terminal failure.
ImplementationNotes:
- Keep this forgiving and compact.
- Do not require hazard cleanup after `Ready`.
- Inventory mitigation should help with access or timing, not replace network repair and routing.
### 6-2 - Cascade Lockout
@@ -557,23 +574,23 @@ Setup:
- 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 wall-mounted `CoolantSprinklerValve` can quench or dilute but creates `SprinklerWater` while its linked `SprinklerControlProp` is `Enabled`.
- A powered `DoorProp` can contain one surface spread path.
- One `AllSeeingEyeTerminal` is reachable.
- One `AllSeeingEyeTerminal` is reachable and requires positive `Electricity` flow.
- Required consumers: one per carrier.
Timeline:
1. First choice A: use the sprinkler to suppress/dilute; `Pulse` creates wet-conduction risk.
1. First choice A: use the `SprinklerControlProp` 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`.
4. First choice D: power the `AllSeeingEyeTerminal` branch for later systemic `Forecast`.
5. Player chooses containment, suppression, isolation, and production order.
6. Player uses `ActivateReactor`.
Win: `ReactorReadiness` is true for all three carriers, one required `ConsumerProp` per carrier is `Enabled` and `Producing`, then `ActivateReactor`.
Lose: terminal `Heat`, `UnsafeEntryLoss`, wet-electric terminal failure, or other fixed terminal failure.
Lose: terminal `Heat`, `UnsafeEntryLoss` from `Unsafe` cells, wet-electric terminal failure, or other fixed terminal failure.
ImplementationNotes:
@@ -589,14 +606,14 @@ Setup:
- 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.
- One `Fuel` leak, one wall-mounted `CoolantSprinklerValve` whose linked `SprinklerControlProp` starts `Enabled`, one wall `Electricity` leak, one powered `DoorProp`, and one weakened structural segment.
- One powered-route `AllSeeingEyeTerminal`, one `HeatShield`, and one relevant `RemedySupplyProp` are available.
Timeline:
1. First choice A: activate the `AllSeeingEyeTerminal`; `Pulse` grants terminal-local topology and `Forecast` while hazards advance.
1. First choice A: power the `AllSeeingEyeTerminal` branch; a later terminal interaction 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.
3. First choice C: disable the linked `SprinklerControlProp` 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.
@@ -604,12 +621,12 @@ Timeline:
Win: `ReactorReadiness` is true for all three carriers, one required `ConsumerProp` per carrier is `Enabled` and `Producing`, then `ActivateReactor`.
Lose: terminal `Heat`, `UnsafeEntryLoss`, wet-electric terminal failure, or other fixed terminal failure.
Lose: terminal `Heat`, `UnsafeEntryLoss` from `Unsafe` cells, wet-electric terminal failure, or other fixed terminal failure.
ImplementationNotes:
- Winning with controlled remaining hazards is valid.
- `Forecast` output should come only from fixed systemic rules while at the active terminal.
- `Forecast` output should come only from fixed systemic rules while at the active and powered terminal.
## Implementation Checklist
@@ -619,9 +636,9 @@ ImplementationNotes:
- 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`.
3. `Coolant` `ConsumerProp`, `SprinklerControlProp`, wall-mounted `CoolantSprinklerValve`, pressure drop, and `Evaporation`.
4. `Electricity` wall leaks, `UnsafeEntryLoss`, powered `DoorProp`.
5. `AllSeeingEyeTerminal` and terminal-local systemic `Forecast`.
5. Powered `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-5, and one final Group 6 level.
@@ -636,6 +653,8 @@ Campaign implementation should add tests for:
- 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 `Forecast` visible away from an active and powered `AllSeeingEyeTerminal`,
- unpowered `DoorProp` and `AllSeeingEyeTerminal` interactions causing no state change while still triggering a `Pulse`,
- no direct interaction with `CoolantSprinklerValve`; sprinkler changes happen through linked `SprinklerControlProp`,
- no pulse-only stationary robot hazard loss,
- campaign manifest order matching this document.