STAGE Game Engineering

STAGE is a human-directed method for making game projects legible, operable, and credibly verifiable by humans and coding agents.

The name describes five project qualities:

• Systems-oriented: behavior has explicit domain ownership, state, rules, and lifecycles.
• Tool-mediated: work uses the project's authoritative engine, editor, runtime, middleware, and source-control paths; dedicated tools are added only when recurring work earns them.
• Agent-operable: the selected change path is legible and safely actionable through existing project routes or earned operations.
• Governed: humans retain authority over intent, taste, priorities, acceptance, and irreversible actions.
• Evidence-backed: accepted changes carry evidence appropriate to their claims.

STAGE is not an engine, framework, dependency-injection container, or promise of autonomous game creation. It aims to increase trustworthy change throughput per unit of human attention without transferring product authority to an agent.

Status

This repository contains STAGE v1.0, an operationally evaluated practitioner proposal with an owner-accepted 1.x compatibility commitment. It originated in The Circussy One and has been exercised through external maps and operations across Unity, Godot, a custom browser engine, and a data-driven Rust/Bones game.

The owner's Solo Unity workflow is operational. Current evidence supports the method's mapping, proportionality, safety, and evidence semantics. The owner-led Salvageist pilot adds sustained delivery, human correction, and concrete workflow-cost lessons. This does not establish independent adoption, long-term productivity, empirical proof, or universal fit. See the evaluation boundary and 1.0.0 release evidence. The 1.0 readiness review separates the accepted stable personal-use contract from evidence that is useful but not a release gate.

The documentation map identifies the canonical source for practitioner guidance, maintainer operations, research evidence, decisions, and release history.

For a navigable human reading interface, run:

npm --prefix website ci
npm --prefix website start

The Docusaurus site reads canonical repository Markdown directly. It owns navigation and presentation, not a second copy of STAGE's rules or decisions. The same derived interface is published automatically after a successful main quality gate at stage.zoshachi.com.

Start With One Change

Ask for the outcome and name any meaningful boundary. The agent follows Understand → Change → Verify → Deliver: recover authority and protected state, implement the smallest complete result, exercise its production consumer, and create a task-only local commit after relevant mechanical checks pass. Human acceptance, push, merge, and publication remain separate decisions.

The delivery guide is the complete ordinary path. A project map, ticket, worktree, handoff, custom operation, or evidence package is needed only when the work earns it. The optional Director's Flow helps choose among several outcomes without imposing another state machine.

For new or materially changed gameplay, recover or obtain an approved hypothesis, build one complete playable loop, and obtain human play feedback before broad expansion. Settled fixes do not reopen design approval. Consult the conditional gameplay, visual, quality, and continuity guides when their subject becomes material. Source-control guidance covers protected staged work, useful isolation, and release preparation.

Use In Codex

The method does not require installation. To make its four workflows available in Codex from this private clone, run from the repository root:

codex plugin marketplace add .
codex plugin add stage-game-engineering@stage-local

Open a new Codex task after installation. For ordinary game work, request the change directly; stage-deliver-change is the plugin's implicit primary skill. Use a full plugin-qualified invocation for the three explicit workflows:

$stage-game-engineering:stage-orient
$stage-game-engineering:stage-verify
$stage-game-engineering:stage-map-project

Use stage-orient for read-only fresh-task recovery, stage-verify for check-only review of an existing change or claim, and stage-map-project only for deliberate map adoption, audit, or maintenance. The Codex owner guide gives the exact flow.

Do not rely on a bare skill name. It is the skill-internal name, but current Codex consumers do not consistently resolve it as an explicit plugin invocation.

Confirm the active source and installed package with:

codex plugin list --marketplace stage-local

Codex caches installed plugin releases. After updating the plugin version, run the plugin add command again and begin another new task. An open task retains the skill snapshot with which it started.

Core Loop

Understand -> Change -> Verify -> Deliver

These are working steps, not forms to complete or headings to narrate. The specification preserves eight universal Safety Kernel obligations; optional contracts apply only after deliberate adoption.

Optional Capabilities

STAGE is not a maturity ladder. Add only the capabilities whose recurring cost, ownership risk, or named consumer justifies persistence.

Need	Optional capability
Repeated orientation, ownership, or operation ambiguity	A proportional Project Map through stage-map-project
A personal Unity dependency and operation baseline	The non-normative Solo Unity profile
Repeated CI, release, audit, analytics, or publishing consumption	The smallest durable operation or evidence adapter that consumer actually needs

Visual implementation, diagnosis, audits, and polish stay in the ordinary delivery loop and the live editor or game. The Visual Work guide explains the claim-specific safeguards and the production-integrated gallery pattern without defining another plugin route. Screenshots and video are optional transport for a decision-bearing artifact consumer, not a parallel visual product. When a game needs a codex, bestiary, gallery, model viewer, world previewer, or inspect mode, build it as an ordinary product or authoring feature through the normal delivery loop, not as STAGE review infrastructure. Project mapping is an explicit-only companion skill, not a setup step for ordinary delivery. See Adoption for the complete need-triggered capability menu.

Safety Kernel And Laboratory

Every STAGE-directed change follows the eight-rule Safety Kernel: human direction, protected state, fail-closed authority, canonical sources and real consumers, claim-matched evidence, truthful outcomes, reversibility, and verified read-only boundaries. It requires no STAGE artifact or prescribed runtime architecture.

This repository also contains a Maintainer Laboratory for skill packaging, schema compatibility, migrations, studies, the Solo Unity profile, and release verification. Games do not adopt that machinery by default. Contributors to STAGE itself should use the maintainer guide.

The boundary is physical: plugin/ contains the concise installable delivery, orientation, verification, and mapping procedures; the rest of this repository is not copied into the Codex plugin cache.

Human reading and agent execution use different interfaces over the same canonical repository sources. See Documentation Surfaces for that boundary.

Design Lineage

STAGE composes established ideas rather than claiming a new computer-science primitive: data-driven game design, explicit systems, dependency inversion, functional-core influences, mixed-initiative co-creativity, observability, deterministic rehearsal, and reversible source-control workflows.

Its proposed contribution is the combination of those practices around one optimization target: complex game projects that remain human-steerable, agent-operable, and credibly verifiable.