zfxaction26_2/design.md

# Game Design: Reactor Maintenance

## Core Concept

The player controls a maintenance robot inside a collapsing industrial reactor facility.

The game is a deterministic, turn-based systems puzzle about stabilizing interconnected machinery under pressure. The player does not fight enemies and does not react to hidden surprises. Instead, they study a visible machine, predict its failures, and choose which systems to save, reroute, isolate, or sacrifice.

The facility is made of:

- pipes
- pressure systems
- generators
- locks and bulkhead doors
- machines
- diagnostics systems
- reactor support systems

Each turn has three phases:

1. Player phase: the player spends a limited number of actions.
2. Simulation phase: the facility updates all mechanical systems.
3. Event phase: scheduled failures or generated hurdles advance.

The main fantasy is:

> "I understand this broken 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

## Goal

The reactor starts offline.

To win a level, the player must bring a required set of main systems online, then activate the reactor core.

Example required systems:

- cooling online
- pressure stable
- main power active

When all required systems are ready, the game shows:

> REACTOR READY

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

## Loss Conditions

The player loses if a global failure state reaches zero or a hard safety limit is exceeded.

Possible loss conditions:

- core meltdown
- pressure overflow
- total power failure
- facility stability collapse

Important: failure should not be instant unless the player allows a clearly predicted critical event to happen. Most losses happen through slowly degrading global values, giving the player time to react.

## Turn Structure

### 1. Player Phase

The player has a fixed number of actions per turn, usually 3.

Possible actions:

- move
- repair pipe
- remove pipe
- rotate valve
- lock or unlock bulkhead door
- toggle breaker
- connect cable
- activate system
- inspect diagnostic terminal

### 2. Simulation Phase

The facility updates all active systems.

Examples:

- pressure flows through connected pipes
- leaks reduce cooling or pressure efficiency
- generators produce power and consume fuel
- machines consume power
- cooling reduces heat
- fire or overheating spreads through connected sectors
- unstable pipes advance toward failure

### 3. Event Phase

Predicted events advance by one turn.

Examples:

- a leak gets worse
- a short circuit disables a cable
- an unstable pipe breaks
- a door jams
- a machine overheats
- a pressure spike enters a sector

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

## Information Design

All relevant information is visible and predictable.

The player can see:

- current pressure values
- current power flow
- current cooling flow
- global stability values
- unstable pipes
- active leaks
- locked and unlocked doors
- scheduled upcoming failures
- predicted sector consequences

The game is not about asking:

> "What is behind the corner?"

It is about asking:

> "What happens if I let this system run for two more turns?"

## The Diagnostic Eye

The "eye" theme is represented by industrial diagnostic systems.

These can be:

- mechanical observation lenses
- wall-mounted diagnostic terminals
- reactor monitoring cameras
- pressure prediction displays

The eye is not an enemy and not a stealth mechanic. It is the factory's analysis interface.

Example diagnostic output:

> PRESSURE FAILURE PREDICTED IN SECTOR C IN 2 TURNS

## Core Gameplay Systems

### Pipes

Pipes transport pressure, coolant, or fuel.

Pipes can be:

- intact
- leaking
- unstable
- broken
- removed

Player interactions:

- repair a pipe
- remove a pipe
- route pressure through a different pipe network

### Valves

Valves control flow direction through pipe networks.

Player interactions:

- rotate valve
- open valve
- close valve

Valves create tradeoffs. Rerouting pressure away from the reactor may stabilize the core but overload another sector.

### Power

Generators produce power. Machines consume power.

Power flows through cables, breakers, and connected sectors.

Player interactions:

- toggle breaker
- connect cable
- activate generator
- deactivate nonessential machine

### Bulkhead Doors

Bulkhead doors isolate sectors.

Player interactions:

- lock door
- unlock door

Locking a door can contain a disaster, but anything behind the door may become inaccessible.

### Machines

Machines provide level-critical functions.

Examples:

- cooling pump
- pressure regulator
- backup generator
- reactor control terminal
- diagnostic terminal

Machines may need power, coolant, pressure, or a stable sector to function.

## System Interaction Model

The facility is modeled as a graph.

- sectors are rooms or compact areas
- pipes, cables, doors, and vents are edges between sectors
- machines occupy sectors
- hazards occupy sectors or edges
- flow networks are computed from currently connected edges

Each sector tracks a small set of readable values:

| Value | Range | Meaning |
| ----- | ----- | ------- |
| Heat | 0-10 | Local temperature and fire risk |
| Smoke | 0-10 | Visibility and movement penalty |
| Fuel Vapor | 0-10 | Flammable gas concentration |
| Coolant Pooling | 0-10 | Liquid coolant on the floor |
| Electrical Charge | 0-10 | Exposed live current or arcing risk |
| Stability | 0-10 | Structural and machinery integrity |

Each pipe edge tracks:

| Value | Range | Meaning |
| ----- | ----- | ------- |
| Medium | enum | pressure, coolant, or fuel |
| Flow | 0-10 | Amount moving through the pipe this turn |
| Pressure | 0-10 | Stress on the pipe |
| Integrity | 0-10 | Damage before breaking |
| Leak Rate | 0-10 | Amount lost into the sector each turn |

The player never needs to inspect hidden formulas. The interface presents the result as direct predictions:

- `FUEL VAPOR IGNITION IN 2 TURNS`
- `COOLANT SHORT WILL DISABLE BREAKER NEXT TURN`
- `SMOKE WILL COST +1 MOVE IN SECTOR D`
- `PUMP CAVITATION: COOLING OUTPUT -2`

### Flow Resolution

During the simulation phase, each active network resolves in this order:

1. Power networks energize machines, doors, breakers, and exposed cables.
2. Fuel networks feed generators and leak into sectors.
3. Pressure networks move stress through pipes and regulators.
4. Coolant networks remove heat, pool through leaks, and feed pumps.
5. Sector hazards update: heat, vapor, smoke, fire, charge, and stability.
6. Machines update their output based on the final local conditions.

This order makes cause and effect predictable. For example, a generator consumes fuel before it produces heat, then coolant removes some of that heat, then remaining heat may ignite vapor.

### Fuel Leakage

Fuel leaks are dangerous because fuel has two forms:

- liquid fuel spilled in a sector
- fuel vapor produced by heat, pressure spray, or accumulated spills

Fuel leakage affects the facility in four ways:

- lost fuel reduces generator runtime
- fuel vapor creates ignition risk
- liquid fuel slows movement
- fire consumes fuel and spreads heat

Simulation:

- A leaking fuel pipe adds `Leak Rate` fuel to the sector each turn.
- If sector heat is 4 or higher, some spilled fuel becomes vapor.
- If pipe pressure is 7 or higher, leaked fuel sprays and becomes vapor faster.
- Vapor decays slowly through ventilation or open doors.
- Liquid fuel remains until drained, burned, sealed, or cleaned by a maintenance action.

Player-solvable responses:

- repair the fuel pipe
- close an upstream fuel valve
- reroute fuel through another pipe
- depressurize the line before repairing it
- ventilate the sector to reduce vapor
- lock bulkheads to contain vapor
- shut down ignition sources before entering or restarting machinery

### Coolant Leakage

Coolant leaks are less explosive than fuel leaks but can disable systems indirectly.

Coolant leakage affects the facility in four ways:

- less coolant reaches the reactor or overheated machines
- pooled coolant conducts electricity
- coolant vapor creates steam that reduces visibility
- coolant contacting very hot machinery causes thermal shock

Simulation:

- A leaking coolant pipe subtracts from delivered coolant and adds `Coolant Pooling` to the local sector.
- If coolant pooling touches exposed electrical charge, the sector becomes electrified.
- If coolant pooling reaches heat 7 or higher, it becomes steam and increases smoke.
- If a hot machine receives a sudden large coolant flow, its stability drops by 1 unless it is throttled through a regulator.

Player-solvable responses:

- repair or replace the coolant pipe
- route coolant around the leak
- cut power before walking through pooled coolant
- open a drain before restarting cooling
- throttle coolant flow into overheated machinery
- use a bulkhead to isolate steam and preserve visibility elsewhere

### Movement Implications

Movement is not only a distance cost. The facility state changes how expensive or risky movement is.

Sector movement modifiers:

| Condition | Movement Effect | Extra Risk |
| --------- | --------------- | ---------- |
| Smoke 4+ | entering costs +1 move | diagnostic range reduced |
| Smoke 8+ | entering costs +2 move | cannot inspect across sector |
| Liquid Fuel 4+ | entering costs +1 move | ignition risk follows player tools |
| Coolant Pooling 4+ | entering costs +1 move | electrocution if charged |
| Active Fire | blocked unless shielded or suppressed | robot heat rises |
| Electrified Floor | blocked unless power is cut or insulated | robot damage |
| Low Pressure / Venting | entering costs +1 move | may push smoke or vapor |

The robot is not fragile, but it should not ignore the environment. Hazards create routing puzzles:

