Spencer Morris
← Project index
ENGINEERING NOTES / 18 2 MIN READ

Staff Games

A game-development environment that makes scene files, simulation tools, and runtime observations accessible to coding agents.

Prototype / development
Staff Games Siege runtime showing a first-person view of a brick test buildingView full size ↗
Actual local Siege runtime from the retained game build, using the project's Ammo physics asset. This shows the game produced by the file-based workflow; the separate editor redesign image below remains a mockup.
01 / THE PROBLEM

What needed solving.

An agent can edit code without understanding what appeared on screen. Game tools need a shared identity for the object in a file, the object in the renderer, and the object a person points at.

02 / SYSTEM OUTLINE
  1. 01Game files + stable references
  2. 02Editor actions + runtime observations
  3. 03Measured checks + scene links

Simplified from the implementation and project notes.

03 / TECHNICAL DECISIONS

How it fits together.

Keep files as the shared state

Scene JSON, level files, manifests, assets and scripts are the game's source of truth. The editor and agents read and write those same files, validated through game-kit formats; the runtime hot reloads them rather than syncing a second editor database.

Resolve references before editing

Stable entity and level-element references connect a file object to what appears in the renderer and what a person selects. Validated actions modify files; the shared PlayCanvas runtime and local HTTP/CLI harness then expose the same operations to both editor views and agents.

Observe measured results

The interaction layer can measure visibility, pixels, distances, actor state and scene metrics, with unsupported measurements failing explicitly. Focused checks cover references, observations, pixel identities and fixed-camera regressions. These establish specified scene conditions, not fun or complete visual correctness.

Studio redesign mockup, Levels view. A design artifact, not a screenshot of the complete shipping editor.View full size ↗
Studio redesign mockup, Levels view. A design artifact, not a screenshot of the complete shipping editor.
04 / WORKING METHOD

Building and checking it.

The documented loop is resolve an object reference, invoke a validated editor action, wait for a run or file event, then observe and check the result. Request an image when appearance matters, and return an app link to the selected object.

The redesign uses viewport-first mockups and an implementation plan tied to existing views. The image here is that design artifact; it is not evidence that every proposed panel shipped.

05 / STATUS & LIMITS

This is a local development environment and game runtime, not a general autonomous game producer. Measurements establish specific conditions in a scene; they do not establish that the game is fun or that every visual defect has been caught.

Source notes

Based on repository code and project records reviewed on October 30, 2026. Historical checks are described as recorded, not rerun for this article. Screenshots, renders, and mockups are labeled individually.

  • staff-games/docs/architecture.md
  • staff-games/docs/interaction-layer.md
  • staff-games/docs/design/studio-redesign/PLAN.md
  • staff-games/docs/design/interaction-layer/VERIFICATION.md
  • staff-games/games/playground/README.md
← All projectsNEXT PROJECTPer Aspera: The Show →