Files
zfxaction26_2/docs/design.md

39 KiB

Game Design: Reactor Maintenance

Core Concept

The player controls a maintenance robot inside a failing reactor facility.

The game is a deterministic, turn-based systems puzzle. The player studies a visible machine, predicts its failures, and chooses between short-term on-site stabilization and longer-term network control.

The simulation model is intentionally narrow:

  • a static surface grid made of walkable floor cells and blocked wall cells
  • an underground fuel network
  • an underground coolant network
  • an underground electricity network
  • surface props that expose controls, terminals, supplies, doors, and repair access
  • leaks that are always reachable by the robot from a floor cell
  • a reactor that must receive fuel, cooling, and electricity support before activation
  • a diagnostic UI that exposes visible state, forecasts, and all underground layers only after all-seeing-eye terminal access

Each turn has three phases:

  1. Player phase: the player spends a limited number of actions.
  2. Simulation phase: network flow, leaks, local hazards, doors, consumers, and level state are resolved deterministically.
  3. Event phase: scheduled failures, remedy durations, and scripted level events advance.

The main fantasy is:

"I understand this machine well enough to prevent the next disaster."

The game should feel:

  • logical
  • tactical
  • deterministic
  • readable
  • systemic

It should not feel:

  • hectic
  • random
  • action-heavy
  • dependent on hidden information after the correct inspection tool is acquired

Goal

The reactor starts offline.

To win a level, the player must:

  • restore fuel delivery to the required fuel consumer
  • restore coolant delivery to the required coolant consumer
  • restore electricity delivery to the required electricity consumer
  • keep the reactor area below terminal heat
  • reach the reactor control site and activate the core

When all required consumers are enabled, supplied, and producing service, and no terminal reactor condition is active, the level shows:

REACTOR READY

The player can then spend an action at the reactor control site to activate the core and win.

Loss Conditions

The player loses if the level reaches a clearly predicted terminal state.

Primary loss conditions:

  • reactor overheating reaches the terminal heat threshold
  • a scripted terminal event resolves
  • cascading hazards make the level explicitly unrecoverable according to level-authored rules

Required consumer starvation does not directly cause loss. A starved or disabled required consumer prevents Ready, but failure still comes from terminal heat, scripted loss events, or other explicit terminal rules.

Failure should not be instant unless the player knowingly allows a predicted critical state to mature.

Turn Structure

1. Player Phase

The player has a fixed number of actions per turn, defined by balancing.

Player actions are limited to:

  • move the robot
  • interact with a prop
  • interact with a leak or hazard cell
  • activate the reactor

Each player action costs one action unless balancing or a level rule explicitly says otherwise. Passive inspection of visible information is free; all underground inspection requires all-seeing-eye access.

2. Simulation Phase

The facility updates all active systems.

Examples:

  • enabled flow props inject pressure or voltage into connected underground networks
  • T-junction and cross-junction props split outflow by selected ratios
  • enabled consumers draw from their bound network and produce service if supplied
  • leaking fuel and coolant underground cells emit their carrier through a broken floor cell
  • leaking electricity wall cells emit sparks through their stored adjacent floor face
  • neighboring floor cells exchange leaked matter, charge, or heat through deterministic numeric rules
  • closed doors block surface hazard propagation across their edge
  • coolant lowers heat
  • electricity interacting with coolant or fuel raises heat

3. Event Phase

Predicted events advance by one turn.

Examples:

  • a scripted leak starts
  • an existing leak worsens
  • an elemental remediation block expires
  • robot heat immunity expires
  • a scripted level event adds heat or disables a prop

Events are not hidden. The player sees upcoming failures before they happen.

Information Design

All surface information is visible and predictable. Underground information is controlled by terminal access.

The player can always see:

  • floor and wall terrain
  • surface props and their visible states
  • visible leaks and their reachable repair faces
  • visible surface hazards on floor cells
  • door open or closed state
  • remedy inventory and supply props
  • whether each consumer is producing, starved, disabled, or unknown
  • the current global level state
  • scheduled upcoming events and warnings

Before all-seeing-eye access, the player cannot freely inspect underground layers. Underground causes may be inferred from visible leaks, prop state, and forecasts, but exact underground topology and numeric network values are hidden.