- the shortest path may become too slow
- a safe path may require toggling breakers first
- a locked door may protect the reactor but trap the robot away from tools
- venting smoke may clear movement while spreading vapor into another sector

### Conditions for Fire

Fire starts only when fuel, oxygen, and ignition are all present.

Fuel sources:

- fuel vapor 4+
- liquid fuel 6+
- burning machine
- overheated generator

Oxygen sources:

- normal unsealed sector
- open vent
- open bulkhead connection

Ignition sources:

- heat 8+
- electrical arc
- overloaded generator
- reactor startup spark
- pressure rupture through a fuel line

Simulation:

- If all three conditions are present, the sector gains `Fire`.
- Fire adds heat each turn.
- Fire converts nearby liquid fuel into vapor, then consumes it.
- Fire damages machines and pipes in the sector.
- Fire adds smoke to the sector and adjacent open sectors.
- Fire cannot pass through a locked fire-rated bulkhead, but heat can slowly stress that door.
- Fire dies when fuel is exhausted, oxygen is removed, or suppression exceeds fire intensity.

Player-solvable responses:

- remove fuel by closing valves or draining liquid
- remove oxygen by sealing bulkheads or disabling vents
- remove ignition by cutting power or cooling the sector
- suppress fire using coolant mist, foam canisters, or vent purge systems
- deliberately burn off fuel in an isolated sector when the reactor path must be cleared

### Fuel and Coolant Interaction

Fuel and coolant interact in useful and dangerous ways.

- Coolant can reduce heat and prevent fuel ignition.
- Coolant and fuel liquids don't mix.
- Coolant mist and fuel vapor don't mix.
- Coolant mist can suppress fire.
- A coolant leak near a fuel leak can create a false sense of safety: ignition is delayed while cooling works, then becomes critical if coolant supply runs out.

## Problematic States and Player-Solvable Hurdles

A hurdle is a problematic state that blocks progress, threatens a loss condition, or changes the route the player can safely use. Every generated hurdle must have at least two viable responses unless the level is explicitly teaching a mechanic.

### Fuel Leak Near Ignition Source

Problem:

A fuel pipe leaks into a sector containing an electrical arc, hot machine, or generator. Vapor will ignite after a visible countdown.

System interactions:

- fuel loss reduces generator runtime
- vapor increases fire risk
- liquid fuel slows movement
- open doors or vents may spread vapor
- coolant may delay ignition by lowering heat

Viable solutions:

- close the upstream fuel valve, then repair the pipe
- cut power to the ignition source and vent the vapor
- reroute fuel through a backup line
- lock both bulkheads, allow controlled burnoff, then reopen after fire dies
- activate coolant mist to keep heat below ignition while completing another task

Simulation details:

- Each turn, the pipe adds fuel equal to `Leak Rate`.
- Heat converts some liquid fuel into vapor.
- Vapor follows open airflow edges during hazard update.
- Ignition countdown is calculated from vapor, heat, and active ignition sources.
- Repairing under pressure costs an extra action or risks increasing leak rate by 1.

### Coolant Leak Across Powered Cable

Problem:

A coolant leak is pooling across a live cable or breaker. The sector will become electrified, blocking movement and possibly disabling power.

System interactions:

- coolant delivery to the reactor is reduced
- exposed power converts pooling into electrical charge
- electrified coolant blocks or damages the robot
- cutting power may shut down required machines

Viable solutions:

- toggle the breaker off, cross safely, repair the pipe, then restore power
- reroute power around the wet sector
- drain coolant before restoring the cable
- reroute coolant through a dry pipe path
- lock the sector and use a remote terminal to operate the machine beyond it

Simulation details:

- Pooling increases by leak rate each turn.
- If a live cable exists and pooling is 3+, electrical charge rises.
- At charge 4+, movement through the sector is blocked unless insulated.
- At charge 7+, the breaker trips and the connected power network splits.
- Drains reduce pooling at a fixed rate but may move coolant into lower sectors.

### Fuel Leak Plus Coolant Leak

Problem:

Fuel and coolant leak into the same sector. The coolant suppresses heat temporarily, but the combined spill slows movement and can spread vapor through steam or drainage.

System interactions:

- coolant delays ignition while available
- fuel vapor rises if heat climbs after coolant flow stops
- drainage can spread liquid fuel to another sector
- steam reduces visibility and increases movement cost
- repairing either pipe changes the balance of the hazard

Viable solutions:

