Lead an earnest monster crew through ruined industrial dungeons and leave each site visibly safer, sorted and useful.
A
EXECUTIVE GAME CONTRACT
A dangerous worksite becomes a company that can clean itself
The player is the field foreman of a small monster cleanup crew. They read a physical dungeon, demonstrate safe work, automate solved labor, intervene at valuable moments, and turn each cleared region into a permanent operating capability.
Select a visible mess or hazard, choose Safe / Fast / Survey, and see the object, crew pose, risk and materials change together.
Practical satisfaction: chaos becomes a legible production line because the player understood it.
Read stop reasons, forecast risk/capacity, encode SOP rules and reserve Focus for exceptions rather than routine tapping.
Facilities, projects, SOP mastery and certifications automate old labor while the next chapter changes the constraint.
Restore twelve regions, resolve the Dungeon Heart, choose a world-repair ending, then enter bounded inspections or an optional second shift.
ANTI-PILLARS
No generic clickerNo invisible waitingNo multiplier-only choiceNo card-wall dashboardNo random punishment without telegraphNo endless prestige treadmill
IMPLEMENTED CURRENT
Chapter 1 registry and company-cycle authority; Chapter 2 entry slice contracts 1-4; 4-room current sites; 3 core crew plus registered unlocks; Safe/Fast/Survey; Focus, SOP, facilities, persistent transformations, 8-hour offline cap and save v8. Exact authority remains in cited Godot/content files.
PROPOSED DESIGN TARGET
Release contract of 12 chapters, 144 story contracts, 36 crisis operations, 60 regional projects and 120 postgame inspections. Proposed rows in this book do not exist in runtime and require later milestone approval, implementation and evidence.
B
COMPLETE INFORMATION ARCHITECTURE
World first, work decision second, company detail on demand
FIELD / 现场
Live workOpeningManual cleanupAutomatic workBottleneckIncident / recoveryRewardNext cycle
Crew / 员工RosterEmployee detailAssignment
Base / 基地EquipmentSOP rulesCertification
Archive / 档案Work ordersCompany changesHelp
Settings / 设置Language + textMotion + powerAudio
Page contracts
| ID / page | Purpose + routes | Priority information | Actions + back | Required data | Variants |
|---|
Modal contracts
| ID / parent / trigger | Purpose + exact content | Choices | Close/back | Error + resulting state |
|---|
C
FULL UI ARTBOARD ATLAS
Every named surface is visible together
The frames below render deterministic states from the secondary interactive prototype. They are design artboards, not Godot runtime captures.
Page and control-state artboards
Modal artboards in parent context
Coverage matrix
| ID | Inventory | Artboard | EN | ZH | 100% | 130% | State variants |
|---|
D
GAMEPLAY SYSTEM DESIGN
The incremental chain changes responsibility, not only speed
Important action contracts
| Action / input | Authoritative result | World feedback | UI + audio feedback | Reject / recovery |
|---|
Unlock and automation order
Failure and recovery
Save, offline and reset
1-3 minute decision clock
E
NUMERIC + ECONOMY DESIGN
Every number names its authority and reset boundary
CURRENT values cite repository authority. PROPOSED values are targets and never presented as implemented.
Resource dictionary
| ID / unit | Start + visibility | Sources | Converters / sinks | Capacity | Reset / carryover | Authority |
|---|
Generators and production processes
| Process ID | Owned / active count | Input / consumption | Base production | Cap / stop | Unlock / authority |
|---|
Workers and tools
| ID | Status / owned | Power / safety | Consumption / growth cost | Unlock | Specialty / tool + responsibility | Upgrade effect |
|---|
Facility levels and exact costs
| Facility / level | Owned / unlock | Cost | Behavior change | Bottleneck answered | Authority |
|---|
Formula sheet
Worked examples
Five pacing profiles
| Profile | First action | First reward | Automation | Bottleneck | Independent choice | Transformation | Chapter exit / ending | Max no-decision |
|---|
F
STRATEGY + CHOICE DESIGN
Options change value with forecast, capacity and build
| Choice | Known / uncertain | Immediate benefit | Opportunity cost | Future consequence | Two rational states | Recovery / anti-dominance |
|---|
Build specialization matrix
| Build | Operations / dispatch | Recovery / survey | Safety / stability | Weakness | Best state |
|---|
Synergy and incompatibility
Failure diagnosis and anti-exploit rules
G
LEVEL / CHAPTER / CAMPAIGN DESIGN
12 chapters, 144 bounded story contracts, one ending
Chapter 1 and Chapter 2 entry-slice rows retain current IDs and status. All other rows use design.* IDs and are explicitly proposed.
Campaign beat map
Current room units
| Stable ID / status | Player goal | Mechanic + decision | Pressure / numeric gate | Failure / recovery | Reward / next bridge |
|---|
Proposed release room-prototype map
| Design ID / chapter | Theme + player goal | Introduced / practiced / tested | Primary decision | Pressure / numeric gate | Duration | Failure / recovery | Reward / persistent use | Bridge |
|---|
Contract-level release map
| ID / status | Theme + goal | Introduced / practiced / combined / tested | Primary decision | Pressure / numeric gate | Duration | Failure / recovery | Reward + persistent change | Bridge |
|---|
Cycle and reset units
| Cycle ID / status | Entry | Player decision | Reset | Carryover | Completion / next difference |
|---|
Cycle, ending and postgame
H
PRESENTATION + IMPLEMENTATION SPECIFICATION
Genuine pixel worksite, clear engine text, restrained industrial audio
Component inventory and stable dependencies
| Component ID | Responsibility | Data dependency | States | Acceptance |
|---|
Feedback, art, VFX and audio event intent
| Event | Visual timing | World proof | Music / SFX intent | Accessibility / low power |
|---|
Localization and accessibility
Asset and evidence boundary
I
VERIFICATION
Completeness is measurable; runtime and human gates stay separate
Acceptance matrix
| Gate | Method | Result | Evidence | Not proven |
|---|
DESIGN-SPEC EVIDENCE ONLY
This book does not grant human fun, human visual review, human listening, Godot runtime equivalence, physical-device verification, signing, store acceptance or release acceptance.