After interacting with an all-seeing-eye terminal prop, the player can inspect all underground layers:

  • underground fuel, coolant, and electricity topology
  • structural state of each underground network cell
  • carrier amount
  • pressure for fuel and coolant
  • voltage for electricity
  • junction split modes and downstream effects
  • source-to-consumer connectivity

Safe, caution, and critical labels are UI and forecast labels only. They are derived from balance constants and are not authoritative simulation state. Exact numeric values and balance predicates drive simulation.

The question is not:

"What is behind the corner?"

It is:

"Do I spend scarce local resources now, or commit actions to fix the system that caused this?"

Simulation Model

Layered Grid

Each map coordinate contains:

  • one static surface terrain cell: Floor or Wall
  • zero or one fuel network cell underground
  • zero or one coolant network cell underground
  • zero or one electricity network cell underground
  • zero or one surface prop
  • zero or more visible hazard amounts on floor cells
  • optionally the robot, only on floor cells

Cells cannot change between floor and wall during play. Terrain is level-authored and static.

The three underground networks are disjunct. They do not share edges and do not directly interact underground.

Each network has:

  • its own outside-of-level source connection
  • one flow prop type on the surface
  • one consumer prop type on the surface
  • optional T-junction props on surface floor cells
  • optional cross-junction props on surface floor cells

The surface prop is an abstract vertical control or access point. Junction props are the only way to regulate network flow after it leaves a source. Consumers can be toggled, but consumer toggles do not alter network outflow ratios.

Network Semantics

The three network families are intentionally symmetric in structure but differ by carrier behavior.

  • Fuel: liquid carrier, uses pressure, required by the fuel consumer, dangerous when leaked near electricity or high heat.
  • Coolant: liquid carrier, uses pressure, required by the coolant consumer, lowers heat, dangerous when leaked near electricity.
  • Electricity: electrical carrier, uses voltage, required by the electricity consumer, dangerous when leaked near coolant or fuel.

Each underground network cell has one structural state:

  • Absent
  • Intact
  • Leaking

Each underground network cell stores exact numeric values:

  • local carrier amount
  • local pressure for fuel and coolant
  • local voltage for electricity

Each floor cell stores exact numeric values:

  • leaked fuel amount
  • leaked coolant amount
  • leaked electricity amount
  • heat amount
  • active elemental remediation blocks

The robot stores:

  • current floor position
  • carried remedial consumables
  • active heat-immunity duration

All numeric values use balance-defined minimum and maximum clamps. The design intentionally does not fix numeric thresholds in this document. Balancing defines source strength, consumer requirements, leak rates, display bands, terminal thresholds, event magnitudes, inventory capacity, remedy block duration, and heat immunity duration.

Why This Formalization

This model keeps the simulation small enough to forecast while still creating tactical decisions:

  • terrain is static and readable
  • network topology is stored underground
  • pressure and voltage determine whether consumers are satisfied and how severe leaks are
  • junction ratios are explicit and player-controlled
  • leaks project hazards onto reachable floor cells
  • doors provide local surface containment
  • remedies provide scarce local stabilization
  • global level state is derived after deterministic local interactions

State Inventory

Cell State

Surface terrain states:

  • Floor: walkable, can hold the robot, props, visible hazards, fuel/coolant leaks, and repair access to electricity wall leaks.
  • Wall: not walkable, can hold wall-routed underground cells and electricity wall leaks.

Terrain is static. There are no runtime events that create or clear floor/wall terrain.

Surface hazard values on floor cells:

  • Fuel
  • Coolant
  • Electricity
  • Heat

Underground network state, repeated for fuel, coolant, and electricity:

  • Absent
  • Intact
  • Leaking
  • local carrier amount
  • local pressure for fuel and coolant
  • local voltage for electricity

Notes:

  • Absent / Intact / Leaking describe the underground cell itself.
  • Numeric values describe the current simulation state.
  • Safe/caution/critical labels are derived from numeric values for UI and forecasts only.
  • A fuel or coolant leak injects into its own floor cell.
  • An electricity wall leak injects into its stored adjacent floor emission face.

Leak State

Each leak stores:

  • carrier type
  • underground coordinate
  • accessible floor coordinate
  • current repair state

Fuel and coolant leak rules:

  • may only occur when the underground leak coordinate is under a Floor cell
  • are visualized as broken floor revealing a burst underground pipe
  • use the same coordinate as their accessible floor coordinate
  • can be repaired or remediated by the robot standing on that floor cell