- repair fuel first if ignition risk is rising
- repair coolant first if reactor heat is becoming critical
- open drains only after isolating downstream sectors
- vent steam after closing fuel valves
- maintain coolant flow deliberately while rerouting fuel elsewhere

Simulation details:

- Fuel and coolant pooling are tracked separately.
- Coolant reduces heat before vapor is produced.
- If heat remains 7+ after cooling, steam rises and carries a fraction of vapor along vent paths.
- Drainage moves a portion of both liquids unless a separator machine is powered.
- The diagnostic display shows which repair has the larger predicted effect over the next two turns.

### Fire Blocking the Critical Route

Problem:

An active fire blocks the shortest path to a required machine or terminal.

System interactions:

- fire raises heat and smoke
- smoke increases movement cost and reduces diagnostic range
- fire damages nearby pipes, possibly creating secondary leaks
- bulkheads can contain fire but may cut off access
- coolant can suppress fire but may cause electrical hazards

Viable solutions:

- seal bulkheads and take a longer route
- cut power, then use coolant mist for suppression
- vent smoke away from the route after removing fuel source
- sacrifice the burning sector while powering the required machine remotely
- drain fuel from the sector, wait for fire to consume remaining vapor, then pass

Simulation details:

- Fire intensity starts at 1-3 based on ignition strength.
- Each turn, fire consumes fuel and adds heat and smoke.
- If fuel remains and oxygen is present, intensity rises.
- Suppression reduces intensity before spread is calculated.
- Fire spreads only through open doors, vents, or flammable pipe ruptures.

### Smoke-Filled Sector

Problem:

Smoke does not immediately destroy anything, but it makes movement slower and prediction weaker. The player may lose action efficiency before reaching a timed failure.

System interactions:

- fire creates smoke
- steam from coolant leaks also counts as smoke
- vents can clear smoke or move it
- diagnostics become less useful through heavy smoke
- smoke can hide floor hazards only if the player has not scanned the sector

Viable solutions:

- activate ventilation toward a safe exhaust path
- open a bulkhead to disperse smoke, accepting spread risk
- route around the sector
- clear the originating fire or steam source
- use a diagnostic terminal to inspect through smoke before entering

Simulation details:

- Smoke rises in sectors with fire or steam.
- Ventilation moves smoke along active vent edges.
- Closed bulkheads block smoke spread.
- Smoke 4+ adds movement cost.
- Smoke 8+ prevents long-range inspection through that sector.

### Pressure Rupture in Fuel Line

Problem:

A pressurized fuel line is overloaded. If it ruptures, it will spray vapor instead of leaking liquid, creating a fast ignition threat.

System interactions:

- pressure stress damages the pipe
- fuel vapor accumulates faster under pressure
- venting pressure may push vapor into other sectors
- shutting fuel may starve the generator
- a pressure regulator can save the pipe but may overload a neighboring route

Viable solutions:

- rotate valves to reduce pressure before the rupture turn
- vent pressure into a noncritical empty sector
- shut down the generator fed by the line and close the fuel valve
- reinforce the pipe to buy time, then reroute
- isolate adjacent ignition sources before allowing a controlled rupture

Simulation details:

- Pipe integrity drops when pressure exceeds rated capacity.
- At integrity 0, the pipe becomes broken and leak mode changes to spray.
- Spray converts most leaked fuel directly into vapor.
- Pressure venting reduces pipe stress but moves vapor along the selected vent path.
- Reinforcement increases integrity but does not reduce pressure.

### Generator Starved by Fuel Loss

Problem:

A required generator is online but its fuel supply is leaking. It will shut down before the player can activate the reactor.

System interactions:

- power output depends on fuel flow
- low fuel causes brownouts, which can jam doors or stop pumps
- repairing the leak may require moving through the leaking sector
- routing more fuel may increase pressure and leak rate

Viable solutions:

- repair the fuel pipe
- reduce power load by disabling nonessential machines
- start a backup generator
- reroute fuel through a lower-pressure path
- store enough capacitor charge to bridge a short outage

Simulation details:

- Generator fuel buffer decreases when incoming fuel is below demand.
- At low buffer, output becomes unstable and power flickers.
- Flicker advances jam timers on powered doors and reduces pump efficiency.
- Load shedding reduces fuel demand immediately.
- Backup generators may produce less power but require fewer stable inputs.

### Overheated Generator with Nearby Fuel

Problem:

A generator is producing needed power but heating a sector that contains fuel vapor or a leaking fuel pipe.

System interactions:

