Skip to main content

SubZeroDev.SunTrap

Sun Trap — a satirical resort-management simulation. Build a holiday paradise, then discover that people, alcohol, plumbing, weather, queues, staffing and basic geometry have formed an alliance against you.

Status: design and implementation planning only. Nothing executable has been built, played or tested here — the design is unproven in every respect, and the MVP exists to find out which parts of it are wrong. All balance numbers are placeholders.


What This Repository Is

The game. It is content and design, built on an engine that lives elsewhere.

SubZeroDev.GameEngine the deterministic platform
└── world-graph the kind — implemented in GameEngine 0.5.0
└── Sun Trap this repository — campaigns, design, client, balance

The engine is SubZeroDev.GameEngine. This mirrors the relationship SubZeroDev.GameOfLife has with the simulation kind: the kind contract lives in the engine, the game lives here.

Engine Integration Status

The shared engine and the world-graph kind Sun Trap needs are implemented and tested. GameEngine publishes the supported public package @the-running-dev/[email protected], including the kind and its campaign interfaces. Sun Trap remains a design-and-planning repository because it has not yet pinned that dependency or authored executable campaign content. The Implementation Programme records the completed M2–M6 evidence audit, including the tagged engine checks. This repository must consume that immutable published version, not create a local substitute.

Authoritative engine resourceUse it for
World-Graph KindThe kind seam, tick pipeline, actions, determinism, projection, reason codes, events, validation, and game/engine boundary
The CoreThe GameState envelope, session store, projection boundary, validation, replay, and save rules
ClientsThe client-as-projection rule and API coverage requirements
Content PacksPack resolution and campaign-version identity
Engine repositoryCurrent implementation status and the source of the published documentation

The engine owns determinism, seeded randomness, canonical serialization, save and migration, the content registry, validation, localization, projection, sessions, achievements, replay, and the API and MCP surfaces. None of it is re-implemented here.

The kind contract owns the tick pipeline, guest and staff agents, pathfinding, queues, construction, the resort economy, incidents and objectives. Its implementation ships through the engine-owned package surface; changes to those mechanics remain engine work, not a local substitute.

This repository owns maps, scenarios, building and product definitions, guest archetypes, balance, narrative voice, the visual client, and the game's own definition of done.

The Engine Contract

The kind this game runs on is specified at World-Graph Kind — the document to read before adding anything here that looks like engine behaviour. Several things that feel like game decisions are already fixed there:

Already decided by the engineWhere
What may live in game state, and what may not§3
That a batch of ticks equals the same ticks taken singly§5
The action list and their parameters§6
That win and loss are not engine statuses§8
Integer-only arithmetic, tie-breaking by id, derived entity ids§9
Reason codes and event names§11, §12
That content packs merge campaigns wholesale and strings per key§14

The wider engine contract, when a question is not kind-specific:

DocumentAnswers
ArchitectureEvery settled decision, including §1a — the test for whether something is a kind or a campaign
The CoreThe GameState envelope, the Kind seam, the engine API, projection, validation
ClientsWhat a client may and may not do, and the coverage checklist that proves it
Content PacksHow packs resolve, and why campaignVersion becomes a digest

Documentation

The documentation site is published through GitHub Pages at suntrap.subzerodev.com. This README is the site home; the documentation is published below /docs/. The installer-managed Docusaurus project lives in docs/, and authored Markdown lives under docs/docs/. The site root is generated from this README. See the documentation-site guide for local checks and deployment behaviour.

Read the game documents in this order:

DocumentHolds
VisionWhy this game exists, what it should feel like, what is out of scope
Game DesignThe gameplay: map, guests, buildings, queues, staff, economy, incidents, objectives
Client SpecificationThe visual client — what it renders and what it may never do
MVPThe smallest slice that proves the game, and its definition of done
Implementation ProgrammeThe cross-repository architecture, milestones, task checklists and acceptance gates
Roadmap, Risks, and Open QuestionsPhases, risks, and what is still undecided
Content AuthoringCatalogs, ids, localization, balance and the engine contract boundary

Originality

This game is inspired by the resort-management genre and reproduces none of it. Identity, art, writing, scenarios, building names, maps, balance and UI are original. No proprietary names, assets, text or expression from any existing title appear in this repository, and none may be added.

View the documentation