Electricity leak rules:

  • may only occur when the underground leak coordinate is in a Wall cell
  • must store exactly one adjacent Floor cell as its accessible emission face
  • are visualized as cables hanging out of the wall and emitting sparks into the chosen floor cell
  • can be repaired or remediated by the robot from the chosen floor cell
  • do not emit to other adjacent floor cells

All leaks introduce hazards to the robot through their visible floor cell. Every authored or scripted leak must have at least one accessible floor cell so the player can choose an on-site response.

Prop State

Surface prop categories:

  • flow prop
  • consumer prop
  • T-junction prop
  • cross-junction prop
  • door prop
  • all-seeing-eye terminal prop
  • remedy supply prop
  • reactor control prop

Flow and consumer props have two states:

  • Enabled
  • Disabled

T-junction props split one incoming network path into two outgoing branches. Their allowed modes are:

  • 0/4
  • 1/3
  • 2/2
  • 3/1
  • 4/0

Cross-junction props split one incoming network path into three outgoing branches. Their allowed modes are:

  • 0/3/3
  • 3/0/3
  • 3/3/0
  • 2/2/2

The ratio numbers are weights, not fixed values. They divide available carrier amount plus pressure or voltage according to balance-defined ratio math. A zero-weight branch receives no intentional outflow from that junction.

Door props have two states:

  • Open
  • Closed

Closed doors block surface leak and heat propagation across their door edge. Closed doors do not block underground network flow.

All-seeing-eye terminal props have two player states:

  • Locked: underground layer inspection is unavailable.
  • Unlocked: interacting with the terminal has enabled all underground layer inspection for the level.

Remedy supply props are single-use typed pickups:

  • FuelRemedySupply
  • CoolantRemedySupply
  • ElectricityRemedySupply
  • HeatRemedySupply

Each supply prop provides one fixed remedy type once. After pickup it becomes depleted.

Consumer State

Each consumer derives one current service state:

  • Disabled: the prop is off, consumes nothing, produces no service, and does not starve.
  • Supplied: the prop is enabled and receives enough carrier amount plus pressure or voltage.
  • Starved: the prop is enabled but receives too little carrier amount, pressure, or voltage.
  • Producing: the prop is supplied this simulation step and its required service is active.

Supplied is the input condition. Producing is the output condition used by readiness.

Required consumer mapping:

  • Fuel consumer: required for reactor fuel path.
  • Coolant consumer: required for reactor cooling path.
  • Electricity consumer: required for reactor activation path.

Remedy State

The robot has a small inventory for remedial consumables. Inventory capacity is balance data.

Remedy types:

  • FuelNeutralizer
  • CoolantNeutralizer
  • ElectricityNeutralizer
  • HeatShield

Element neutralizers:

  • are consumed when applied to a target floor cell or reachable leak face
  • remove the current matching surface element from that target
  • apply a temporary block preventing that same element from re-entering the target for a balance-defined duration
  • do not remove or block any other element
  • do not reduce heat
  • do not repair the underlying leak

Heat shield:

  • is consumed when activated by the robot
  • makes the robot immune to heat damage for a balance-defined number of robot steps
  • does not reduce heat
  • does not block heat propagation
  • does not protect against fuel, coolant, or electricity hazards

Mixed hazards require multiple remedies. For example, a floor cell containing fuel, electricity, and heat requires a fuel neutralizer, an electricity neutralizer, and heat immunity or another heat-management solution to make the robot locally safe.

Level State

The whole level has five states:

  • Stable
  • Caution
  • Critical
  • Ready
  • Lost

Meaning:

  • Stable: no terminal path is active and no urgent predicted intervention is required.
  • Caution: one or more required services are unavailable, a hazard is growing, or reactor heat is concerning but not terminal.
  • Critical: the simulation predicts a loss without near-term intervention.
  • Ready: all reactor activation prerequisites are met.
  • Lost: terminal failure has already occurred.

Level state is derived. It is not diffused spatially.

Robot State

The robot has four states:

  • Ready
  • Interacting
  • Blocked
  • Damaged

Meaning:

  • Ready: free to move and act.
  • Interacting: currently spending an action on a prop, leak, hazard, or reactor activation.
  • Blocked: the target move or action was refused because the destination or target is invalid.
  • Damaged: the robot entered or remained in an unresolved hazardous cell without applicable protection.

Flow Mechanic

Sources

An enabled flow prop is the source for its bound network.

