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 the v0.6 initial-development release of an operationally evaluated practitioner proposal. 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. It does not establish independent adoption, long-term productivity, empirical proof, or universal fit. See the evaluation boundary and 0.6.11 release evidence. The 1.0 readiness review separates the proposed 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

Use STAGE on the real work already in front of the game:

1. Frame the player, author, or maintainer outcome and identify decisions that remain human-owned.
2. Inspect the actual project path, current source-control state, effective toolchain, and authored assets before editing.
3. Plan and build the smallest complete change through canonical project sources while protecting unrelated work.
4. Rehearse each material claim through the smallest route that includes its production consumer.
5. Judge mechanical evidence separately from human decisions about visuals, audio, feel, balance, pacing, and fun.
6. Checkpoint the accepted result, or tune, diagnose, defer, or revert.

When work originates or materially expands a player-facing loop, discuss the gameplay intent with the human designer first. The agent can research, model, and compare alternatives, but the intended experience and tradeoffs require a human-approved hypothesis. Then build one thin complete loop and have the owner play it before multiplying the premise through broad architecture, modes, content, or polish. Mechanical success does not lift that product gate, and owner acceptance does not establish a broader audience claim.

For systems-heavy work, the player-system evidence guide traces how a player perceives, decides, acts, reads consequences, learns, and adapts. It links decision design to feedback, UI, onboarding, pacing, progression, balance, accessibility, ethics, and claim-matched playtesting without pretending to compute fun.

No STAGE map, manifest, custom review surface, or evidence package is required. The delivery method explains the loop, and the Task-Evidence Matrix helps match evidence to a claim.

For a longer solo effort, the optional Stage Director's Flow surrounds delivery with a small Cue -> Dialogue -> Ready -> Active -> Rehearsal -> Director's Call -> Checkpointed attention loop. It preserves the useful simplicity of paper notes while preventing an agent from treating every idea as approved implementation work. The Quality Gates And CI guide then separates Source, Model, Engine, Consumer, Distribution, and human Director evidence without calling a mechanically green project a good game. The Change, Concurrency, And Release Workflow defines short-lived work-item branches, worktree and Unity asset ownership, serial integration, exact build identity, and human-gated release proposals. The Task Continuity guide keeps long-lived project knowledge in a short versioned Context Spine, uses revision-bound handoffs only for unfinished work, and provides a fresh-task check before an oversized conversation is retired.

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

Frame -> Inspect -> Plan -> Build -> Rehearse -> Judge -> Checkpoint
  ^                                               |
  +---------------- tune or revert ---------------+

The loop is mixed-initiative. Agents may propose, challenge, investigate, and implement. Humans decide what the product should become and whether the result is acceptable.

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.