Clarify powered terminals and campaign hazards
This commit is contained in:
@@ -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