During the network flow step:

  • FeedFromOutside[Fuel] injects fuel amount and fuel pressure.
  • FeedFromOutside[Coolant] injects coolant amount and coolant pressure.
  • FeedFromOutside[Electricity] injects electricity amount and voltage.

The injected source amount and source pressure or voltage are balance constants. A disabled flow prop injects nothing and isolates its bound source cell from outside supply.

Propagation

Carrier amount, pressure, and voltage propagate through connected intact and leaking underground cells using deterministic distance falloff and junction ratios.

For each carrier network:

  • start from every enabled flow prop connected to that carrier
  • walk through connected Intact and Leaking cells of that carrier
  • stop at Absent cells and disconnected network topology
  • assign each reached cell the best available incoming carrier amount plus pressure or voltage
  • subtract balance-defined amount falloff and pressure or voltage falloff for each network step
  • divide outflow at T-junction and cross-junction props using the selected ratio mode
  • clamp final values to the balance-defined numeric range

If multiple sources or paths reach the same cell, the cell uses the best resulting carrier amount and the best resulting pressure or voltage. This keeps routing predictable and prevents order-dependent results.

Junctions

Junction props are the only flow regulation mechanism.

A junction prop must be placed on a floor cell and is controlled by the robot through InteractProp. Its underground network cell defines the carrier it regulates.

T-junction behavior:

  • one incoming branch is split into two authored outgoing branches
  • selected mode chooses the outflow ratio between those branches
  • 0/4 sends all intentional outflow to branch B
  • 4/0 sends all intentional outflow to branch A
  • intermediate modes split by weight

Cross-junction behavior:

  • one incoming branch is split into three authored outgoing branches
  • selected mode chooses the outflow ratio between those branches
  • 0/3/3, 3/0/3, and 3/3/0 shut off one outgoing branch while splitting between the other two
  • 2/2/2 balances outflow across all three branches

Ratio math is balance data. The intended design is readable branch commitment, not fine-grained numeric optimization.

Strategic uses:

  • route pressure away from a leaking branch
  • feed a required consumer at the cost of starving another branch
  • reduce voltage near a sparking wall leak without disabling the source
  • create a longer-term fix that costs more commitment than spending a consumable

Consumers

An enabled consumer evaluates after network propagation.

The consumer is supplied if all required balance predicates pass:

  • enough carrier amount reaches the bound underground cell
  • enough pressure reaches a fuel or coolant consumer
  • enough voltage reaches an electricity consumer
  • the bound network path is not disconnected by topology or junction ratios

If supplied, the consumer emits ConsumeFromNetwork[n], removes or reserves the balance-defined demand amount, and produces its required service for this turn.

If enabled but not supplied, the consumer emits StarveConsumer[n]. Starvation blocks readiness and contributes to Caution or forecast warnings, but it does not directly cause loss.

If disabled, the consumer consumes nothing, produces nothing, does not starve, and cannot satisfy readiness. Disabling a consumer is still useful as demand management, but it is not a flow-ratio control.

Leaks And Flow Values

Pressure and voltage make leaks strategically meaningful.

A leaking underground cell:

  • remains part of network propagation while leaking
  • emits its carrier into the accessible floor cell during InjectLeak[n]
  • uses balance-defined leak predicates that can depend on carrier amount, pressure, or voltage
  • may inject more severe hazards when pressure or voltage is high

Repairing a leak changes the underground cell from Leaking to Intact and stops future injection. It does not clean existing leaked surface fuel, coolant, electricity, or heat.

Applying a matching elemental remedy does not repair the leak. It removes the matching visible hazard on the target and temporarily blocks re-entry of that same element, buying time for repair or flow regulation.

Doors And Surface Containment

Doors are surface props that control local hazard spread.

A door has an authored propagation edge between two floor cells. When open, surface fuel, coolant, electricity, and heat may propagate across that edge according to normal rules. When closed, those surface hazards do not propagate across that edge.

Closed doors do not:

  • block robot movement
  • block underground network flow
  • block source feeding
  • block consumer supply
  • extinguish hazards already present on either side

Door use is a short-term containment tool. It can isolate a hazardous area while the player fetches remedies, repairs a leak, or changes junction ratios.

Remediation Loop

Every leak creates robot-facing hazard pressure. The player should always have two broad alternatives:

  • short-term localized stability by spending a consumable or heat immunity
  • long-term stability by repairing the leak, changing junction ratios, toggling consumers, or restoring required flow

