Clarify powered terminals and campaign hazards
This commit is contained in:
277
docs/CAMPAIGN.md
277
docs/CAMPAIGN.md
@@ -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.
|
||||
|
||||
@@ -14,7 +14,7 @@ The simulation core is built from:
|
||||
- transport network structural integrity,
|
||||
- deterministic fixed simulation rules and forecasts.
|
||||
|
||||
The game should feel logical, tactical, readable, and systemic. It should avoid randomness, action pressure, and hidden information while the player is using an active `AllSeeingEyeTerminal`.
|
||||
The game should feel logical, tactical, readable, and systemic. It should avoid randomness, action pressure, and hidden information while the player is using an active and powered `AllSeeingEyeTerminal`.
|
||||
|
||||
## Terminology
|
||||
|
||||
@@ -22,19 +22,20 @@ Design and campaign documents use these PascalCase keywords when referencing sha
|
||||
|
||||
- `Fuel`, `Coolant`, and `Electricity`: underground carrier networks.
|
||||
- `Heat`, `LeakedFuel`, `SprinklerWater`, and `LeakedElectricity`: surface values stored on floor cells.
|
||||
- `SurfaceHazard`: any unsafe floor-cell surface value or value combination.
|
||||
- `Unsafe`: derived floor-cell movement state caused by dangerous surface values or value combinations.
|
||||
- `Step`: one low-level deterministic simulation iteration.
|
||||
- `Pulse`: the player-facing environment response after one accepted lengthy action.
|
||||
- `QuickAction`: a player action that does not mutate the environment and does not trigger a `Pulse`.
|
||||
- `LengthyAction`: a player action that mutates the environment and triggers one `Pulse`.
|
||||
- `MoveRobot`: the quick action that moves the robot to an adjacent floor cell.
|
||||
- `InteractProp`, `InteractLeak`, `ApplyHeatShield`, and `ActivateReactor`: player commands that can be accepted or refused by fixed rules.
|
||||
- `FlowProp`, `IsolationValveProp`, `ConsumerProp`, `JunctionProp`, `DoorProp`, `AllSeeingEyeTerminal`, `RemedySupplyProp`, `CoolantSprinklerValve`, and `ReactorControlProp`: authored surface prop categories.
|
||||
- `FlowProp`, `IsolationValveProp`, `ConsumerProp`, `JunctionProp`, `DoorProp`, `AllSeeingEyeTerminal`, `RemedySupplyProp`, `SprinklerControlProp`, `CoolantSprinklerValve`, and `ReactorControlProp`: authored surface prop categories.
|
||||
- `PoweredProp`: a prop that requires positive local `Electricity` flow before its interaction can take effect.
|
||||
- `Enabled`, `Disabled`, `Open`, `Closed`, `Supplied`, `Starved`, and `Producing`: prop or service states.
|
||||
- `Forecast`: a systemic warning generated by deterministic simulation over copied state.
|
||||
- `ReactorReadiness`: the derived condition that allows `ActivateReactor`.
|
||||
- `Stable`, `Caution`, `Critical`, `Ready`, `Lost`, and `Won`: derived level states.
|
||||
- `UnsafeEntryLoss`: terminal loss caused when `MoveRobot` enters an unsafe destination cell.
|
||||
- `UnsafeEntryLoss`: terminal loss caused when `MoveRobot` enters an `Unsafe` destination cell.
|
||||
|
||||
## Action Economy
|
||||
|
||||
@@ -42,19 +43,21 @@ There is no action budget. Player choices are either quick or lengthy.
|
||||
|
||||
`QuickAction` commands do not mutate the environment and do not trigger a `Pulse`:
|
||||
|
||||
- `MoveRobot`: move the robot to an adjacent floor cell, reduce heat immunity movement steps if applicable, reject movement into walls or out of bounds, and apply `UnsafeEntryLoss` if the destination floor cell is unsafe,
|
||||
- `MoveRobot`: move the robot to an adjacent floor cell, reduce heat immunity movement steps if applicable, reject movement into walls or out of bounds, and apply `UnsafeEntryLoss` if the destination floor cell is `Unsafe`,
|
||||
- selection and inspection: change only UI selection state,
|
||||
- `AllSeeingEyeTerminal` viewing: when the robot is at an active terminal, allow the player to view every surface and underground layer.
|
||||
- `AllSeeingEyeTerminal` viewing: when the robot is at an active and powered terminal, allow the player to view every surface and underground layer.
|
||||
|
||||
`LengthyAction` commands commit an intervention and immediately trigger one `Pulse`:
|
||||
|
||||
- `InteractProp`: toggle `FlowProp` state, toggle `IsolationValveProp` state, toggle `ConsumerProp` state, cycle `JunctionProp` ratios, open or close powered `DoorProp` instances, pick up `RemedySupplyProp` instances, toggle `CoolantSprinklerValve` state, or activate `AllSeeingEyeTerminal` access from a terminal,
|
||||
- `InteractProp`: toggle `FlowProp` state, toggle `IsolationValveProp` state, toggle `ConsumerProp` state, cycle `JunctionProp` ratios, open or close powered `DoorProp` instances, pick up `RemedySupplyProp` instances, toggle `SprinklerControlProp` state, or activate powered `AllSeeingEyeTerminal` access from a terminal,
|
||||
- `InteractLeak`: repair a reachable leak or apply a matching elemental remedy,
|
||||
- `ApplyHeatShield`: spend one heat shield and set heat immunity movement steps,
|
||||
- `ActivateReactor`: activate a ready reactor at the current reactor control prop.
|
||||
|
||||
Invalid actions report refusal and do not mutate gameplay state.
|
||||
|
||||
`DoorProp` and `AllSeeingEyeTerminal` are `PoweredProp` instances. If the robot uses `InteractProp` on an unpowered `PoweredProp`, the action is accepted as a `LengthyAction`, changes no prop state, provides no terminal view, and still triggers one `Pulse`. This makes power loss an authored puzzle consequence rather than a UI refusal. Other invalid interactions remain refused and do not trigger a `Pulse`.
|
||||
|
||||
## Pulses And Steps
|
||||
|
||||
A step is the low-level deterministic simulation iteration. One step injects leaks, resolves same-cell reactions, resolves adjacent surface flow, accumulates deltas, and clamps visible surface values.
|
||||
@@ -80,7 +83,7 @@ When `ReactorReadiness` is true, the level shows `REACTOR READY`. The player win
|
||||
The level is lost when:
|
||||
|
||||
- `Heat` reaches the terminal threshold,
|
||||
- `MoveRobot` enters an unsafe destination floor cell without applicable protection, causing `UnsafeEntryLoss`,
|
||||
- `MoveRobot` enters an `Unsafe` destination floor cell without applicable protection, causing `UnsafeEntryLoss`,
|
||||
- fixed simulation rules mark terminal failure.
|
||||
|
||||
Missing `ReactorReadiness`, including missing `ReactorControlProp` feed or missing required `ConsumerProp` production, blocks `Ready` but does not directly cause `Lost`.
|
||||
@@ -118,14 +121,14 @@ The player can always inspect:
|
||||
- surface terrain,
|
||||
- surface props and visible prop state,
|
||||
- visible leaks and repair faces,
|
||||
- visible surface hazards and sprinkler water,
|
||||
- visible surface values and `Unsafe` movement cells,
|
||||
- door state,
|
||||
- remedy inventory and supply props,
|
||||
- consumer state: disabled, starved, supplied, producing, or unknown,
|
||||
- level state,
|
||||
- `Forecast` warnings only while the robot is at an active `AllSeeingEyeTerminal`.
|
||||
- `Forecast` warnings only while the robot is at an active and powered `AllSeeingEyeTerminal`.
|
||||
|
||||
Underground topology and numeric network values are available only while the robot is at an active `AllSeeingEyeTerminal`. There is no persistent lock or unlock state in the level data.
|
||||
Underground topology and numeric network values are available only while the robot is at an active and powered `AllSeeingEyeTerminal`. There is no persistent lock or unlock state in the level data.
|
||||
|
||||
The editor always sees and authors every layer.
|
||||
|
||||
@@ -140,7 +143,7 @@ Each map coordinate contains:
|
||||
- zero or one underground coolant cell,
|
||||
- zero or one underground electricity cell,
|
||||
- zero or one surface prop,
|
||||
- visible hazard amounts on floor cells,
|
||||
- visible surface values on floor cells,
|
||||
- optionally the robot, only on a floor cell.
|
||||
|
||||
Terrain is authored and does not change during play. Wall cells are not walkable and do not store surface hazards.
|
||||
@@ -195,6 +198,7 @@ Surface prop categories:
|
||||
- door prop,
|
||||
- `AllSeeingEyeTerminal` prop,
|
||||
- remedy supply prop,
|
||||
- sprinkler control prop,
|
||||
- coolant sprinkler valve prop,
|
||||
- reactor control prop.
|
||||
|
||||
@@ -212,7 +216,7 @@ An isolation valve prop is bound to fuel, coolant, or electricity and sits on a
|
||||
|
||||
During network flow, an open isolation valve allows carrier propagation through the underground branch normally. A closed isolation valve blocks intentional network propagation across that underground cell's connected branch boundary. Closing a valve can stop pressure or voltage from reaching a damaged segment, but it can also prevent downstream `ConsumerProp` production, `CoolantSprinklerValve` discharge, or `ReactorControlProp` feed.
|
||||
|
||||
Toggling an isolation valve is a lengthy action and triggers one pulse. Inspection should make visible branch effects readable before the player commits. If the robot is at an active `AllSeeingEyeTerminal`, systemic `Forecast` output should also warn about affected underground branches, isolated leaks, and downstream service loss.
|
||||
Toggling an isolation valve is a lengthy action and triggers one pulse. Inspection should make visible branch effects readable before the player commits. If the robot is at an active and powered `AllSeeingEyeTerminal`, systemic `Forecast` output should also warn about affected underground branches, isolated leaks, and downstream service loss.
|
||||
|
||||
### Consumer Props
|
||||
|
||||
@@ -246,14 +250,27 @@ A junction prop must be on a floor cell whose coordinate has exactly one undergr
|
||||
|
||||
The engine infers incoming and outgoing branch directions from valid network topology and enabled source paths. A valid junction has one incoming branch and either two or three outgoing branches. Ambiguous junction flow is invalid. Ratio numbers are balance-defined weights that divide carrier amount and pressure or voltage. A zero-weight branch receives no intentional outflow.
|
||||
|
||||
### Powered Props
|
||||
|
||||
A `PoweredProp` requires positive local `Electricity` amount and positive voltage before its authored interaction can take effect. For the approved campaign scope, only `DoorProp` and `AllSeeingEyeTerminal` are `PoweredProp` instances.
|
||||
|
||||
When the robot uses `InteractProp` on an unpowered `PoweredProp`:
|
||||
|
||||
- the action is accepted as a `LengthyAction`,
|
||||
- the prop state does not change,
|
||||
- an unpowered `AllSeeingEyeTerminal` does not reveal underground layers or `Forecast` output,
|
||||
- one `Pulse` resolves normally.
|
||||
|
||||
The prop remains in its previous physical or active state when power is lost. This keeps power-routing consequences readable and allows levels to use wasted powered-prop interactions as deliberate risk.
|
||||
|
||||
### Doors
|
||||
|
||||
A `DoorProp` is an electric prop on one floor cell. Its orientation is derived from opposing wall cells:
|
||||
A `DoorProp` is a `PoweredProp` on one floor cell. Its orientation is derived from opposing wall cells:
|
||||
|
||||
- north and south walls mean the door sits in an east-west corridor and blocks west/east propagation while closed,
|
||||
- west and east walls mean the door sits in a north-south corridor and blocks north/south propagation while closed.
|
||||
|
||||
A `DoorProp` must have exactly one valid opposing wall pair and exactly one connected `Electricity` underground cell at its coordinate. The player can toggle a `DoorProp` only when that local `Electricity` feed has positive amount and positive voltage. If power is lost, the `DoorProp` keeps its last physical `Open` or `Closed` state.
|
||||
A `DoorProp` must have exactly one valid opposing wall pair and exactly one connected `Electricity` underground cell at its coordinate. The player can toggle a `DoorProp` only when that local `Electricity` feed has positive amount and positive voltage. If power is lost, the `DoorProp` keeps its last physical `Open` or `Closed` state. Interacting with an unpowered `DoorProp` changes nothing and triggers one `Pulse`.
|
||||
|
||||
Closed `DoorProp` instances block `LeakedFuel`, `SprinklerWater`, `LeakedElectricity`, and `Heat` propagation across the corridor cell. They do not block `MoveRobot`, underground network flow, source feeding, consumer supply, or hazards already present on either side.
|
||||
|
||||
@@ -264,25 +281,32 @@ Door blocking is evaluated by the door cell and its inferred corridor axis:
|
||||
- `Open` `DoorProp` instances do not block surface interaction,
|
||||
- `DoorProp` instances on invalid terrain, with ambiguous opposing walls, or without local `Electricity` are validation errors.
|
||||
|
||||
### Coolant Sprinkler Valves
|
||||
### Sprinkler Controls And Coolant Sprinkler Valves
|
||||
|
||||
A `SprinklerControlProp` is an interactive floor prop linked to exactly one wall-mounted `CoolantSprinklerValve`. It can be `Enabled` or `Disabled` and does not require `Electricity`.
|
||||
|
||||
Toggling a `SprinklerControlProp` is a `LengthyAction` and triggers one `Pulse`. The linked `CoolantSprinklerValve` mirrors the control state for discharge purposes. `CoolantSprinklerValve` instances are not directly interactive by the robot.
|
||||
|
||||
A `CoolantSprinklerValve` is a wall-mounted surface prop that intentionally releases `Coolant` as `SprinklerWater` onto one adjacent authored floor outlet/access face. It exists to let the player trade local fire suppression for reduced `Coolant` service.
|
||||
|
||||
Valve behavior:
|
||||
|
||||
- toggling a valve is a `LengthyAction` and triggers one `Pulse`,
|
||||
- the valve discharges only while its linked `SprinklerControlProp` is `Enabled`,
|
||||
- an `Enabled` valve adds a balance-defined amount of `SprinklerWater` to its outlet floor cell during each `Step`,
|
||||
- the valve must be authored on a wall cell with exactly one adjacent valid floor outlet/access face,
|
||||
- the valve must be connected to a present `Coolant` network cell,
|
||||
- the valve must be linked to exactly one `SprinklerControlProp`,
|
||||
- discharge creates a local `Coolant` pressure drop and can prevent nearby or downstream `ConsumerProp` production or `ReactorReadiness`,
|
||||
- disabling the valve or closing an upstream `IsolationValveProp` can restore `Coolant` pressure on later pulses,
|
||||
- disabling the linked `SprinklerControlProp` or closing an upstream `IsolationValveProp` can restore `Coolant` pressure on later pulses,
|
||||
- discharge does not repair coolant pipe damage and does not permanently disable the `Coolant` network.
|
||||
|
||||
The local pressure drop is deterministic and spatial. It should be derived from the valve's connected `Coolant` network branch so that the player can understand why nearby consumers or `ReactorReadiness` become insufficient after sprinkler discharge.
|
||||
|
||||
### Terminals And Supplies
|
||||
|
||||
An `AllSeeingEyeTerminal` allows full underground inspection and `Forecast` viewing while the robot is at an active terminal. Activating the terminal is a `LengthyAction` and triggers one `Pulse`; viewing is terminal-local and does not persist after the robot leaves.
|
||||
An `AllSeeingEyeTerminal` is a `PoweredProp` that allows full underground inspection and `Forecast` viewing while the robot is at an active and powered terminal. Activating a powered terminal is a `LengthyAction` and triggers one `Pulse`; viewing is terminal-local and does not persist after the robot leaves.
|
||||
|
||||
Interacting with an unpowered `AllSeeingEyeTerminal` changes nothing, reveals no underground layers or `Forecast` output, and still triggers one `Pulse`.
|
||||
|
||||
Remedy supply props are single-use pickups:
|
||||
|
||||
@@ -314,7 +338,7 @@ Electricity leaks:
|
||||
- can be repaired or remediated from that floor cell,
|
||||
- emit only to that stored face.
|
||||
|
||||
All leaks must have valid floor access. Repair changes the underground cell from `Leaking` to `Intact`, restores structural integrity to max, and stops future injection. Repair does not clean existing surface hazards. If the repaired segment is immediately returned to unsafe pressure or voltage, structural integrity rules may damage it again on later pulses.
|
||||
All leaks must have valid floor access. Repair changes the underground cell from `Leaking` to `Intact`, restores structural integrity to max, and stops future injection. Repair does not clean existing surface hazards. If the repaired segment is immediately returned to excessive pressure or voltage, structural integrity rules may damage it again on later pulses.
|
||||
|
||||
The robot carries remedial consumables with balance-defined inventory capacity:
|
||||
|
||||
@@ -353,7 +377,7 @@ Leaking underground cells remain part of network propagation unless isolated by
|
||||
During leak injection:
|
||||
|
||||
- fed fuel leaks add leaked fuel to the accessible floor cell,
|
||||
- fed coolant pipe failures and enabled `CoolantSprinklerValve` instances add sprinkler water to valid floor outlet/access cells,
|
||||
- fed coolant pipe failures and `CoolantSprinklerValve` instances with enabled linked `SprinklerControlProp` instances add sprinkler water to valid floor outlet/access cells,
|
||||
- fed electricity leaks add leaked electricity to the stored floor emission face,
|
||||
- active matching remedy blocks prevent matching element entry.
|
||||
|
||||
@@ -373,6 +397,20 @@ Surface interaction resolution is deterministic:
|
||||
- closed doors and remedy blocks gate the interactions they explicitly block,
|
||||
- deltas accumulate during an interaction pass and are applied together before clamping.
|
||||
|
||||
## Unsafe Movement
|
||||
|
||||
`Unsafe` is a derived movement-safety state on floor cells. It is recalculated from current surface values after authored setup and after each `Pulse`.
|
||||
|
||||
A floor cell is `Unsafe` when any of these conditions are true:
|
||||
|
||||
- `Heat` is at or above the balance-defined unsafe heat threshold,
|
||||
- `LeakedElectricity` is at or above the balance-defined unsafe electricity threshold,
|
||||
- `SprinklerWater` and `LeakedElectricity` together meet the balance-defined wet-electric unsafe rule.
|
||||
|
||||
`LeakedFuel` alone is not `Unsafe`. It is dangerous because it can `Ignite` with `Heat` or `LeakedElectricity`. `SprinklerWater` alone is not `Unsafe`.
|
||||
|
||||
`UnsafeEntryLoss` occurs only when `MoveRobot` enters an `Unsafe` destination cell without applicable protection. A `Pulse` does not cause `UnsafeEntryLoss` for a robot that remains stationary on a cell that becomes `Unsafe`; the loss happens when the player next attempts to enter an `Unsafe` destination. `HeatShield` can protect only against `Heat` entry according to its configured duration. Element neutralizers can remove their matching surface element before movement, but they do not provide general immunity.
|
||||
|
||||
## Hazard Bands And Pair Table
|
||||
|
||||
Balance thresholds project numeric values into safe, caution, and critical bands:
|
||||
@@ -464,10 +502,10 @@ Data-driven rule predicates and effects are not part of level data. Effects happ
|
||||
- structural integrity resolution weakens damaged high-pressure cells and creates leaks from low-integrity positive-pressure cells,
|
||||
- leak injection and sprinkler discharge add carrier hazards or sprinkler water to valid floor access cells,
|
||||
- surface interaction resolution spreads and reacts hazards according to the hazard pair table,
|
||||
- robot safety resolves `UnsafeEntryLoss` when `MoveRobot` enters an unsafe destination floor cell,
|
||||
- robot safety resolves `UnsafeEntryLoss` when `MoveRobot` enters an `Unsafe` destination floor cell,
|
||||
- reactor state derives readiness or terminal heat loss,
|
||||
- duration advancement reduces remedy blocks and heat immunity counters,
|
||||
- forecast refresh simulates copied state over the configured pulse horizon for active `AllSeeingEyeTerminal` viewing.
|
||||
- forecast refresh simulates copied state over the configured pulse horizon for active and powered `AllSeeingEyeTerminal` viewing.
|
||||
|
||||
Warnings are generated by fixed forecast and status systems when conditions can be proven.
|
||||
|
||||
@@ -484,7 +522,7 @@ One accepted lengthy interaction resolves one pulse in this order:
|
||||
7. Derive reactor readiness and level state.
|
||||
8. Preserve robot position; a `Pulse` does not cause `UnsafeEntryLoss` by itself.
|
||||
9. Advance remedy blocks and heat immunity once for the pulse.
|
||||
10. Refresh forecasts for active `AllSeeingEyeTerminal` viewing.
|
||||
10. Refresh forecasts for active and powered `AllSeeingEyeTerminal` viewing.
|
||||
|
||||
Each step inside the pulse resolves in this order:
|
||||
|
||||
@@ -500,7 +538,7 @@ Each step inside the pulse resolves in this order:
|
||||
|
||||
`Forecast` output is generated systemically by deterministic simulations over copied state. Forecasting does not mutate the actual level. Level data does not author bespoke forecast text.
|
||||
|
||||
`Forecast` output is visible only while the robot is at an active `AllSeeingEyeTerminal`. Away from an active terminal, the player relies on visible props, visible leaks, visible surface values, consumer state, and level state.
|
||||
`Forecast` output is visible only while the robot is at an active and powered `AllSeeingEyeTerminal`. Away from an active and powered terminal, the player relies on visible props, visible leaks, visible surface values, consumer state, and level state.
|
||||
|
||||
Forecast output includes:
|
||||
|
||||
@@ -529,6 +567,7 @@ Validation errors:
|
||||
- invalid door cell or door without local electricity,
|
||||
- invalid leak access,
|
||||
- invalid wall-mounted `CoolantSprinklerValve` outlet/access face or missing coolant network connection,
|
||||
- invalid or missing `SprinklerControlProp` link for a `CoolantSprinklerValve`,
|
||||
- isolation valve without exactly one matching underground carrier,
|
||||
- junction without exactly one underground carrier,
|
||||
- ambiguous junction flow,
|
||||
@@ -559,6 +598,7 @@ The editor authors:
|
||||
- junction props and balance-defined ratio mode index,
|
||||
- electric door props,
|
||||
- wall-mounted coolant sprinkler valves and their authored outlet/access floor cells,
|
||||
- sprinkler control props and their linked coolant sprinkler valves,
|
||||
- `AllSeeingEyeTerminal` props,
|
||||
- remedy supplies,
|
||||
- floor leaks and electricity wall leaks with authored access faces,
|
||||
@@ -581,6 +621,6 @@ The loader accepts only schema-valid level data and returns clear errors for mal
|
||||
|
||||
## Balancing And Tests
|
||||
|
||||
Balancing defines source strengths, falloff, ratio math, isolation valve branch blocking, consumer predicates, leak magnitudes, sprinkler discharge, coolant pressure drops, evaporation, wet-electricity conduction, structural integrity thresholds and damage scale, interaction magnitudes, display thresholds, unsafe-entry thresholds, terminal heat thresholds, inventory capacity, remedy duration, heat immunity duration, and forecast horizon.
|
||||
Balancing defines source strengths, falloff, ratio math, isolation valve branch blocking, consumer predicates, leak magnitudes, sprinkler discharge, coolant pressure drops, evaporation, wet-electricity conduction, structural integrity thresholds and damage scale, interaction magnitudes, display thresholds, `Unsafe` thresholds, terminal heat thresholds, inventory capacity, remedy duration, heat immunity duration, and forecast horizon.
|
||||
|
||||
Tests assert behavior against configured balance values and bands. Coverage includes validation, inferred connectivity, isolation valve branch blocking, junction effects, multi-service consumer states, reactor readiness and activation, terminal loss, unsafe entry loss, heat immunity, structural integrity degradation and leak creation, pressure-fed leak injection, leak access, wall-mounted sprinkler valves, coolant pressure drops, coolant mitigation, evaporation, wet-electricity spread, remedies, powered door toggling and blocking, terminal-local forecasts, campaign authoring rules, and serialization round trips.
|
||||
Tests assert behavior against configured balance values and bands. Coverage includes validation, inferred connectivity, isolation valve branch blocking, junction effects, multi-service consumer states, reactor readiness and activation, terminal loss, unsafe entry loss, heat immunity, structural integrity degradation and leak creation, pressure-fed leak injection, leak access, wall-mounted sprinkler valves, sprinkler control links, coolant pressure drops, coolant mitigation, evaporation, wet-electricity spread, remedies, powered door toggling and blocking, powered terminal access, unpowered `PoweredProp` no-op pulses, terminal-local forecasts, campaign authoring rules, and serialization round trips.
|
||||
|
||||
Reference in New Issue
Block a user