661 lines
32 KiB
Markdown
661 lines
32 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 and powered `AllSeeingEyeTerminal`.
|
|
- Avoid treating missing `ReactorReadiness` as a failure state; it only blocks `Ready`.
|
|
- Use `UnsafeEntryLoss` only when `MoveRobot` enters an `Unsafe` destination cell.
|
|
- 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`, `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-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.
|
|
- `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 surface hazards, 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 source startup, reactor feed, and leak isolation are separate decisions.
|
|
|
|
Setup:
|
|
|
|
- Networks: `Fuel`.
|
|
- One disabled `Fuel` `FlowProp`.
|
|
- 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 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 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; `LeakedFuel` alone does not cause `UnsafeEntryLoss`.
|
|
|
|
ImplementationNotes:
|
|
|
|
- The leak branch must be visually identifiable without underground visibility.
|
|
- No first `LengthyAction` should make the level `Ready`.
|
|
|
|
### 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` 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.
|
|
- Required consumer counts are zero.
|
|
|
|
Timeline:
|
|
|
|
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: 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.
|
|
- 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, `SprinklerControlProp`, `SprinklerWater`, `Evaporation`, and pressure recovery.
|
|
|
|
### 2-1 - Prime The Pump
|
|
|
|
Purpose: Introduce `ConsumerProp` as a required production checklist.
|
|
|
|
Setup:
|
|
|
|
- Networks: `Coolant`.
|
|
- 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: two `Coolant`.
|
|
- The `ReactorControlProp` is fed from the main branch.
|
|
|
|
Timeline:
|
|
|
|
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, 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 the difference between `Enabled`, `Supplied`, and `Producing` 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 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`.
|
|
- One upstream `IsolationValveProp` can shut the sprinkler branch without shutting the consumer branch.
|
|
|
|
Timeline:
|
|
|
|
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 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`.
|
|
|
|
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 and exactly one linked `SprinklerControlProp`.
|
|
- 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` because its linked `SprinklerControlProp` 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: No designed `UnsafeEntryLoss` from `SprinklerWater` alone; 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 powered `AllSeeingEyeTerminal`. Level 3-1 must remain readable without underground visibility.
|
|
|
|
### 3-1 - Door Circuit
|
|
|
|
Purpose: Introduce `DoorProp` power requirements while reinforcing wall `Electricity` leak handling.
|
|
|
|
Setup:
|
|
|
|
- Networks: `Electricity`.
|
|
- 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` 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: 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`.
|
|
|
|
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 - The First Eye
|
|
|
|
Purpose: Introduce powered `AllSeeingEyeTerminal` access and terminal-local `Forecast`.
|
|
|
|
Setup:
|
|
|
|
- Networks: `Electricity`.
|
|
- One `AllSeeingEyeTerminal` in a side room.
|
|
- 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: 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 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`
|
|
|
|
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` `Heat`, `LeakedElectricity`, or wet-electric cells, 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` from `Unsafe` cells.
|
|
|
|
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` from `Unsafe` cells, 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` 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: 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 `Unsafe` wet-electric cells or fixed terminal failure.
|
|
|
|
ImplementationNotes:
|
|
|
|
- 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
|
|
|
|
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` 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 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.
|
|
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 `Unsafe` wet-electric 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 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: 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 `Unsafe` wet-electric 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 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 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: 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` 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
|
|
|
|
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` while its linked `SprinklerControlProp` is `Enabled`.
|
|
- A powered `DoorProp` can contain one surface spread path.
|
|
- One `AllSeeingEyeTerminal` is reachable and requires positive `Electricity` flow.
|
|
- Required consumers: one per carrier.
|
|
|
|
Timeline:
|
|
|
|
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: 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` from `Unsafe` cells, 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 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: 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 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.
|
|
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` 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 and powered 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`, `SprinklerControlProp`, wall-mounted `CoolantSprinklerValve`, pressure drop, and `Evaporation`.
|
|
4. `Electricity` wall leaks, `UnsafeEntryLoss`, powered `DoorProp`.
|
|
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.
|
|
|
|
## 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 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.
|