- power stability conflicts with fire safety
- coolant can reduce heat but may short exposed cables
- shutting the generator may disable the coolant pump
- ventilation may cool the room but add oxygen

Viable solutions:

- throttle generator output and shed load
- route coolant through a regulator before cooling the generator
- repair the fuel leak before raising generator output
- power the coolant pump from a backup source, then shut down the generator
- seal the sector and run the generator only long enough to charge capacitors

Simulation details:

- Generator heat output scales with load.
- If heat reaches 8 while vapor is 4+, ignition is predicted.
- Coolant reduces heat after generator output, so undersized cooling may only delay ignition.
- Load shedding lowers both heat and fuel consumption.
- Capacitors store temporary power but discharge predictably each turn.

### Coolant Starvation and Reactor Heat Rise

Problem:

The reactor needs cooling, but coolant is leaking, blocked, or diverted. Reactor heat rises toward meltdown.

System interactions:

- coolant leaks reduce delivered cooling
- pressure can improve flow but stress pipes
- power loss stops pumps
- coolant sent to one overheated machine may starve the reactor
- steam can block access to valves

Viable solutions:

- repair the leak on the main coolant route
- reroute coolant through backup pipes
- increase pump pressure briefly, accepting pipe stress elsewhere
- throttle or shut down noncritical hot machines
- use emergency coolant reserve for a short delay

Simulation details:

- Reactor heat increases by core instability minus delivered cooling.
- Delivered cooling equals pump output minus leaks and blocked valves.
- Pump output requires power and may require pressure.
- Overpressure increases flow this turn but damages weak pipes.
- Emergency reserve reduces heat immediately but has limited charges.

### Electrified Bulkhead

Problem:

A bulkhead is needed for containment, but its controls are live, wet, or shorted. The player cannot safely lock or unlock it from the local panel.

System interactions:

- coolant or water pooling conducts charge
- power loss may freeze the door in its current state
- open door spreads smoke, vapor, fire, or pressure
- closed door may trap the player away from required tools

Viable solutions:

- cut power to the door circuit, operate manual override, then restore power
- drain the sector before touching the controls
- reroute control power through another breaker
- use a remote terminal if diagnostics are online
- isolate hazards elsewhere so the door no longer needs to move

Simulation details:

- Door controls require power unless manual override is available.
- If control panel charge is 4+, local operation is blocked.
- If charge reaches 8, the door jams and requires repair.
- Remote operation requires diagnostic network connectivity.
- Manual override costs extra actions but ignores power state.

### Jammed Door During Hazard Spread

Problem:

A door that should contain a hazard is jammed open or closed.

System interactions:

- jammed open allows smoke, vapor, pressure, or fire to spread
- jammed closed can block the only path to a required system
- low power or brownouts make jams worse
- pressure difference across the door may prevent manual movement

Viable solutions:

- stabilize power, then operate the door
- equalize pressure on both sides
- repair the door actuator
- reroute around the sector
- create a different containment boundary using adjacent doors

Simulation details:

- Jam state has a severity from 1-3.
- Each repair action reduces severity by 1 if pressure difference is safe.
- Brownouts increase severity on powered doors with active faults.
- High pressure difference blocks manual override.
- A closed containment loop is valid even if it uses different doors than the obvious one.

### Pressure Venting Through Hazardous Sector

Problem:

The safe pressure relief path crosses a sector with fuel vapor, fire, or coolant steam. Venting may solve pressure while spreading the hazard.

System interactions:

- pressure flow moves smoke and vapor
- venting can add oxygen to a fire
- pressure can push coolant pooling into lower sectors
- not venting may burst a pipe

Viable solutions:

- clear the hazardous sector before venting
- vent into a sealed sacrifice sector
- rotate valves to use a lower-capacity but cleaner path
- lock bulkheads downstream before opening the vent
- reinforce the pressure pipe and delay venting until another route is ready

Simulation details:

- Venting reduces network pressure by a fixed amount.
- Any vapor or smoke in the vent path is moved one sector per turn.
- If venting feeds a fire with oxygen, fire intensity rises.
- Sealed sacrifice sectors absorb pressure but lose stability.
- Reinforced pipes can survive overpressure for a limited number of turns.

### Unstable Pipe Chain Reaction

Problem:

Several damaged pipes are connected. Fixing only the first visible leak may increase flow through the next weak pipe and cause a later burst.

System interactions:

- repaired pipes restore flow and raise downstream pressure
- valves can protect one branch by stressing another
- coolant, fuel, and pressure networks may share physical sectors
- burst pipes can create fire, steam, or movement hazards depending on medium