Remediation is intentionally element-specific.

Examples:

  • A fuel spill can be neutralized with FuelNeutralizer, but any electricity already mixed into the cell remains.
  • An electrified coolant puddle needs both CoolantNeutralizer and ElectricityNeutralizer to fully clear the elemental hazard.
  • A hot leak zone can be crossed with HeatShield, but the heat remains dangerous after immunity expires.
  • A closed door can keep a neutralized corridor safe longer by preventing new spread from adjacent cells.

Consumables are scarce by map design. Each supply prop grants one typed item once, so spending a remedy is a commitment.

Events That Modify State

[n] means one of the three carriers: fuel, coolant, or electricity.

Player Actions

  • MoveRobot: spends one action to move the robot to an adjacent floor cell. Invalid destinations emit BlockRobot.
  • InteractProp: spends one action on the prop in the robot's current floor cell.
  • InteractLeak: spends one action to repair a leak reachable from the robot's current floor cell, apply a matching carried elemental remedy to the robot's current floor cell, or activate a carried heat shield while the robot occupies a hazardous floor cell.
  • ActivateReactor: spends one action at the reactor control site. It wins only if the level is Ready; otherwise it reports that the reactor is not ready.

InteractProp covers:

  • enabling or disabling flow props
  • enabling or disabling consumer props
  • cycling or selecting T-junction ratio modes
  • cycling or selecting cross-junction ratio modes
  • opening or closing doors
  • unlocking all-seeing-eye terminal access
  • picking up a remedy from a supply prop

InteractLeak covers:

  • repairing the underlying leak
  • applying FuelNeutralizer
  • applying CoolantNeutralizer
  • applying ElectricityNeutralizer

HeatShield is activated through InteractLeak while targeting a hazardous floor cell. It consumes one action and affects the robot rather than the map cell.

Cell And Network Events

  • StartLeak[n]: changes an underground network cell from Intact to Leaking if the leak placement rules are satisfied.
  • RejectInvalidLeak[n]: refuses or reports an authored/scripted leak that has no valid floor repair access.
  • RepairLeak[n]: changes an underground network cell from Leaking to Intact. Existing surface hazards remain.
  • FeedFromOutside[n]: writes source carrier amount and pressure or voltage into the connected network according to propagation rules.
  • RouteThroughTJunction[n]: divides outflow between two authored branches using the selected T-junction ratio.
  • RouteThroughCrossJunction[n]: divides outflow between three authored branches using the selected cross-junction ratio.
  • Equalize[n]: moves a balance-defined amount of the same leaked surface carrier from a higher-value floor cell to a lower-value adjacent floor cell unless a closed door blocks that edge.
  • InjectLeak[n]: adds a balance-defined leaked carrier amount from a leaking underground cell into its accessible floor cell. The amount may depend on local carrier amount, pressure, or voltage.
  • HeatTransfer: moves a balance-defined heat amount from a hotter floor cell to a cooler adjacent floor cell unless a closed door blocks that edge.
  • HeatUp[1]: increases local heat by a small balance-defined amount.
  • HeatUp[2]: increases local heat by a larger balance-defined amount.
  • CoolDown[1]: decreases local heat by a small balance-defined amount.
  • CoolDown[2]: decreases local heat by a larger balance-defined amount.
  • Short[1]: resolves electricity and coolant interaction by raising heat, reducing leaked electricity, and optionally reducing leaked coolant by balance-defined amounts.
  • Short[2]: stronger short event with larger balance-defined heat and discharge effects.
  • Ignite[1]: resolves fuel with electricity or fuel with high heat by raising heat and consuming or transforming leaked fuel by balance-defined amounts.
  • Ignite[2]: stronger ignition event with larger balance-defined heat and fuel effects.
  • ClampValues: clamps all carrier, pressure, voltage, leaked surface, and heat values to balance-defined ranges.

