Skip to main content

Case Study: The Circussy One

Context​

The Circussy One is a circus-themed third-person auto-combat roguelite prototype built in Unity. Its architecture and workflow evolved during an unusually intensive month of human-agent collaboration involving gameplay systems, procedural terrain, UI, visual effects, audio middleware, editor tooling, content authoring, diagnostics, documentation, and source control.

The case study is the origin of STAGE, not proof that every project should copy its code structure.

The later visual-workflow lesson applied STAGE's then-current detached evidence workflow to the project's real Unity Visual Test Lab. It exposed a method-level error as well as visual findings: portable captures and a contact sheet had been built before a useful engine-native review surface. The project subsequently composed its real content bindings, named beats, timeline playback, presentation controls, and validation into a Visual Almanac. That corrected engine ownership but did not establish that a generalized Almanac was useful product or method infrastructure. The detached export protocol was retired, and the later in-engine experiment is retained as historical evidence rather than a required STAGE surface.

The resulting lesson is broader than moving one page into Unity. Engine-native is not automatically useful. Interactive inspection, agent operation, visual-regression capture, shipping content browsing, and portable evidence have different responsibility contracts, but their existence does not justify duplicate renderers, catalogs, or a common gallery architecture. Direct engine preview or the running game remains the default review route. A gallery, codex, or bestiary must justify itself as a game or authoring feature independently of STAGE.

The project director later rejected the detached contact sheet as a development workflow. Its Enemy Arrival stills and motion remain the one useful narrow sequence; the isolated Performer Jump export was rejected as insufficient. The broad package remains in Git history; the useful Enemy Arrival sequence is retained as a failure lesson. It should not be expanded to cover more game content. Future work begins in Unity or the running game through the production consumer. The coherent Enemy Arrival sequence demonstrated the value of reviewing real production motion; it did not demonstrate the value of a generalized Almanac. Asset-local questions remain cheaper in Unity's existing previews, while composed questions can use the direct game route. Custom persistent UI is an optional project decision gated by recurring utility, not a STAGE maturity step.

That first native correction exposed another boundary. Opening a Scenario from the editor catalog injected the selected profile and authored content, while opening the same generated scene directly could fall back to capsule actors. The runtime scene therefore was not yet an independent entry point. Commit ce757463 serialized the profile and content identity into generated Scenarios, resolved them during runtime startup, and added an in-game Almanac panel with named beats, playback, pause, restart, loop, seek, readiness, and validation. Direct Play then showed the real Bibi and Audience Member presentation without an earlier editor-window session. The correction passed 1,444 EditMode tests and eight composed PlayMode smoke tests; human aesthetic acceptance remains a separate decision.

Quantitative Shape​

At the time of analysis:

  • the Git history contained 422 commits beginning from the initial Unity baseline;
  • an indexed June 8 to July 5 conversation subset contained 1,260 user messages;
  • heuristic markers found 306 planning prompts, 201 implementation prompts, 169 commit or push prompts, 67 diagnosis prompts, and 28 explicit rollback requests;
  • plan -> implement appeared 130 times in a primary-action sequence classification;
  • the main source tree contained hundreds of focused systems, rules, content definitions, views, factories, registries, tests, and editor tools.

The counts are descriptive heuristics. Categories overlap, and the indexed conversation is a lower-bound subset of the full development history.

Architectural Shape​

The project combined:

  • ScriptableObject definitions, catalogs, and configuration;
  • a VContainer composition root;
  • an explicitly ordered game-loop runner;
  • plain runtime state and focused rules;
  • Unity views, factories, physics, particles, UI, and middleware adapters;
  • Content Workbench and Config Hub authoring surfaces;
  • Authoring Doctor and Verification Dashboard checks;
  • deterministic visual scenarios and fixed procedural review seeds;
  • permanent diagnostics for loading, traversal, and lifecycle behavior;
  • documentation and source-control checkpoints used as agent memory and recovery.

What Worked​

  • Domain vocabulary made code, UI, authoring tools, and discussions mutually searchable.
  • Config and content surfaces let the human tune outcomes without reopening implementation details.
  • Fixed seeds and visual scenarios converted random or transient failures into repeatable rehearsals.
  • Diagnostics broke long cycles of plausible but incorrect fixes.
  • Frequent checkpoints made ambitious experiments reversible.
  • Shared interaction, reward, lifecycle, audio, and UI patterns were deepened after real repetition appeared.

What Hurt​

  • Agents sometimes inferred engine state from source changes before Unity had compiled or settled.
  • Automated tests were occasionally treated as visual or experiential approval.
  • Several enemy traversal fixes were attempted before sufficient instrumentation existed, producing flying, sinking, and wall-penetration regressions.
  • Generated scene tooling overwrote manually arranged menu work until ownership rules were hardened.
  • Async orchestration initially hid synchronous Unity integration stalls.
  • Dependency-injection failures survived compilation and appeared only in composed Play Mode.
  • Wwise required end-to-end reasoning across authoring state, generated banks, Unity imports, and runtime events.
  • Repeated suffix patterns encouraged more files and abstractions than some changes needed.

Workflow Pattern​

The dominant loop was:

  1. the human described an outcome, observation, or reference;
  2. the agent inspected and proposed a plan;
  3. the human authorized implementation;
  4. the agent implemented and performed mechanical verification;
  5. the human playtested or reviewed screenshots;
  6. the result was tuned, diagnosed, reverted, or committed.

The human was not merely an approver. They supplied product direction, embodied playtest evidence, aesthetic judgment, priority, and rejection. The agent was not merely autocomplete. It mapped the codebase, proposed designs, implemented across tools, instrumented failures, and maintained project knowledge.

Distilled Lessons​

  1. Optimize for trustworthy accepted changes, not generated code volume.
  2. Treat human correction as valuable evidence to preserve in diagnostics, tests, or project guidance.
  3. Require engine-grounded rehearsal for engine-grounded claims.
  4. Protect hand-authored work explicitly.
  5. Instrument invisible systems before broad repair attempts.
  6. Use real-scale review surfaces for procedural and traversal systems.
  7. Make rollback ordinary and inexpensive.
  8. Introduce abstractions after repeated pressure, not before the first example.
  9. Keep current project phase and canonical documentation explicit.
  10. Distinguish mechanical verification from human acceptance.
  11. Treat video format and temporal evidence semantics separately: an MP4 made from exact state seeks does not prove ordinary runtime simulation.
  12. Keep camera, lighting, background, quality, and subject bindings under human-authored project configuration while agents automate execution and evidence handling.
  13. Describe native review capability without copying the game's content catalogs, and do not call an editor window agent-operable until subject selection, readiness, reset, and teardown have stable callable operations.
  14. Verify every advertised native entry point from a fresh session. Sharing a scene is not launch parity when only one route injects the profile, subject, or presentation state that makes it truthful.
  15. Use the smallest truthful engine-native review surface. Persist custom review UI only when it independently shortens a recurring player, authoring, or development loop enough to repay its ownership cost.
  16. Let infrastructure earn persistence through observed recurring cost. A validated helper that does not shorten the real human decision loop should be simplified or retired rather than expanded.
  17. Package the ordinary change-delivery loop before optional governance artifacts. Mapping, review infrastructure, and export should support game work rather than become the easiest visible definition of STAGE work.

Limits​

This remains one origin project, one primary human director, one engine, and a rapidly evolving generation of coding agents. Later external studies have tested mapping and operational semantics across other architectures, but they have not yet supplied independent controlled changes or longitudinal adoption. Correction cost, regression rate, accepted lead time, and maintenance overhead remain open evaluation targets.

Last updated on