Viable solutions:

- repair the weakest downstream pipe before restoring full flow
- throttle flow with a regulator
- reroute around the damaged chain
- isolate the branch and accept reduced system output
- use temporary reinforcement to survive until reactor activation

Simulation details:

- Each pipe has rated pressure and integrity.
- Flow restoration recalculates pressure across the whole network.
- Diagnostics show the next predicted failure after a planned valve state.
- Regulators cap flow but reduce delivered output.
- Temporary reinforcement decays after a fixed number of turns.

### Diagnostic Blind Spot

Problem:

A required prediction path is obscured by smoke, power loss, or a damaged diagnostic terminal. The player still knows the rules, but future consequences are less projected.

System interactions:

- smoke limits line-of-sight diagnostics
- power loss disables terminals and cameras
- fire or coolant shorts can damage sensors
- blind spots make multi-turn planning harder but should not hide immediate lethal threats

Viable solutions:

- restore power to diagnostics
- clear smoke or reroute camera feeds
- repair the local sensor terminal
- physically inspect the sector
- use conservative containment: close valves, lock doors, and stabilize before proceeding

Simulation details:

- Blind sectors still show current visible hazards when entered.
- Predictions beyond the blind sector are shortened or unavailable.
- Repairing diagnostics restores full forecast for connected systems.
- The generator must not place a mandatory invisible-only solution behind a blind spot.

### Reactor Startup Hazard

Problem:

The reactor can be activated, but startup creates a predictable heat, pressure, and ignition pulse. Existing leaks can make the final activation unsafe.

System interactions:

- startup increases heat and pressure for one or more turns
- fuel vapor in the reactor sector may ignite
- weak coolant pipes may burst under final pump load
- power demand may brown out doors or diagnostics

Viable solutions:

- pre-cool the reactor before activation
- vent pressure immediately before startup
- clear or seal fuel vapor in adjacent sectors
- charge capacitors to cover startup power demand
- lock containment doors so a noncritical sector absorbs the pulse

Simulation details:

- Startup applies a scripted but visible pulse profile.
- The forecast panel shows startup consequences before the player commits.
- If required systems are online but unstable, `REACTOR READY` becomes `REACTOR READY - UNSAFE STARTUP`.
- Unsafe startup is allowed if it does not violate hard loss limits, preserving player agency.

## Mechanic Simulation Reference

The simulation should be simple enough to predict by inspection.

### Heat

- Heat rises from reactor instability, fire, overloaded generators, and hot machines.
- Heat falls from coolant, ventilation, shutdown machinery, and time in stable sectors.
- Heat 7+ accelerates fuel vapor creation.
- Heat 8+ counts as an ignition source.
- Heat 10 damages machines and pipes each turn.

### Fuel

- Fuel is consumed by generators.
- Fuel can leak as liquid or spray as vapor.
- Liquid fuel slows movement at high pooling values.
- Vapor is the main fire risk.
- Ventilation reduces vapor locally but may move it elsewhere.

### Coolant

- Coolant removes heat when delivered to a machine or sector.
- Coolant leaks reduce delivered cooling and create pooling.
- Pooling can conduct electricity.
- Coolant contacting high heat creates steam.
- Sudden coolant on overheated machinery can reduce stability unless regulated.

### Power

- Power is generated, routed, consumed, stored, and lost.
- Brownouts do not immediately end the level; they reduce output, jam doors, and weaken pumps.
- Exposed live power plus coolant pooling creates electrical charge.
- Breakers define power network boundaries and are important player controls.

### Pressure

- Pressure moves useful flow but damages weak pipes.
- Overpressure creates predicted bursts.
- Pressure vents can save pipes but move airborne hazards.
- Pressure differences affect door operation.
- Regulators trade output for safety.

### Fire and Smoke

- Fire requires fuel, oxygen, and ignition.
- Fire produces heat and smoke.
- Smoke slows movement and shortens diagnostics.
- Fire spreads through open routes and burns fuel.
- Suppression, oxygen removal, or fuel removal can end fire.

### Stability

- Stability represents how close a sector, machine, or pipe is to mechanical failure.
- Stability drops from heat, fire, pressure bursts, electrical shorts, and thermal shock.
- Repairs restore local stability, not global safety by magic.
- Global facility stability drops when critical sectors fail, when fire spreads, or when multiple machines break.

## Hurdle Design Rules

Every hurdle should be generated with:

- a clear affected system
- a visible countdown or consequence
- at least one local solution
- at least one systemic solution
- one tradeoff that may create a secondary problem
- a validation check that the player can physically reach or remotely affect the solution