Prop And Remedy Events

  • EnableFlow[n]: changes a flow prop from Disabled to Enabled.
  • DisableFlow[n]: changes a flow prop from Enabled to Disabled.
  • EnableConsumer[n]: changes a consumer prop from Disabled to Enabled.
  • DisableConsumer[n]: changes a consumer prop from Enabled to Disabled.
  • SetTJunctionRatio[n]: sets a T-junction to one of 0/4, 1/3, 2/2, 3/1, or 4/0.
  • SetCrossJunctionRatio[n]: sets a cross-junction to one of 0/3/3, 3/0/3, 3/3/0, or 2/2/2.
  • OpenDoor: changes a door from Closed to Open.
  • CloseDoor: changes a door from Open to Closed.
  • UnlockAllSeeingEye: enables underground layer inspection for the level.
  • PickUpRemedy: consumes a typed supply prop and adds its remedy to robot inventory if capacity allows.
  • ApplyElementRemedy[n]: consumes a matching carried remedy, removes that surface element from the target floor cell, and applies a temporary same-element re-entry block.
  • ApplyHeatImmunity: consumes a heat shield and gives the robot heat immunity for a balance-defined number of steps.
  • ExpireRemedyBlock[n]: removes an active same-element re-entry block from a floor cell.
  • ExpireHeatImmunity: removes robot heat immunity when its step duration reaches zero.
  • ConsumeFromNetwork[n]: an enabled and supplied consumer removes or reserves demand and emits service for the turn.
  • StarveConsumer[n]: an enabled but unsupplied consumer emits a visible warning and blocks readiness. It does not directly emit LoseLevel.

Level Events

  • EscalateLevel: derives a worse non-terminal state when required service is missing, heat is rising, a terminal forecast is near, or a scripted level condition says the situation is deteriorating.
  • RecoverLevel: derives a better non-terminal state when required services are restored and terminal forecasts are no longer near.
  • MarkReady: changes the derived level state to Ready when all required consumers are producing service and the reactor area is below terminal conditions.
  • ClearReady: changes Ready back to Stable, Caution, or Critical when any readiness prerequisite is lost before activation.
  • LoseLevel: changes the level to Lost when terminal heat, scripted terminal failure, or explicit unrecoverable conditions fire.
  • ActivateCore: changes the level to the win state after ActivateReactor succeeds while the level is Ready.

Robot Events

  • StartInteraction: changes Ready to Interacting for the duration of an action.
  • FinishInteraction: changes Interacting to Ready after the action resolves.
  • BlockRobot: changes Ready to Blocked for the attempted move or action, then returns to Ready once the refusal is reported.
  • DamageRobot: changes Ready or Blocked to Damaged when the robot occupies a cell whose final hazard values exceed robot safety predicates and no carried or active protection applies.
  • RecoverRobot: changes Damaged or Blocked to Ready when recovery rules are satisfied.
  • AdvanceHeatImmunityStep: decrements robot heat immunity when the robot spends a movement step.

Condition Table

The table is a design summary for pair interactions. It is not the authoritative simulation algorithm.

Authoritative logic is defined by numeric predicates and balance constants. The UI may label values as safe, caution, or critical, and those labels may be used to explain forecasts, but implementation must evaluate the underlying numeric values.

Projection For Readability

Projected labels:

  • FuelSafe
  • FuelCaution
  • FuelCritical
  • CoolantSafe
  • CoolantCaution
  • CoolantCritical
  • ElectricitySafe
  • ElectricityCaution
  • ElectricityCritical
  • HeatSafe
  • HeatCaution
  • HeatCritical

Projection rules:

  • labels are derived from balance-defined UI thresholds
  • labels do not change stored simulation values
  • wall cells do not participate as surface hazard cells
  • closed doors block surface neighbor interaction across their authored edge
  • leaks first emit their carrier into their accessible floor cell through InjectLeak[n]
  • active elemental remedy blocks prevent the matching element from entering the protected floor cell
  • flow props, junctions, and consumers act before the local surface interaction pass
  • level state is derived after local interactions
  • robot state is resolved after local interactions, using final local hazard values and active heat immunity

Simulation Order

The simulation loop for one turn is:

  1. Resolve player actions.
  2. Apply scheduled start-of-turn events that explicitly occur before flow.
  3. Apply FeedFromOutside[n] for every enabled flow prop.
  4. Propagate carrier amount plus pressure or voltage through each underground network using distance falloff and junction ratios.
  5. Apply ConsumeFromNetwork[n] or StarveConsumer[n] for every enabled consumer.
  6. Apply InjectLeak[n] for every leaking underground cell, respecting active matching remedy blocks.
  7. For every floor cell, evaluate local numeric predicates between leaked surface values and heat.
  8. For every floor cell, evaluate numeric predicates against right and bottom floor neighbors when no closed door blocks the edge.
  9. Emit the corresponding interaction events from the condition table summary.
  10. Apply all emitted deltas in a deterministic order.
  11. Clamp all values with ClampValues.
  12. Update robot state from the final floor cell it occupies and any active heat immunity.
  13. Derive level state from required services, reactor prerequisites, forecasts, and terminal conditions.
  14. Advance scheduled turn events, remedy block durations, and heat immunity duration.

