From 2376edab0dbb1ba4a729d893139fe077c5e39339 Mon Sep 17 00:00:00 2001 From: Frank Date: Sat, 9 May 2026 13:10:49 +0200 Subject: [PATCH] Revise simulation design doc --- docs/design.md | 1783 ++++++++++++++---------------------------------- 1 file changed, 503 insertions(+), 1280 deletions(-) diff --git a/docs/design.md b/docs/design.md index 2840dad..57a8092 100644 --- a/docs/design.md +++ b/docs/design.md @@ -1,1280 +1,503 @@ -# 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. +# 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 which systems to stabilize first. + +The revised simulation model is intentionally narrow: + +- a surface grid +- an underground fuel network +- an underground coolant network +- an underground electricity network +- surface props that connect vertically into exactly one underground network +- a reactor that must be supplied and kept cool +- a diagnostic UI that exposes the current state and the next predicted changes + +Each turn has three phases: + +1. Player phase: the player spends a limited number of actions. +2. Simulation phase: local network, leak, and heat rules are resolved deterministically. +3. Event phase: scheduled failures or 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 + +## Goal + +The reactor starts offline. + +To win a level, the player must: + +- restore electricity delivery to the required consumers +- restore coolant delivery to the reactor path +- restore fuel delivery to the required fuel consumer +- reach a stable enough state to activate the reactor + +When all required systems are ready, the game 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 terminal heat +- required consumers remain starved long enough to force shutdown +- cascading heat makes the level irrecoverable + +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, usually 3. + +Possible actions: + +- move +- interact with a flow prop +- interact with a consumer prop +- repair a leaking network cell +- inspect a cell or prop +- activate the reactor + +### 2. Simulation Phase + +The facility updates all active systems. + +Examples: + +- outside connections feed enabled networks +- enabled consumers draw from their bound network +- leaking underground cells emit their element into the surface cell above them +- neighboring surface cells exchange leaked matter or heat through deterministic lookup rules +- coolant reduces heat +- electricity interacting with coolant or fuel raises heat + +### 3. Event Phase + +Predicted events advance by one turn. + +Examples: + +- a leak worsens +- a consumer disables itself after starvation +- 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 relevant information is visible and predictable. + +The player can see: + +- the state of each underground network cell: absent, intact, or leaking +- the local amount band of leaked fuel, coolant, and electricity +- the local heat band +- whether each surface prop is enabled or disabled +- which consumer is currently starved +- the current global level state +- scheduled upcoming events + +The question is not: + +> "What is behind the corner?" + +It is: + +> "What happens if I let this pair of cells interact for one more turn?" + +## Simulation Model + +### Layered Grid + +Each map coordinate contains: + +- one surface cell +- 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 +- optionally the robot + +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 connection +- exactly one flow prop type on the surface +- exactly one consumer prop type on the surface + +The surface prop is an abstract vertical connection to one underground cell. + +### Network Semantics + +The three network families are intentionally symmetric. + +- Fuel: used by its consumer, dangerous when leaked next to electricity or high heat. +- Coolant: used by its consumer, safe by itself, lowers heat, dangerous when leaked next to electricity. +- Electricity: used by its consumer, safe by itself, dangerous when leaked next to coolant or fuel. + +Each underground network cell has only three structural states: + +- `Absent` +- `Intact` +- `Leaking` + +Each element amount uses the same three thresholds: + +- `Safe` = `0-9` +- `Caution` = `10-19` +- `Critical` = `20-29` + +Heat uses the same thresholds: + +- `HeatSafe` = `0-9` +- `HeatCaution` = `10-19` +- `HeatCritical` = `20-29` + +### Why This Formalization + +This model keeps the simulation small enough for a table lookup: + +- network topology is stored underground +- leaked matter and heat are projected onto the surface +- only the projected surface bands participate in the lookup matrix +- props, robot, and global level state modify or consume those projected bands before or after the matrix pass + +## State Inventory + +### Cell State + +Surface cell states: + +- `Open` +- `Blocked` +- `HeatSafe` +- `HeatCaution` +- `HeatCritical` + +Underground network states, repeated for fuel, coolant, and electricity: + +- `Absent` +- `Intact` +- `Leaking` +- `Safe` +- `Caution` +- `Critical` + +Notes: + +- `Absent` / `Intact` / `Leaking` describe the underground cell itself. +- `Safe` / `Caution` / `Critical` describe the local amount currently present in that layer or leaked onto the surface. +- A leaking underground cell injects its element into the surface cell above it during simulation. + +### Prop State + +Each network has exactly two prop types on the surface: + +- flow prop +- consumer prop + +Each prop has exactly two states: + +- `Enabled` +- `Disabled` + +Concrete prop states: + +- `FuelFlowEnabled` +- `FuelFlowDisabled` +- `FuelConsumerEnabled` +- `FuelConsumerDisabled` +- `CoolantFlowEnabled` +- `CoolantFlowDisabled` +- `CoolantConsumerEnabled` +- `CoolantConsumerDisabled` +- `ElectricityFlowEnabled` +- `ElectricityFlowDisabled` +- `ElectricityConsumerEnabled` +- `ElectricityConsumerDisabled` + +### Level State + +The whole level has exactly five states: + +- `Stable` +- `Caution` +- `Critical` +- `Ready` +- `Lost` + +Meaning: + +- `Stable`: all required consumers are fed and no terminal heat path is active. +- `Caution`: one or more required systems are degrading but recovery remains straightforward. +- `Critical`: the simulation predicts a loss without near-term intervention. +- `Ready`: the reactor activation prerequisites are met. +- `Lost`: terminal failure has already occurred. + +### Robot State + +The robot has exactly four states: + +- `Ready` +- `Interacting` +- `Blocked` +- `Damaged` + +Meaning: + +- `Ready`: free to move and act. +- `Interacting`: currently spending an action on a prop or repair. +- `Blocked`: the target move is refused because the destination is blocked or too hazardous. +- `Damaged`: the robot entered or remained in an unresolved hazardous cell. + +## Events That Modify State + +### Cell And Network Events + +- `CreateCellBlock`: changes a surface cell from `Open` to `Blocked`. +- `ClearCellBlock`: changes a surface cell from `Blocked` to `Open`. +- `StartLeak[n]`: changes an underground network cell from `Intact` to `Leaking`. +- `RepairLeak[n]`: changes an underground network cell from `Leaking` to `Intact`. +- `InjectLeak[n]`: adds one band of leaked element from a leaking underground cell into the surface cell above. +- `Equalize[n]`: transfers one band of the same element from the higher local band to the lower local band between neighboring cells. +- `HeatTransfer`: transfers one heat band from the hotter cell to the cooler cell. +- `HeatUp[1]`: increases local heat by 1 band-equivalent. +- `HeatUp[2]`: increases local heat by 2 band-equivalents. +- `CoolDown[1]`: decreases local heat by 1 band-equivalent. +- `CoolDown[2]`: decreases local heat by 2 band-equivalents. +- `Short[1]`: electricity and coolant interact, raising heat and discharging electricity. +- `Short[2]`: a stronger version of `Short[1]`. +- `Ignite[1]`: fuel and electricity or fuel and heat interact, raising heat in both participating cells. +- `Ignite[2]`: a stronger version of `Ignite[1]`. +- `ClampBand`: clamps all element and heat values back into `0-29`. + +`[n]` means one of the three carriers: fuel, coolant, or electricity. + +### Prop 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`. +- `FeedFromOutside[n]`: an enabled flow prop pulls supply from the level boundary into its bound network. +- `ConsumeFromNetwork[n]`: an enabled consumer removes one band from its bound network and emits its intended service. +- `StarveConsumer[n]`: a consumer receives too little supply and degrades the level state. + +### Level Events + +- `EscalateLevel`: `Stable -> Caution -> Critical`, and `Ready -> Caution` if readiness is lost. +- `RecoverLevel`: `Critical -> Caution -> Stable`. +- `MarkReady`: `Stable` or `Caution` becomes `Ready` when all activation prerequisites are satisfied. +- `LoseLevel`: `Critical` or `Ready` becomes `Lost` when a terminal rule fires. + +### Robot Events + +- `MoveRobot`: moves the robot into a valid neighboring open cell. +- `StartInteraction`: changes `Ready -> Interacting`. +- `FinishInteraction`: changes `Interacting -> Ready`. +- `BlockRobot`: changes `Ready -> Blocked` for the attempted move or action. +- `DamageRobot`: changes `Ready` or `Blocked -> Damaged`. +- `RecoverRobot`: changes `Blocked -> Ready` after the blocking condition is removed. + +## Projection Into The Lookup Matrix + +Not every stored state belongs in the pairwise neighbor table. + +The pairwise table only operates on projected surface fields: + +- `FuelSafe` +- `FuelCaution` +- `FuelCritical` +- `CoolantSafe` +- `CoolantCaution` +- `CoolantCritical` +- `ElectricitySafe` +- `ElectricityCaution` +- `ElectricityCritical` +- `HeatSafe` +- `HeatCaution` +- `HeatCritical` + +Projection rules: + +- within a single cell, unordered pairs of projected field states use the same lookup table as neighboring cells +- `Blocked` cells do not participate in neighbor lookup across that edge. +- `Leaking` underground cells first emit their carrier into the surface cell above them through `InjectLeak[n]`. +- flow props and consumers act before the neighbor lookup, because they modify underground supply +- level state is derived after the lookup, because it is global rather than local +- robot state is resolved after the lookup, because it reacts to the final local hazard state of its cell + +This keeps the spatial interaction system small while still identifying the full set of cell, prop, level, and robot states. + +## Simulation Order + +The revised simulation loop for one turn is: + +1. Resolve player actions. +2. Apply `FeedFromOutside[n]` for every enabled flow prop. +3. Apply `ConsumeFromNetwork[n]` or `StarveConsumer[n]` for every enabled consumer. +4. Apply `InjectLeak[n]` for every leaking underground cell. +5. For every open cell, evaluate every unordered pair of projected field states inside that same cell. +6. For every open cell, evaluate the current cell against its right neighbor and bottom neighbor. +7. For each pair, read the projected field-state table below and emit the listed event. +8. Apply all emitted deltas. +9. Clamp all values with `ClampBand`. +10. Update robot state from the final local surface cell it occupies. +11. Derive level state from required consumers, reactor prerequisites, and terminal heat conditions. +12. Advance scheduled turn events. + +## Pair Lookup Event Legend + +The symmetric lookup matrix uses the following event names: + +- `Hold`: no direct change. +- `FuelFlow`: apply `Equalize[Fuel]`. +- `CoolFlow`: apply `Equalize[Coolant]`. +- `ChargeFlow`: apply `Equalize[Electricity]`. +- `HeatFlow`: apply `HeatTransfer` by 1 band. +- `HeatFlow2`: apply `HeatTransfer` by 2 bands. +- `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 cells +- same-carrier amounts equalize between neighboring cells + +## Symmetric Pair Lookup Table + +Rows and columns are identical projected field states. 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 in the neighbor table. They are local vertical controls on top of the underground layers. + +Flow prop rule: + +- if enabled, the prop allows `FeedFromOutside[n]` or onward transport through its bound network +- if disabled, its bound network path is isolated at that cell + +Consumer prop rule: + +- if enabled and supplied, it consumes one band and produces its service +- if enabled and unsupplied, it triggers `StarveConsumer[n]` +- if disabled, it neither consumes nor produces + +Required consumer mapping: + +- Fuel consumer: required for reactor fuel path +- Coolant consumer: required for reactor cooling path +- Electricity consumer: required for reactor activation path + +## Robot Rules + +The robot is intentionally simple. + +- The robot moves only on the surface. +- The robot can occupy only `Open` cells. +- A move into a cell that resolves to `HeatCritical` changes the robot to `Damaged`. +- A move into a blocked or forbidden cell changes the robot to `Blocked`. +- Interacting with a prop or repairing a leak changes the robot to `Interacting` until the action resolves. + +## Level Rules + +Level state is derived, not spatially diffused. + +Suggested derivation: + +- `Stable`: all required consumers supplied and no reactor-adjacent `HeatCritical` +- `Caution`: at least one required consumer is unstable or one reactor-adjacent cell is `HeatCaution` +- `Critical`: any required consumer is starved for too long or any reactor-adjacent cell is `HeatCritical` +- `Ready`: all required consumers supplied and the reactor area is not `HeatCritical` +- `Lost`: a scripted terminal rule or unrecoverable reactor heat condition fires + +## Design Pillars + +### Deterministic Systems + +The same actions in the same state always produce the same result. + +### Visible Consequences + +The player sees both the local field bands and the global state they imply. + +### Meaningful Tradeoffs + +Turning one network on may feed a required consumer while making a leak more dangerous. + +### Small Formal Core + +The simulation should be explainable as: + +- underground network structure +- surface leaks +- one shared threshold system +- one pairwise lookup table + +### 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 table-driven readability. + +## Summary + +The revised design reduces the simulation to a small layered system: + +- three disjunct underground networks +- two prop types per network +- one shared threshold model +- one projected surface interaction table +- one derived global level state + +That gives a solid basis for a deterministic simulation that can be visualized, forecast, and extended without reintroducing hidden complexity.