Local solutions are direct actions:

- repair the pipe
- toggle the breaker
- rotate the valve
- lock the door
- drain the floor

Systemic solutions change the wider machine:

- reroute flow
- shed load
- sacrifice a sector
- delay activation
- isolate a hazard and let it burn out
- use backup storage or reserves

The generator should reject a hurdle if:

- the only solution requires a disabled mechanic
- a hard loss occurs before the player can take the minimum required actions
- the solution requires crossing a blocked sector without an alternate route
- the forecast cannot explain why the problem is happening
- two hurdles combine into an unsolvable state before the player can respond

## Procedural Level Generation

Levels are generated deterministically from a compact generation request.


## Generation Inputs

### Seed

The seed initializes the deterministic random number generator.

### Enabled Mechanics

The enabled mechanics list defines which systems may appear in the level.

Example mechanics:

- `power`
- `cooling`
- `doors`
- `fuel`
- `failures`

The generator may only use mechanics from this list.

If a mechanic is not enabled:

- it must not be required for victory
- it must not appear as an unresolved hurdle
- it must not be needed to understand another generated system

For every mechanic enabled:

- the generator should include at least one meaningful use of that mechanic
- the mechanic may appear as a direct hurdle, a solution path, or an interaction with another hurdle
- if the mechanic is required for victory, the level must teach or expose its state before it becomes critical

Mechanic requirements:

| Mechanic | Required Presence | Example Hurdle | Example Solution Role |
| -------- | ----------------- | -------------- | --------------------- |
| `power` | at least one machine needs routed power | split power network | shed load to keep coolant pump online |
| `cooling` | at least one heat source needs cooling | coolant starvation | suppress fire or protect generator |
| `doors` | at least one sector boundary matters | jammed bulkhead | isolate vapor, fire, smoke, or pressure |
| `fuel` | at least one generator or fuel pipe matters | fuel leak near ignition | choose between power uptime and fire safety |
| `pressure` | at least one pipe network carries stress | pressure rupture | improve flow or vent hazard |
| `failures` | at least one timed degradation occurs | pipe burst in 3 turns | repair, reroute, isolate, or delay |

For every disabled mechanic, the level cannot generate associated tiles nor require associated actions.

Disabled mechanics also limit interactions. For example:

- if `fuel` is disabled, fire cannot require fuel-vapor reasoning
- if `cooling` is disabled, overheated machines must be solvable through shutdown, venting, or power load changes
- if `doors` are disabled, containment cannot require bulkhead locking
- if `power` is disabled, machines may be manually operated, pressure-driven, or already powered by abstract local supply

### Interaction Density

The generator should distinguish primary hurdles from interaction consequences.

Primary hurdle:

- the problem counted by `Hurdle Count`
- visible from the start or revealed by an explicit scheduled event
- has a named forecast and at least two viable responses

Interaction consequence:

- emerges from simulation because of a primary hurdle or player solution
- does not count against `Hurdle Count` unless it is deliberately generated as a primary hurdle
- must be forecast before it becomes critical

Example:

- Primary hurdle: fuel pipe leak near Generator A.
- Interaction consequence: coolant mist can suppress the heat but may electrify the wet floor if Breaker B remains on.

The generator can deliberately pair mechanics:

| Pair | Readable Interaction |
| ---- | -------------------- |
| fuel + power | generator uptime versus ignition risk |
| fuel + cooling | cooling delays ignition but leaks may create steam |
| cooling + power | coolant pooling creates electrical hazards |
| pressure + fuel | rupture converts liquid leak into vapor spray |
| pressure + doors | pressure difference blocks manual door operation |
| fire + doors | containment protects the reactor but may block access |
| smoke + diagnostics | predictions shorten until visibility is restored |

Difficulty can increase interaction density, but it should not make every hurdle interact with every other hurdle. A readable level usually has one dominant interaction and one secondary interaction.

### Hurdle Count

Defines how many major problems the level contains.

A hurdle is a meaningful obstacle that requires player attention, not just decorative damage.

Examples:

- a leaking pipe that prevents cooling from reaching the reactor
- a pressure route that will burst in 3 turns unless rerouted
- a locked door separating the player from a required generator
- a short circuit splitting the power network
- an overheating machine that must be cooled before activation
- a sector that must be sacrificed to protect the core

The generator should create an exact amount of primary hurdles.

Secondary consequences may emerge from simulation, but the initial readable puzzle should have the requested number of main hurdles.