If multiple events modify the same value in one step, their deltas are accumulated before clamping unless a specific event states that it consumes, reserves, or blocks a value earlier in the order.

Pair Event Legend

The symmetric condition table uses the following event names:

  • Hold: no direct change.
  • FuelFlow: apply Equalize[Fuel].
  • CoolFlow: apply Equalize[Coolant].
  • ChargeFlow: apply Equalize[Electricity].
  • HeatFlow: apply HeatTransfer with normal magnitude.
  • HeatFlow2: apply HeatTransfer with stronger magnitude.
  • Warm1: apply HeatUp[1] to the fuel-owning side.
  • Warm2: apply HeatUp[2] to the fuel-owning side.
  • Quench1: apply CoolDown[1] to the heat-owning side.
  • Quench2: apply CoolDown[2] to the heat-owning side.
  • Short1: apply Short[1].
  • Short2: apply Short[2].
  • Ignite1: apply Ignite[1].
  • Ignite2: apply Ignite[2].

Design intent:

  • fuel only becomes dangerous through electricity or heat
  • coolant only becomes dangerous through electricity
  • coolant opposes heat
  • heat equalizes between neighboring floor cells
  • same-carrier leaked surface amounts equalize between neighboring floor cells
  • doors and active remedy blocks are local gates on these interactions

Symmetric Pair Condition Table

Rows and columns are identical projected UI labels. Only the upper-right triangle is filled. The lower-left triangle is intentionally empty because the table is symmetric.

Row\Col FuelSafe FuelCaution FuelCritical CoolantSafe CoolantCaution CoolantCritical ElectricitySafe ElectricityCaution ElectricityCritical HeatSafe HeatCaution HeatCritical
FuelSafe Hold FuelFlow FuelFlow Hold Hold Hold Hold Warm1 Warm2 Hold Warm1 Warm2
FuelCaution Hold FuelFlow Hold Hold Hold Warm1 Ignite1 Ignite2 Warm1 Ignite1 Ignite2
FuelCritical Hold Hold Hold Hold Warm2 Ignite2 Ignite2 Warm2 Ignite2 Ignite2
CoolantSafe Hold CoolFlow CoolFlow Hold Short1 Short2 Hold Quench1 Quench1
CoolantCaution Hold CoolFlow Short1 Short1 Short2 Hold Quench1 Quench2
CoolantCritical Hold Short2 Short2 Short2 Hold Quench2 Quench2
ElectricitySafe Hold ChargeFlow ChargeFlow Hold Hold Hold
ElectricityCaution Hold ChargeFlow Hold Hold Hold
ElectricityCritical Hold Hold Hold Hold
HeatSafe Hold HeatFlow HeatFlow2
HeatCaution Hold HeatFlow
HeatCritical Hold

Prop Rules

Props do not appear as participants in the pair condition table. They are controls, access points, or resources on floor cells.

Flow prop rule:

  • if enabled, the prop allows FeedFromOutside[n]
  • if disabled, its bound source does not inject supply

Junction prop rule:

  • T-junctions regulate two outgoing branch ratios
  • cross-junctions regulate three outgoing branch ratios
  • junctions are the only flow regulation controls
  • ratio math is balance data

Consumer prop rule:

  • if enabled and supplied, it consumes demand and produces service
  • if enabled and unsupplied, it triggers StarveConsumer[n]
  • if disabled, it neither consumes, produces, nor starves
  • a disabled required consumer blocks readiness
  • consumer toggling changes demand but does not alter junction outflow ratios

Door prop rule:

  • if open, surface hazards propagate normally
  • if closed, surface hazards and heat do not cross the door edge
  • closed doors do not block underground flow

Terminal prop rule:

  • interacting with the all-seeing-eye terminal unlocks underground inspection for the level
  • no other action or prop grants full underground inspection

Remedy supply prop rule:

  • interacting with a supply prop adds its fixed remedy type to inventory if capacity allows
  • the prop is depleted after one successful pickup

