642 lines
29 KiB
Markdown
642 lines
29 KiB
Markdown
# Reactor Maintenance Campaign Design
|
||
|
||
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 `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 six groups. Group 1 intentionally has two levels; Groups 2-6 have three levels each.
|
||
|
||
| Group | Levels | Networks | Main Lesson |
|
||
| ----- | ------ | -------- | ----------- |
|
||
| 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
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
Each level below includes:
|
||
|
||
- `Purpose`: the reason the level exists.
|
||
- `Setup`: authored starting conditions.
|
||
- `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 one accepted `LengthyAction` triggers one `Pulse`, after which `Ready` can be activated.
|
||
|
||
Setup:
|
||
|
||
- 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 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: `ReactorControlProp` has positive `Fuel` amount and pressure, required consumer counts are zero, and `ActivateReactor` changes level state to `Won`.
|
||
|
||
Lose: No designed loss condition beyond invalid actions; this is guided tutorial content.
|
||
|
||
ImplementationNotes:
|
||
|
||
- This is the only single-action setup.
|
||
- Do not include `Forecast`; no `AllSeeingEyeTerminal` exists.
|
||
|
||
## Group 1: `Fuel`
|
||
|
||
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 an enabled `FlowProp` can both satisfy `ReactorReadiness` and feed a visible leak.
|
||
|
||
Setup:
|
||
|
||
- 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. 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: `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`.
|
||
|
||
ImplementationNotes:
|
||
|
||
- 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 - Valve Choice
|
||
|
||
Purpose: Teach branch-specific isolation versus over-isolating the main feed.
|
||
|
||
Setup:
|
||
|
||
- 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. 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: `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`.
|
||
|
||
ImplementationNotes:
|
||
|
||
- Use surface labels or prop placement to distinguish main valve and leak-branch valve.
|
||
- Describe a closed main feed as missing `ReactorReadiness`.
|
||
|
||
## 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.
|
||
|
||
### 2-1 - Prime The Pump
|
||
|
||
Purpose: Introduce `ConsumerProp` as a required production checklist.
|
||
|
||
Setup:
|
||
|
||
- 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. 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: `ReactorControlProp` has positive `Coolant` amount and pressure, at least one required `Coolant` `ConsumerProp` is `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`.
|
||
- Use visible prop placement; no `AllSeeingEyeTerminal`.
|
||
|
||
### 2-2 - Sprinkler Debt
|
||
|
||
Purpose: Teach that an enabled wall-mounted `CoolantSprinklerValve` can reduce pressure until disabled or isolated.
|
||
|
||
Setup:
|
||
|
||
- 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. 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: `ReactorControlProp` has positive `Coolant` amount and pressure, one `Coolant` `ConsumerProp` is `Enabled` and `Producing`, then `ActivateReactor`.
|
||
|
||
Lose: No authored `Heat` or fire; avoid loss pressure except explicit terminal rules.
|
||
|
||
ImplementationNotes:
|
||
|
||
- 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 `JunctionProp` routing and consumer requirements in a readable `Coolant` network.
|
||
|
||
Setup:
|
||
|
||
- 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. 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: `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.
|
||
|
||
ImplementationNotes:
|
||
|
||
- Keep all relevant branches readable from surface prop placement.
|
||
- No `Forecast`; no `AllSeeingEyeTerminal`.
|
||
|
||
## 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.
|
||
|
||
### 3-1 - Live Face
|
||
|
||
Purpose: Teach wall `Electricity` leak access and repair from the adjacent emission face.
|
||
|
||
Setup:
|
||
|
||
- 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. 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: `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`.
|
||
|
||
ImplementationNotes:
|
||
|
||
- Emission/repair face must be visually unambiguous.
|
||
- No `Forecast`; no `AllSeeingEyeTerminal`.
|
||
|
||
### 3-2 - Powered Door
|
||
|
||
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`.
|
||
|
||
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.
|
||
- Required consumers: one `Electricity`.
|
||
|
||
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`.
|
||
|
||
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.
|
||
|
||
ImplementationNotes:
|
||
|
||
- This is the first campaign level with `Forecast`.
|
||
- `Forecast` output must be systemic; do not author level text.
|
||
|
||
## Group 4: `Fuel` + `Electricity`
|
||
|
||
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 - First Spark
|
||
|
||
Purpose: Teach that combining `LeakedFuel` and `LeakedElectricity` can create `Heat`.
|
||
|
||
Setup:
|
||
|
||
- 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. 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: `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.
|
||
|
||
ImplementationNotes:
|
||
|
||
- Use only designed interactions from the hazard pair table.
|
||
- `Heat` appears as a consequence of `Ignite`, not as an arbitrary authored patch.
|
||
|
||
### 4-2 - Break Before Make
|
||
|
||
Purpose: Teach source sequencing: fixing or isolating first can be safer than powering both networks.
|
||
|
||
Setup:
|
||
|
||
- 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. 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: `ReactorReadiness` is true for `Fuel` and `Electricity`, required consumers are `Enabled` and `Producing`, then `ActivateReactor`.
|
||
|
||
Lose: terminal `Heat` or `UnsafeEntryLoss`.
|
||
|
||
ImplementationNotes:
|
||
|
||
- 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 - Hot Bypass
|
||
|
||
Purpose: Combine structural integrity, route choice, and fire risk.
|
||
|
||
Setup:
|
||
|
||
- 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. 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: `ReactorReadiness` is true for `Fuel` and `Electricity`, required consumers are `Enabled` and `Producing`, then `ActivateReactor`.
|
||
|
||
Lose: terminal `Heat`, `UnsafeEntryLoss`, or fixed terminal failure.
|
||
|
||
ImplementationNotes:
|
||
|
||
- `HeatShield` only affects movement safety; it does not quench `Heat`.
|
||
- Avoid perfect cleanup requirements.
|
||
|
||
## Group 5: `Coolant` + `Electricity`
|
||
|
||
Group 5 teaches that `SprinklerWater` is useful system material but dangerous with `Electricity`. `Evaporation` becomes important without adding a wait command.
|
||
|
||
### 5-1 - Charged Water
|
||
|
||
Purpose: Teach wet-electricity `Conduct`.
|
||
|
||
Setup:
|
||
|
||
- 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. 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: `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.
|
||
|
||
ImplementationNotes:
|
||
|
||
- No authored forecast prose; terminal-local systemic `Forecast` may warn about wet conduction if a terminal exists.
|
||
|
||
### 5-2 - Dry Before Live
|
||
|
||
Purpose: Teach that `Evaporation` can be part of useful action sequencing.
|
||
|
||
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 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`.
|
||
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: `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.
|
||
|
||
ImplementationNotes:
|
||
|
||
- Do not add a wait or fast-forward action.
|
||
- Do not author standalone `Heat`; drying comes from `Evaporation` rules during pulses.
|
||
|
||
### 5-3 - Eye In The Storm
|
||
|
||
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 `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.
|
||
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.
|
||
|
||
ImplementationNotes:
|
||
|
||
- Terminal should reveal why one sprinkler/electric route combination is riskier.
|
||
- `Forecast` remains systemic and terminal-local.
|
||
|
||
## Group 6: Full Startup
|
||
|
||
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 - Three-Key Start
|
||
|
||
Purpose: First all-network level with one readable problem per network.
|
||
|
||
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.
|
||
|
||
Timeline:
|
||
|
||
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: `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.
|
||
|
||
ImplementationNotes:
|
||
|
||
- Keep this forgiving and compact.
|
||
- Do not require hazard cleanup after `Ready`.
|
||
|
||
### 6-2 - Cascade Lockout
|
||
|
||
Purpose: Require ordering because one fix can worsen another surface interaction.
|
||
|
||
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 powered `DoorProp` can contain one surface spread path.
|
||
- One `AllSeeingEyeTerminal` is reachable.
|
||
- Required consumers: one per carrier.
|
||
|
||
Timeline:
|
||
|
||
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: `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.
|
||
|
||
ImplementationNotes:
|
||
|
||
- This is the main test of previous group lessons in one compact level.
|
||
- Door operation must depend on local `Electricity` supply.
|
||
|
||
### 6-3 - Critical Path
|
||
|
||
Purpose: Final capstone with multiple valid solution orders.
|
||
|
||
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.
|
||
|
||
Timeline:
|
||
|
||
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: `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.
|
||
|
||
ImplementationNotes:
|
||
|
||
- 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 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-5, and one final Group 6 level.
|
||
|
||
## Test Expectations
|
||
|
||
Campaign implementation should add tests for:
|
||
|
||
- every level loading and validating,
|
||
- 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.
|