### Difficulty

Difficulty controls pressure on the player, not randomness.

It can affect:

- max move distance
- starting global resource values
- distance between important machines
- urgency of scheduled failures
- amount of spare power, coolant, or fuel
- number of safe rerouting options
- repair costs
- density of damaged infrastructure
- how many hurdles interact with each other

Difficulty should not make the level less readable. Higher difficulty should create tighter tradeoffs and less slack.

### Solvability Validation

After generation, the level should run a deterministic validation pass.

Validation checks:

- every required system has a reachable activation path
- every primary hurdle has at least two possible solution plans
- no hard loss occurs before the player can take the shortest valid response
- every forecasted hazard has at least one visible cause
- generated interactions use only enabled mechanics
- movement hazards do not trap the player without a remote solution or alternate route
- final reactor startup has at least one safe or knowingly risky path

The validator does not need to find the best solution. It only needs to prove that the level is not impossible, unreadable, or dependent on hidden information.

## Hurdle Template Examples

### Cooling Pipe Leak

Problem:

Cooling does not reach the reactor. Reactor heat rises every turn.

Solutions:

- repair the leaking pipe
- reroute cooling through an alternate pipe path
- activate backup cooling

Difficulty modifiers:

- higher difficulty places the leak farther from the player
- higher difficulty adds a scheduled pipe burst
- higher difficulty reduces starting cooling

### Pressure Overload

Problem:

Pressure is building in a pipe network and will burst in a visible number of turns.

Solutions:

- rotate valve to redirect pressure
- vent pressure into a noncritical sector
- isolate the overloaded sector

Difficulty modifiers:

- higher difficulty creates consequences for every reroute
- higher difficulty gives fewer safe vent paths

### Split Power Network

Problem:

A required machine is not powered because the power network is split.

Solutions:

- reconnect cable
- toggle breaker
- activate backup generator
- deactivate a nonessential machine to free capacity

Difficulty modifiers:

- higher difficulty reduces spare power
- higher difficulty makes the player choose which machine stays offline

### Jammed Bulkhead

Problem:

A sector must be isolated, but a door is jammed or unpowered.

Solutions:

- repair door control
- restore power to the door
- take a longer route to another door

Difficulty modifiers:

- higher difficulty adds a countdown before the hazard spreads
- higher difficulty places useful resources behind the same door

### Overheating Machine

Problem:

A required machine cannot be activated until heat is reduced.

Solutions:

- route cooling to the sector
- reduce power load
- activate venting system

Difficulty modifiers:

- higher difficulty links cooling to another already stressed system

## Example Level: Cooling Sector B

### Starting Global Values

| System | Value |
| ------ | ----- |
| Power | 6/10 |
| Cooling | 2/10 |
| Pressure | 7/10 |
| Heat | 6/10 |
| Stability | 5/10 |

### Hurdles

1. Cooling pipe leak between the pump room and reactor chamber.
2. Pressure overload in the maintenance shaft, predicted to burst in 3 turns.
3. Bulkhead door can isolate the damaged sector, but doing so cuts off access to a generator.

### Player Options

#### Option A: Repair the Cooling Pipe

Cost:

- 2 actions

Effect:

- cooling reaches the reactor again

Tradeoff:

- the pressure overload remains unresolved

#### Option B: Rotate the Pressure Valve

Cost:

- 1 action

Effect:

- reactor pressure stabilizes

Tradeoff:

- pressure rises in the maintenance shaft
- pipe burst predicted there in 3 turns

#### Option C: Lock the Bulkhead Door

Cost:

- 1 action

Effect:

- damaged sector is isolated
- escalation stops there

Tradeoff:

- generator behind the door becomes unreachable
- global power will slowly decline

## Design Pillars

### Deterministic Systems

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

### Visible Consequences

The player should see upcoming failures and understand why they will happen.

### Meaningful Tradeoffs

The player should often solve one problem by making another problem worse.

### Procedural but Authored-Feeling

Generated levels should feel intentionally designed. The generator should use templates, validation, and readable system graphs instead of placing random damage everywhere.

### Resource Prioritization

The real puzzle is not a single lock-and-key solution. It is deciding which systems matter most and which losses are acceptable.

## Summary

This is an industrial chain-reaction puzzle game.

The player wins by understanding a deterministic machine under stress. Procedural generation creates replayable levels from a seed, a list of enabled mechanics, a requested number of hurdles, and a difficulty value. The generator's job is not to create chaos. Its job is to create readable, solvable, systemic problems with clear consequences and hard choices.