Robot Rules

The robot is intentionally simple.

  • The robot moves only on floor cells.
  • The robot cannot occupy wall cells.
  • The robot can interact with the prop on its current floor cell.
  • The robot can interact with fuel and coolant leaks from their broken floor cell.
  • The robot can interact with electricity wall leaks while standing on their stored floor emission face.
  • A move into a wall or forbidden cell changes the robot to Blocked.
  • A move into or continued presence in a cell whose final hazard values exceed robot safety predicates changes the robot to Damaged unless active protection applies.
  • Heat immunity prevents heat-caused robot damage while active, but it does not remove heat.
  • Elemental remedies are inventory items and must be applied intentionally.
  • Interacting with a prop, leak, hazard, or reactor changes the robot to Interacting until the action resolves.
  • Robot safety predicates are balance data. The design does not require them to match UI band thresholds exactly.

Level Rules

Level state is derived after each simulation step.

Derivation:

  • Stable: no terminal forecast is near, reactor heat is controlled, and the facility is not actively degrading.
  • Caution: at least one required service is missing, a required consumer is starved or disabled, a hazard is growing, or reactor-adjacent heat is concerning.
  • Critical: forecasts predict terminal loss without near-term intervention, or reactor heat is close to terminal.
  • Ready: all required consumers are producing service and the reactor area is below terminal conditions.
  • Lost: a scripted terminal rule, terminal reactor heat condition, or explicit unrecoverable state fires.

Ready is reversible before activation. If a required consumer is disabled, starved, disconnected, or no longer producing service, ClearReady derives the appropriate non-ready state.

Strategic Interactions

The flow and remediation mechanics should create tactical decisions without hidden randomness.

Examples:

  • A fuel leak on a high-pressure branch can be stabilized locally with a fuel neutralizer, but the leak will remain a problem unless repaired or routed away from.
  • A coolant spill mixed with electricity requires multiple element-specific remedies, or the player can close a door and change junction ratios before entering.
  • A heat-shielded robot can cross a hot corridor for a limited number of steps, but the heat remains a continuing forecast problem.
  • A wall electricity leak can be made less dangerous by routing voltage away through a junction, or by spending an electricity neutralizer at the spark face.
  • Closing a door can protect a repaired corridor from renewed hazard spread while the player commits actions elsewhere.
  • Disabling a consumer can stop demand while the player repairs or reroutes, but it also prevents the level from becoming Ready.

Design Pillars

Deterministic Systems

The same actions in the same state always produce the same result.

Visible Consequences

The player sees exact local values, UI labels, global state, forecasted consequences, and underground state after all-seeing-eye access.

Meaningful Tradeoffs

Spending a remedy provides immediate local stability once. Adjusting junctions, repairing leaks, and restoring flow provide longer-term stability but require more commitment.

Small Formal Core

The simulation should be explainable as:

  • static floor/wall terrain
  • underground network topology
  • numeric pressure and voltage flow
  • ratio-based junction routing
  • reachable leak emission
  • surface hazards gated by doors and remedies
  • derived global level state

Extensible Later

The current code and earlier design are treated as a prototype. This reduced model is the new formal core. More mechanics can be added later only if they preserve deterministic readability and forecastability.

Remaining Design Gaps

No implementation-blocking design gaps are intentionally left open.

The following values are deliberately assigned to balancing rather than fixed in this document:

  • source strengths
  • pressure and voltage falloff
  • ratio-to-flow math
  • consumer demand predicates
  • leak injection magnitudes
  • local interaction magnitudes
  • UI safe/caution/critical thresholds
  • robot safety thresholds
  • terminal heat thresholds
  • inventory capacity
  • remedy block duration
  • heat immunity duration
  • action costs beyond the default one-action rule

Implementation should expose these as balance data and tests should assert behavior against configured constants rather than hardcoded design numbers.

Summary

The design reduces the simulation to a small layered system:

  • static floor and wall cells
  • three disjunct underground networks
  • exact numeric carrier, pressure, voltage, leak, and heat values
  • flow, consumer, junction, door, terminal, and remedy props
  • reachable leak rules for floor pipe bursts and wall cable sparks
  • UI bands as labels rather than simulation truth
  • one deterministic condition table summary backed by numeric predicates
  • one derived global level state

That gives a solid basis for a deterministic simulation that can be visualized, forecast, balanced, and extended without reintroducing hidden complexity.