Agentic Indie Game Development

Building a Tiny AI-Native Studio

Series: Metatransformer — Hacking on the Frontier
Edition: 0.1.0 Early Access
Evidence cutoff: August 29, 2026
Level: Advanced engineering
Executable reference path: Godot, with equivalent Unity and Unreal seams
Recurring project: Signal Fire, a coherent five-minute 3D vertical slice

Release state. The nine-chapter production argument, complete Signal Fire architecture, 30-day capstone, source notes, and glossary are present in this release. The Metatransformer website is the living Early Access edition; reviewed corrections, engine-specific updates, and web-native apparatus arrive there first. Leanpub is the numbered ebook release channel. Engine versions, model and provider behavior, community bridges, pricing, and terms may age quickly and must be checked against the evidence cutoff.

Currency warning. Model names, engine versions, provider terms, community bridges, prices, and even the vocabulary of agent systems change quickly. This book fixes its evidence at the date above. Treat named products as replaceable instances of interfaces. Before production use, re-check official documentation, provider terms, package versions, and security assumptions.

Preface: A game is an observed behavior, not a folder of generated files

A directory can contain scripts, meshes, textures, sounds, and a project descriptor while containing no playable game. A scene can parse and still strand the player behind a collider. A build can launch and still ignore the action key. A generated beacon can look impressive in an asset preview and become a dull gray speck after import. The difference between those artifacts and a game is observed behavior: a person supplies input, the running system changes state, and audiovisual feedback makes the change legible.

This distinction is the spine of the book. Agentic development does not mean asking a model to emit a game. It means building a controlled production system in which generative policies propose bounded changes, deterministic machinery applies and observes them, and a human creative director decides whether the resulting experience deserves to ship. The model may be surprisingly capable. It remains nondeterministic, fallible, and unable to confer meaning on a build merely by declaring success.

We will construct one small game all the way through. Signal Fire places the player in a compact stylized 3D relay station. The player traverses the space, collects three signal fragments, avoids or disables one patrol drone, and activates a beacon. The loop includes a title screen, restart flow, readable feedback, audio, a generated hero beacon, a generated family of environment props, instrumentation, tests, and a desktop export. Five minutes is long enough to expose interaction, presentation, content, tooling, and release failures, yet short enough that we can reason about every important seam.

The book is skeptical of “one prompt makes a game” because that phrase hides the actual work: choosing a contract, assigning authority, preserving state, normalizing assets, controlling an engine process, testing runtime behavior, and exercising taste. It is optimistic about leverage because each of those activities can be made more inspectable and more automatable.

Reader contract and prerequisites

You should already be comfortable with repositories, build systems, typed APIs, tests, game-engine concepts, and basic 3D asset terminology. We assume the companion Agentic Engineering vocabulary: a session is durable event history and task identity; a harness is the controller around a model policy; an environment contains the stateful systems tools may change; an action requests a state transition; an observation reports what happened; and a verifier evaluates the resulting environment state. We restate a term only when game production gives it a sharper meaning.

By the end, you should be able to:

1. decompose a game-development agent into replaceable, least-privileged components;
2. map the same automation needs onto Godot, Unity, and Unreal without confusing product-specific surfaces with architecture;
3. carry code, scenes, generated assets, runtime observations, and release evidence through auditable pipelines;
4. diagnose the class of failures that compile and launch checks cannot see; and
5. produce a playable Signal Fire build and an evidence packet that supports, but does not overstate, its readiness.

This is not a complete course in engine programming, art, animation, legal review, publishing, or game design. It shows how those disciplines connect inside an agentic production system. The human creative director remains a working component at every stage, not a ceremonial disclaimer added after automation.

Global architecture map

Figure F.1 — The tiny studio as an authority graph. This is an author-derived production architecture, not a diagram reproduced from a source.

flowchart TD
    H[Human creative director\nintent, taste, scope, ship] -->|acceptance rubric and decisions| L[Lead harness\ntask graph, state, policy, budgets]
    L -->|bounded file task| R[Repository worker\nisolated branch or worktree]
    L -->|typed engine command| E[Engine adapter\neditor, runtime, capture, build]
    L -->|asset specification| A[Asset broker\nprovider calls, raw manifests]
    A -->|quarantined artifacts| D[DCC normalization\ngeometry, UV, materials, scale, LOD]
    D -->|validated interchange asset| E
    R -->|authorized project changes| E
    E -->|logs, state, media, builds| V[Verifier stack\nsyntax through human playtest]
    V -->|evidence and failures| L
    V -->|playable candidate and evidence| H
    H -->|approve, revise, or stop| L

Read the arrows as grants of responsibility, not as a chronology. The creative director defines why the game exists and judges whether it communicates. The lead harness turns that intent into dependencies, permissions, budgets, checkpoints, and evidence requirements. A repository worker may edit only authorized text, code, and configuration in isolation. It does not secretly manipulate a live editor. The engine adapter owns imports, editor operations, play mode, injected input, runtime observation, capture, tests, and builds. The asset broker may call providers and record raw outputs, but it cannot place them into the shipping project. DCC normalization makes external artifacts fit the studio's geometric and material contracts. The verifier stack grades environment state at increasing levels of cost. No generative component decides that its own output is shippable.

Signal Fire acceptance rubric and production constraints

The slice has a deliberately narrow observable contract. It is complete when a clean desktop build lets a new player start from a title screen, move through one compact level, understand the fragment objective, collect exactly three fragments, encounter one patrol drone, avoid or disable it through the documented interaction, activate the beacon only after all fragments are collected, receive coherent visual and audio feedback, reach a completion state, and restart without stale state.

Table F.1 — Acceptance rubric. Values below are project constraints chosen for this book, not benchmark results.

Production constraints keep the problem honest. There is one level, one player controller, three fixed fragment locations, one drone, one beacon, and one desktop target. There is no inventory, procedural map, online multiplayer, dialogue tree, save slot, live service, marketplace, or open world. The art direction is stylized industrial twilight: broad readable silhouettes, a cool environment, warm signal energy, restrained surface detail. We allow gray-box primitives while mechanics are unstable, then replace only the hero beacon and a modular prop family through the generated-asset supply chain. The human creative director owns any change to those constraints.

01Chapter 1What Counts as a Finished Vertical Slice?

Opening production question: What evidence lets us call Signal Fire a playable vertical slice rather than a generated project that happens to open?

Chapter thesis: Completion is a player-observable contract evaluated by a stack of imperfect verifiers. Artifact presence, parsing, and launchability are necessary lower layers; none establishes coherent interaction, presentation, performance, or taste.

1.1 From artifact completion to engine-grounded behavior

Game tasks combine code, serialized scenes, spatial layout, timing, physics, inputs, audio, and perceptual feedback. Recent benchmarks make that combination visible. GameDevBench constructs multimodal game-development tasks and reports lower success on graphics-heavy work under its studied setup. GameCraft-Bench evaluates engine grounding, artifact completeness, replayed interaction, and multimodal judgments. JAMER uses project-level Godot code tasks with deterministic verification. These are A-class empirical sources, but they are new, concentrated in particular engines and task distributions, and do not demonstrate autonomous commercial production.

Their useful lesson is structural. A verifier must ask progressively stronger questions:

1. Are the expected artifacts present?
2. Can the engine import and parse them?
3. Does the project launch under strict conditions?
4. Does a controlled interaction trace cause the required state transitions?
5. Are those transitions perceptually legible?
6. Does the complete experience satisfy a human taste and ship gate?

The Verifier is the Curriculum reports that a strict headless launch gate can provide useful, narrow execution grounding. Its limit is in the adjective narrow: launch is a prerequisite, not a surrogate for play.

Figure 1.1 — The completion ladder. Each higher layer depends on the lower one and makes a stronger, still bounded claim.

flowchart BT
    A[Artifacts exist] -->|engine reads| B[Import and parse]
    B -->|process starts cleanly| C[Strict launch]
    C -->|inputs change expected state| D[Deterministic interaction]
    D -->|feedback is visible and audible| E[Multimodal coherence]
    E -->|frame, accessibility, stability budgets hold| F[Production fitness]
    F -->|creative director accepts experience| G[Ship decision]

The arrows mean “is required by,” not “proves.” A build at level C says nothing by itself about the three fragments. A level-D scenario may still overlook unreadable lighting. A favorable model-based visual grade at level E may share the generator's preferences. The top remains a human decision informed by the stack.

1.2 The player-observable contract

A vertical slice is not a sample of every planned feature. It is a short, representative path through the intended quality bar. For Signal Fire, the contract is expressed as observable transitions rather than implementation nouns:

TITLE --start--> PLAYING(fragment_count=0, drone=patrolling)
PLAYING --collect valid fragment--> PLAYING(fragment_count += 1)
PLAYING --disable drone under valid condition--> PLAYING(drone=disabled)
PLAYING(count < 3) --activate beacon--> PLAYING + blocked feedback
PLAYING(count = 3) --activate beacon--> COMPLETE + finale feedback
COMPLETE --restart--> TITLE with all transient state reset

This state machine deliberately leaves room for engine-specific implementations. A Godot signal, Unity event, or Unreal gameplay message may carry the collection transition. The contract cares that exactly one valid pickup advances the count, that an early activation is rejected legibly, and that restart restores initial state.

The non-goals prevent apparently helpful generation from diluting the test. There is no fourth fragment, randomized placement, second enemy, upgrade screen, lore system, or alternate ending. A proposal that adds one must return to the creative director as a scope decision. It cannot slip in under “polish.”

1.3 Budgets and the evidence packet

“Runs on my machine” conceals the execution conditions. The performance budget therefore names its reference: 1920×1080, a declared desktop machine and graphics API, release-like settings, a scripted five-minute route, a 60-frames-per-second target, no sustained interval below 45, bounded memory growth, and no error-level logs. These are local acceptance thresholds, not claims about all supported hardware.

The evidence packet binds claims to artifacts:

release_candidate: signal-fire-0.1.0-rc3
source_revision: <git-commit>
engine:
  product: Godot
  version: <pinned-version>
build:
  platform: desktop
  artifact_sha256: <hash>
scenarios:
  - id: happy_path_v3
    seed: 4103
    result: pass
    trace_uri: evidence/traces/happy_path_v3.jsonl
captures:
  screenshots: [title, fragment_feedback, drone_encounter, finale]
  video: evidence/video/full_route.mp4
performance:
  reference_machine: <machine-id>
  frame_report: evidence/perf/route.json
assets:
  manifest: evidence/assets/approved.json
human_gate:
  reviewer: <creative-director-id>
  decision: approve | revise | reject
  rationale: <short-record>

The packet does not make a build good. It makes the reasons for a decision inspectable. Hashes connect evidence to a precise candidate. Seeds and trace IDs make deterministic scenarios repeatable. Captures expose what numeric assertions omit. The human record prevents taste from disappearing into an untraceable thumbs-up.

1.4 Worked trace: the build that “passed”

Consider candidate rc1. The repository worker reports that all expected files exist. The Godot adapter imports the project without error and performs a strict headless launch. The process stays alive for ten seconds and exits cleanly. A weak pipeline marks the task complete.

The gameplay verifier then runs an author-constructed trace. At t=0, it starts a fresh profile. At t=8.2 s, injected movement enters fragment trigger A. Telemetry reports fragment_count: 1, yet the fragment remains visible. At t=8.3 s, the player is still overlapping the trigger; a second body callback fires and reports fragment_count: 2. The same object reaches count three before the player sees the rest of the level. Beacon activation succeeds at t=14.0 s.

The lower checks were accurate: files existed, imports succeeded, and the project launched. They simply measured the wrong proposition. The fix is not “make the test stricter” in the abstract. It is to state the invariant: each fragment identity may contribute at most once, and the visible pickup must become unavailable in the same accepted transition. A verifier records the collected-ID set and fails on duplicate admission.

Decision record 1.1

1.5 What this does not prove

Passing the rubric does not prove that Signal Fire is fun, commercially viable, accessible to every player, portable to every desktop, free of defects, or representative of a full game. The benchmark evidence does not prove that one verifier design is optimal. A deterministic scenario certifies only the path and assertions it covers; a multimodal model can reward generic polish or share blind spots with the generator; a human gate can be inconsistent. We use overlapping checks because their failure modes differ, not because their union becomes certainty.

Godot, Unity, and Unreal can all express this observable contract. Godot's text-oriented project and headless command line make the reference architecture easy to inspect. Unity supplies batch editor execution and its Test Framework; Unreal supplies Automation Tool, the Automation Test Framework, and Gauntlet. The completion ladder stays stable while the adapter implementation changes.

1.6 Chapter summary and apparatus

Signal Fire now has fixed mechanics, non-goals, budgets, an evidence packet, and a human gate. Completion means a clean candidate produced the required behavior under declared conditions and survived creative review. In Chapter 2 we build the control system that can move this contract through production.

Review questions

1. Why can a strict launch gate be both useful and insufficient?
2. Which Signal Fire invariant catches duplicate trigger callbacks?
3. What claim can a deterministic happy-path replay support, and what can it not support?
4. Why is the creative director part of the architecture rather than an informal final check?

Design problems

1. Diagnosis. A build records three unique fragment IDs but shows 2/3 on the HUD. Locate at least two possible broken seams and name an observation that distinguishes them.
2. Falsification. Design one scenario that could disconfirm the claim that restart restores all transient state. Include initial state, inputs, observation, and decision rule.

Implementation lab 1 — Executable acceptance probe. Create a machine-readable acceptance file for the six state transitions above and a validator that rejects duplicate fragment IDs and early beacon success. Pass: the validator accepts one valid trace and rejects fixtures for duplicate collection, early activation, and dirty restart, with distinct errors. Fail: it infers success from file presence, process exit alone, or free-form model commentary.

Source notes. GameDevBench, GameCraft-Bench, JAMER, and The Verifier is the Curriculum are A-class primary empirical evidence for bounded benchmark and verifier observations. The layered completion model and Signal Fire rubric are author synthesis. Their biggest limit is that benchmark task success is not a product-reliability estimate.

02Chapter 2The Tiny AI-Native Studio as a Control System

Opening production question: Which component is allowed to change what, and how does a five-minute game survive nondeterministic proposals without turning production into nondeterministic state?

Chapter thesis: A tiny AI-native studio is a feedback controller with deterministic and generative lanes. Durable state, explicit authority, engine mediation, verification, and human checkpoints turn model proposals into governed production changes.

2.1 The complete architecture before the tool names

The useful unit is not “model plus game engine.” It is session plus lead harness plus environments plus model policy. The session preserves task identity and events. The harness computes context, requests a proposal, validates actions, routes them, records observations, and decides whether to continue. Environments include the repository, engine process, external asset store, DCC tool, build output, and people. The model policy proposes actions from its current bounded view.

For game production, this general decomposition becomes seven roles. The creative director owns intent, taste, scope, and shipping. The lead harness owns the task graph, policy, budgets, integration, and evidence. The repository worker owns authorized text files in an isolated branch or worktree. The engine adapter owns stateful engine operations. The asset broker owns provider calls and raw manifests. DCC normalization owns asset fitness. The verifier stack owns layered claims.

This role split remains useful when one person runs every process. Roles define authority and interfaces; they do not require seven models or seven employees.

2.2 Deterministic and generative lanes

Generative policies are valuable where the space is large and judgment-rich: proposing a scene composition, diagnosing an unfamiliar error, writing a bounded script change, generating a mesh candidate, or suggesting a test. Deterministic machinery should own what can be stated exactly: file allowlists, schema validation, hashes, import commands, budget arithmetic, state transitions, build invocation, and release admission.

Figure 2.1 — Dual-lane production loop. The generative lane proposes; the deterministic lane mediates and measures.

flowchart LR
    I[Creative intent] -->|constrains| G[Generative lane\nplan, code, layout, diagnosis, candidates]
    G -->|structured proposal| P[Policy and schema gate]
    P -->|authorized command| D[Deterministic lane\nrepo, imports, builds, budgets, logs]
    D -->|environment state| O[Observation normalizer]
    O -->|bounded evidence| G
    O -->|verification report| H[Human checkpoint]
    H -->|revise scope or accept| I

The key boundary is between proposal and mutation. A model may suggest removing a collider; the policy gate checks file ownership and risk; the engine adapter performs the supported operation on the engine's required thread; the observation reports the changed scene and runtime consequence. “The model decided” is never an implementation detail.

Containment is more dependable than asking a model to remember its permissions. OpenHands Software Agent SDK, Scaling Managed Agents, and Inspect sandboxing support the general pattern of separating agent control from isolated execution, while their specific systems and threat models differ. Containers still leave mounts, credentials, egress, caches, and host services to configure.

2.3 The task dependency graph and ownership

The harness converts the acceptance rubric into a directed acyclic graph. Dependencies represent real production constraints. The beacon cannot be verified before the fragment state exists. Final art should not be normalized against an unstable scale convention. Export evidence should not be collected before the candidate revision is frozen.

task_id: SF-MECH-030
title: Gate beacon activation on three unique fragments
depends_on: [SF-MECH-020]
owner_role: repository_worker
allowed_paths:
  - game/beacon_controller.gd
  - tests/beacon_scenario.gd
engine_commands:
  - import_project
  - run_scenario:beacon_gate
preconditions:
  source_revision: <hash>
  fragment_contract_version: 2
postconditions:
  - early_activation_rejected
  - activation_at_three_completes
budgets:
  model_tokens: 18000
  wall_minutes: 25
  provider_credits: 0
rollback: discard_worktree
human_gate: false

The schema connects intent to enforceable bounds. depends_on prevents premature work. allowed_paths limits repository mutation. engine_commands grants only required capabilities. Preconditions reject stale work. Postconditions define success in environment terms. Budgets limit runaway retries. Rollback names a recovery method before mutation.

Figure 2.2 — Signal Fire dependency graph. Shared hubs stay serial; independent supply-chain work branches only after its specification is fixed.

flowchart TD
    A[Acceptance contract] --> B[Boot shell]
    B --> C[Traversal]
    C --> D[Fragment identity and count]
    D --> E[Drone encounter]
    D --> F[Beacon gate and finale]
    D --> G[HUD and audio feedback]
    A --> H[Art bible and scale contract]
    H --> I[Beacon raw generation]
    H --> J[Prop-family raw generation]
    I --> K[DCC normalize]
    J --> K
    E --> L[Integrated scenario]
    F --> L
    G --> L
    K --> L
    L --> M[Verification packet]
    M --> N[Human ship gate]

Drone logic, beacon logic, and feedback may proceed in isolated files after the fragment contract stabilizes. They must not independently rewrite the main scene. Integration owns that shared hub. This is an ownership rule, not a request for agents to coordinate politely.

2.4 Three environments, three truths

Game production has at least three materially different environments.

The workspace contains source files and deterministic transformations. It can reveal diffs, schemas, hashes, and static test results. The live editor contains imported resources, caches, selections, unsaved scene state, domain or script reload state, and main-thread-only APIs. The exported runtime contains the actual packaged resources, platform settings, input mapping, rendering backend, and release behavior.

A file edit may be correct in the workspace yet absent from a stale editor. A scene may work in editor play mode but fail in export because an asset was not included. A build may behave differently because editor-only helpers are missing. Therefore every engine command names its target environment.

{
  "command_id": "cmd-8f31",
  "operation": "run_scenario",
  "target": "exported_runtime",
  "project_revision": "9f2c...",
  "scenario": "happy_path_v3",
  "seed": 4103,
  "timeout_ms": 90000,
  "capture": ["telemetry", "logs", "screenshots"]
}

The command is rejected if the build hash does not correspond to project_revision. That single precondition prevents an agent from interpreting evidence from yesterday's binary as evidence for today's patch.

2.5 Worked trace: admitting the first production task

The creative director approves the initial contract and art direction. The lead harness reduces them into task SF-BOOT-010: produce a bootable gray-box shell with title, start action, level root, and restart placeholder. The task permits project configuration, one bootstrap scene, and one smoke test; it permits no network and no asset-provider calls.

At event 1, the session records the task and base revision. At event 2, the repository worker inspects only allowed paths. At event 3, the model proposes a bounded patch. At event 4, deterministic policy rejects an attempted edit to the future art manifest because it lies outside the allowlist. The worker revises. At event 5, the patch applies in the isolated worktree. At event 6, the engine adapter imports and launches. At event 7, runtime telemetry reports mode=TITLE. Injected start changes it to PLAYING. At event 8, a screenshot confirms a camera renders the gray-box level. At event 9, the verifier records pass with the exact revision. The creative director does not review art because the task has no art claim.

Counterfactual: if the launch observation came from a live editor with unsaved state, the harness would reject it because the task requires a clean headless process. The process boundary is part of the evidence.

2.6 What this does not prove

The control-system architecture does not make model outputs deterministic, guarantee security, eliminate integration work, or prove that more instrumentation creates better games. It moves production invariants into components that can enforce and observe them. Poor task decomposition can still produce locally correct pieces that do not compose. Excessive gates can make a tiny project uneconomic. Human checkpoints can become approval theater unless they are tied to genuine product decisions.

Godot's inspectable text files favor repository-first work. Unity often needs a stronger live-editor and batchmode bridge because serialization, imports, and domain reloads affect truth. Unreal's asset-heavy workflows place more authority in editor automation, cooking, and runtime test orchestration. The same roles apply, but their boundaries carry different operational weight.

2.7 Chapter summary and apparatus

Signal Fire now has a complete studio topology, deterministic and generative lanes, a dependency graph, an enforceable task schema, and explicit workspace/editor/runtime environments. Chapter 3 maps the engine adapter onto real automation surfaces and boots the reference project.

Review questions

1. Why are roles useful even in a one-person studio?
2. Which facts belong to the deterministic lane, and which proposals benefit from a generative lane?
3. Why must an engine command name its target environment and source revision?
4. Which Signal Fire tasks can branch after the fragment contract, and which shared work must remain serial?

Design problems

1. Authority design. Specify minimal permissions for a task that adjusts the drone patrol route but may not change player movement or main-scene ownership.
2. Recovery design. A live-editor operation times out after partially placing nodes. Define the observations needed to choose retry, rollback, or human escalation.

Implementation lab 2 — Task admission controller. Implement validation for the task schema above, including dependency completion, closed path allowlists, budget presence, base-revision match, and rollback declaration. Pass: malformed, stale, overbroad, and dependency-blocked tasks fail before any mutation; a valid boot task emits an immutable admission record. Fail: policy exists only in prompt prose or is checked after edits.

Source notes. The agent-system decomposition is author synthesis supported by SWE-agent (A), OpenHands SDK (A/B), Managed Agents (B), and Inspect documentation (C). The Signal Fire task graph and role allocation are constructed production designs. No cited system establishes that this exact studio topology is optimal.

03Chapter 3Choosing and Automating the Engine Surface

Opening production question: Which engine operations belong in files, a headless process, a live editor, a controlled runtime, or a platform build?

Chapter thesis: Choose an engine by the production surface the game and team need, then isolate that surface behind an adapter. Godot, Unity, and Unreal offer serious but different automation seams; none is universally best.

3.1 Five operations that should not be conflated

An engine adapter spans five categories:

1. File edits change source scripts, text scenes where supported, configuration, tests, and manifests.
2. Headless operations import, parse, compile, run tool scripts, execute tests, and sometimes render without an interactive window.
3. Live-editor operations manipulate state that exists inside the editor, including scene selections, imported assets, editor-only APIs, and unsaved documents.
4. Runtime control launches play mode or a packaged process, injects input, observes gameplay state, and captures frames.
5. Platform builds resolve export settings, cook or package content, sign where required, and produce distributable artifacts.

The categories may share a binary but do not share guarantees. “The CLI can launch the editor” does not imply it can safely alter a scene while the UI is busy. “Python can script the editor” does not imply it controls packaged gameplay. A sound adapter exposes the distinction in its types.

type EngineTarget = "workspace" | "headless_editor" | "live_editor" | "play_mode" | "exported_runtime";

type EngineCommand = {
  id: string;
  target: EngineTarget;
  operation: "import" | "compile" | "scene_patch" | "launch" | "inject_input" | "observe" | "test" | "build";
  revision: string;
  deadlineMs: number;
  expectedPreState?: string;
  idempotencyKey?: string;
};

3.2 Equivalent seams across Godot, Unity, and Unreal

The Godot command-line documentation describes headless execution, project import and parsing, scripts, export, benchmarks, and tests. Godot editor plugins and import plugins extend the live editor and asset pipeline. Godot scenes and resources are often text-oriented, which makes many project changes diffable. That is an advantage for this book, not a universal verdict on engine capability.

Unity supports command-line editor operation and scripted methods through its Editor command-line arguments. The Unity Test Framework supports edit-mode and play-mode workflows. Unity production automation must account for import state, serialized assets, assembly compilation, and domain reload. A batch invocation that begins during an editor lock or reads a stale Library state needs an explicit failure classification.

Unreal separates several powerful surfaces. Unreal Python automates editor activities. Automation Tool drives unattended build, cook, and run workflows. The Automation Test Framework supplies engine tests and screenshot comparison, while Gauntlet orchestrates runtime sessions and test controllers. Blueprint and binary asset ownership make isolated editor sandboxes and integration discipline especially important.

Table 3.1 — Equivalent architectural seams, not a feature ranking.

3.3 The local Godot reference architecture

Figure 3.1 — Complete local Godot loop. This is the first required reference architecture.

flowchart TD
    B[Brief and acceptance YAML] --> T[Lead task ledger]
    T --> W[Git worktree\nclosed file allowlist]
    W --> C[Godot CLI adapter\nimport, parse, test]
    C -->|bootable revision| R[Scenario runtime\ninput actions + telemetry]
    R --> O[Logs, state snapshots, screenshots, video]
    O --> V[Deterministic verifiers]
    V -->|failure with evidence| T
    V -->|candidate| M[Separate visual/playability review]
    M -->|revise| T
    M -->|accept| H[Human creative gate]
    H --> X[Desktop export + manifest]

The local loop keeps the default path simple. Repository edits happen in a worktree. Each verification run starts a fresh engine process against a pinned project revision. The scenario runner translates abstract actions such as move_forward and interact into the project's Input Map. Instrumentation emits stable gameplay events rather than exposing arbitrary internal objects. Captures and telemetry return through an observation normalizer. The creative director sees the playable candidate and the same evidence identifiers as the harness.

We introduce a live editor only for operations whose value exceeds their lifecycle cost: inspecting an import, manipulating an editor-only resource, or capturing a specific diagnostic. The default is CLI first because clean-process evidence is easier to reason about.

3.4 Worked implementation trace: the first bootable shell

The boot shell contains a bootstrap scene with a mode controller, a title layer, and a level root containing a camera, light, ground plane, collision boundary, and placeholder player spawn. It contains no fragments, drone, or final art.

The repository worker creates text resources within the task allowlist. The adapter invokes a clean import. Parse errors are normalized to file, line, engine code, and stderr excerpt. On success it launches the project with a test flag and a telemetry sink. The process reports:

{"seq":1,"time_ms":0,"event":"boot","revision":"9f2c...","mode":"TITLE"}
{"seq":2,"time_ms":318,"event":"frame_ready","viewport":[1920,1080]}
{"seq":3,"time_ms":512,"event":"input","action":"start","pressed":true}
{"seq":4,"time_ms":530,"event":"mode_changed","from":"TITLE","to":"PLAYING"}
{"seq":5,"time_ms":611,"event":"player_spawned","spawn_id":"start","position":[0,1,0]}

The verifier requires ordered sequence numbers, the candidate revision, a title-to-playing transition after input, and a valid spawn inside the navigation bounds. A screenshot is attached to event 4. The shell passes without claiming that traversal feels good or that the gray box satisfies the art direction.

In Unity, the equivalent task would use a bootstrap scene, an editor or batch entry point, Input System actions, play-mode instrumentation, and a build-pipeline method. In Unreal it would use a minimal map and game mode, automation entry points, an input abstraction, runtime telemetry or a Gauntlet controller, and later cooking. The behavioral trace stays nearly identical; only the adapter and project artifacts differ.

3.5 Lifecycle failures and adapter policy

An adapter needs error categories that drive recovery:

Hot reload is convenient for humans but dangerous as evidence. It can preserve old objects, mix new code with old scene state, or break a connection during reload. Production checks prefer a clean launch. Live iteration may use reload for speed, but the trace must label it and final verification must reset the process.

3.6 What this does not prove

A text-oriented format does not make every Godot scene safe for unconstrained text generation. Unity batchmode does not eliminate the editor lifecycle. Unreal Python does not replace C++, Blueprints, cooking, or runtime automation. Official automation support describes capabilities for named products and versions; it does not guarantee that an arbitrary agent will use them correctly.

Engine choice also depends on rendering goals, platform support, team expertise, ecosystem, source access, licensing, and content scale. Signal Fire uses Godot because inspectability and a CLI-first loop serve this textbook. A team with a mature Unity pipeline or an Unreal-specific visual target may rationally choose differently.

3.7 Chapter summary and apparatus

Signal Fire now boots from a clean Godot process, transitions from title to play, emits revision-bound telemetry, and has an adapter model that transfers to Unity and Unreal. Chapter 4 designs the typed tool surface that lets a harness use this adapter without exposing the entire editor by default.

Review questions

1. Why must file editing, headless work, live-editor work, runtime control, and builds remain distinct adapter targets?
2. Which Unity lifecycle event commonly invalidates an agent connection or cached state?
3. How do Unreal Automation Tool, the Automation Test Framework, Gauntlet, and Python occupy different seams?
4. What exactly does the boot-shell trace establish?

Design problems

1. Comparison. Choose an engine surface for a team whose game relies on heavy Blueprint content and console builds. Map each Signal Fire adapter need without claiming the choice is universal.
2. Failure recovery. Design a retry policy for EDITOR_BUSY that cannot accidentally duplicate a non-idempotent scene operation.

Implementation lab 3 — Boot adapter. Implement an adapter command that imports a clean project, launches the shell, injects start, captures the five observation types shown above, and stops the process. Pass: evidence is tied to the requested revision; stale revision, parse failure, missing telemetry, and timeout are distinct failures. Fail: it accepts an already-open editor or considers process survival sufficient.

Source notes. Godot, Unity, and Unreal capability statements come from C-class official documentation linked in Section 3.2. The comparison table and local loop are author synthesis. Documentation establishes available surfaces, not comparative productivity, safety, or fitness for every project.

04Chapter 4MCP and Tool Design for Game Engines

Opening production question: What is the smallest engine-tool interface that lets the harness build and observe Signal Fire without granting an opaque model the authority of an unrestricted editor console?

Chapter thesis: A protocol can connect a harness to an engine, but reliability comes from tool semantics, lifecycle control, permissions, and observations. Prefer a small typed surface with explicit contracts; isolate arbitrary code execution as a dangerous escape hatch.

4.1 Connection is not architecture

The Model Context Protocol specification defines an architecture in which a host manages clients connected to servers that can expose tools, resources, prompts, and related capabilities. In our studio, the lead harness is part of the host-side application, an engine adapter may be exposed through an MCP server, and a client manages that connection. This is a C-class protocol description.

MCP does not guarantee that a tool is useful, safe, deterministic, idempotent, reversible, performant, or correctly authorized. It does not choose tools, establish gameplay semantics, repair a Unity domain reload, marshal an Unreal operation to the game thread, or decide whether a screenshot shows a readable encounter. Those remain harness, adapter, verifier, and human responsibilities.

That boundary prevents a common category error. “The engine supports MCP” would imply an official engine standard and stable semantics. At the evidence cutoff, community engine bridges are E-class implementations—valuable experiments, not blanket recommendations or vendor standards.

4.2 A small Signal Fire tool suite

Tool design defines the model's effective action and observation spaces. SWE-agent demonstrates that an agent-computer interface can materially change software-agent performance in its evaluated setting. Production guidance on writing effective tools for agents argues for distinct, self-contained, token-efficient tools. Neither source says that this exact game-engine suite is optimal; the suite is our production design.

Table 4.1 — Stable tool profile.

The suite avoids exposing hundreds of editor methods. Tool profiles can expand temporarily: the asset-import task may enable asset.inspect_import and asset.configure_import, while a gameplay test task enables runtime tools. Dynamic profiles reduce discovery noise and authority, provided the harness records which profile governed each trace.

4.3 Contracts, errors, and rollback

A tool call is a state-transition request, not a natural-language wish. Its schema should contain enough information to reject ambiguity before mutation.

{
  "tool": "scene.apply_patch",
  "request_id": "req-4421",
  "idempotency_key": "SF-INTEG-110/place-beacon/v2",
  "project_revision": "9f2c...",
  "scene": "res://game/main.tscn",
  "expected_scene_fingerprint": "sha256:ab71...",
  "operations": [
    {
      "op": "add_instance",
      "parent_path": "World/Objective",
      "resource": "res://art/approved/beacon.glb",
      "node_name": "BeaconVisual"
    }
  ],
  "snapshot_before": true
}

Preconditions include source and scene fingerprints, editor readiness, and resource approval. Postconditions include a saved scene, exactly one new node at the expected path, resolvable resource references, and a fresh fingerprint. Errors are typed: invalid input is not retryable; stale state requires re-inspection; editor busy may permit bounded retry; partial mutation requires rollback and verification; lost connection produces an unknown outcome until post-state inspection.

Idempotency is operation-specific. A set_property operation can often converge on the same value. An add_instance call can duplicate content if retried after the response is lost. The idempotency key lets the server return the recorded outcome or report that the prior result must be inspected. Rollback is also operation-specific: an inverse patch may work for simple property changes, while a scene snapshot or disposable worktree is safer for compound editor scripting.

Figure 4.1 — A stateful tool transaction. Lost responses lead to inspection, never blind replay.

sequenceDiagram
    participant H as Lead harness
    participant S as Engine server
    participant M as Main-thread queue
    participant E as Editor state
    H->>S: typed request + revision + idempotency key
    S->>S: validate schema, authority, preconditions
    S->>M: enqueue supported operation
    M->>E: inspect then mutate on main thread
    E-->>M: post-state + fingerprint
    M-->>S: structured result
    alt response delivered
        S-->>H: result + observation IDs
    else connection lost
        H->>S: inspect idempotency key and post-state
        S-->>H: committed | rolled back | unknown
    end

4.4 Main-thread marshaling and connection lifecycle

Exact safety warning: Do not call editor, scene-tree, object-lifecycle, rendering, physics, or game-state APIs from a background transport thread unless the named engine API explicitly documents that operation as thread-safe. Receive and validate requests off-thread if useful, then marshal stateful engine work to the editor or game main thread. A timeout does not prove that the operation did not occur.

This rule matters across engines even though the APIs differ. A Godot plugin may defer work onto the main loop. Unity editor code must respect editor callbacks, compilation, and domain reload; a reload can destroy connection objects and invalidate cached references. Unreal editor and runtime operations often require the game thread, and Python availability does not waive object-lifetime rules.

The server exposes lifecycle states such as CONNECTING, READY, BUSY, RELOADING, PLAYING, DISCONNECTED, and RECOVERING. Every tool declares allowed states. After a Unity domain reload or an Unreal map transition, the client re-handshakes, negotiates schema version, and re-inspects current state. It never assumes that a socket's survival implies semantic continuity.

4.5 The execute-code escape hatch

Dedicated tools cover frequent, well-understood transitions. An escape hatch executes a supplied GDScript editor script, C# editor method, Unreal Python fragment, Blueprint operation, C++ utility, or shell command when the stable surface cannot express the task.

Exact authority warning: Arbitrary code execution inside an editor inherits the editor process's filesystem, project, credential, plugin, and network authority unless the environment restricts them. It can mutate unsaved scenes, imported assets, caches, user settings, and external services beyond the visible code diff. Treat it as high risk: use a disposable branch or sandbox, deny unnecessary network and credentials, require a closed scope, capture pre-state, impose time and output limits, inspect post-state, and run the verifier stack before integration.

An escape request includes purpose, language, complete code, allowed resource paths, maximum runtime, expected mutations, snapshot ID, and reviewer policy. It is disabled in the default profile. It cannot be made safe merely by asking the model not to do harm.

Community examples illustrate design choices without settling them. Triforge Godot MCP, HybridIndie Godot MCP, Coplay Unity MCP, x0cipher Unreal MCP, and GenOrca Unreal MCP are E-class projects. They may demonstrate live-editor tools, code execution, screenshots, play-mode control, dynamic profiles, or thread marshaling. Pin and inspect the exact commit used in a lab. Do not infer affiliation, current safety, or compatibility from inclusion here.

4.6 Worked failure injection: the duplicated beacon

The integration task calls scene.apply_patch to place the approved beacon. The editor performs the operation and saves, but the connection drops before the response reaches the harness. A naive client retries. The main scene now has BeaconVisual and BeaconVisual2; both run finale particles, doubling the performance cost.

The correct trace uses idempotency key SF-INTEG-110/place-beacon/v2. After the timeout, the harness queries the key. If the server's transaction record survived, it returns the committed result. If not, project.inspect and a read-only scene query locate nodes with the task's stable placement tag. One matching node means observe and continue; zero means retry from the snapshot; more than one means stop, restore the snapshot, and report a postcondition violation. The harness never asks a vision model to judge whether “there seems to be one beacon.”

Unity and Unreal require the same outcome discipline even if the duplicate appears as a prefab instance or actor in a binary asset. The rollback mechanism may be version-control asset restore in an isolated workspace rather than a text inverse patch.

4.7 What this does not prove, summary, and apparatus

A well-designed MCP server does not prove that a model will select the right tool, that an editor is safe to automate, or that every transition can be made transactional. Fewer tools can still be poorly designed. More typed tools can become an expensive compatibility layer. MCP interoperability does not establish engine semantics.

Signal Fire now has a bounded tool profile, typed commands, lifecycle states, main-thread policy, idempotency behavior, and a quarantined escape hatch. Chapter 5 uses those tools to implement the actual loop one mechanic at a time.

Review questions

1. What does MCP standardize, and which responsibilities remain outside the protocol?
2. Why is a timeout after an editor mutation an unknown outcome rather than a failure?
3. Which runtime input operations are unsafe to retry blindly?
4. Why must arbitrary editor code execution be isolated even when the code is visible?

Design problems

1. Tool contract. Specify preconditions, postconditions, errors, idempotency, and rollback for asset.configure_import.
2. Profile design. Give the minimal temporary tool profile for tuning drone detection in play mode, and justify each permission.

Implementation lab 4 — Transactional mock engine. Build a mock scene.apply_patch server that simulates a lost response after commit. Pass: a retry with the same key cannot duplicate the node, unknown outcomes trigger inspection, and main-thread-required requests are queued. Fail: timeout causes immediate replay or a background thread mutates scene state.

Source notes. MCP and official engine APIs are C-class interface evidence. SWE-agent is A-class evidence that interface design mattered in its setup; Anthropic's tool article is B-class production guidance. All named community bridges are E-class, volatile, and not official standards. The Signal Fire suite is author synthesis.

05Chapter 5The Code–Scene Iteration Loop

Opening production question: How does an agent add one mechanic without confusing a plausible code patch with a working change in a stateful game?

Chapter thesis: Productive iteration is a closed loop: inspect, plan a bounded change, edit, import or compile, launch, drive input, observe state, verify, and checkpoint. Mechanics enter in dependency order, with explicit scene ownership and test seams.

5.1 One mechanic, one observable delta

The loop begins from a known revision and an unambiguous failing observation. The worker inspects the smallest relevant code, scene, test, telemetry schema, and recent trace. It proposes a change bounded by file ownership. The repository mutation is deterministic and diffable. The engine adapter imports or compiles in a clean enough environment to invalidate stale assumptions. A scenario launches, drives named inputs, and observes structured state plus media. A verifier compares postconditions and invariants. Only a passing, reviewable increment becomes a checkpoint.

Figure 5.1 — The mechanic transaction loop. A code diff does not reach “done” without passing through the engine and runtime.

flowchart LR
    O[Inspect known revision\nand failing evidence] --> P[Plan one bounded delta]
    P --> E[Edit owned files]
    E --> C[Import / compile]
    C -->|error| O
    C --> L[Clean launch]
    L --> I[Drive named input]
    I --> S[Observe telemetry, logs, frame]
    S --> V[Verify contract and invariants]
    V -->|fail with trace| O
    V -->|pass| K[Checkpoint candidate]

The observation schema keeps the loop stable while implementations change:

type Observation = {
  runId: string;
  revision: string;
  environment: "editor_play" | "exported_runtime";
  seq: number;
  tick: number;
  event: string;
  entityId?: string;
  state?: Record<string, string | number | boolean | string[]>;
  artifacts?: { kind: "log" | "screenshot" | "video"; uri: string }[];
  errors: { code: string; message: string; source?: string }[];
};

Instrumentation should expose contract state, not an unlimited reflective view of the game. Stable entity IDs, mode, fragment count, drone state, beacon state, player zone, health or disable charge if used, and feedback events are sufficient for this slice.

5.2 Scene serialization and shared ownership

Scenes combine hierarchy, resources, references, transforms, and engine-managed metadata. Text does not make them ordinary prose. An agent can produce syntactically plausible serialization with broken resource IDs, duplicate ownership, or a transform far outside the level. Binary assets make naive merge even less viable.

The Signal Fire integration contract assigns the main level scene to one integration owner. Gameplay workers edit scripts, test scenes, or self-contained component scenes. The fragment component owns its trigger, stable ID, visual state, and collected event. The drone component owns patrol and disable state. The beacon component owns activation gating and finale. Integration places instances and connects them through stable contracts.

No two workers concurrently edit the main scene, project input map, global event hub, shared telemetry schema, or the same binary asset. Append-only registries may accept independent additions only if validation detects duplicates and ordering is irrelevant. This rule prevents semantic merge conflicts that textual merge tools cannot understand.

Hot reload is labeled a convenience path. If a worker changes a signal signature while old nodes remain alive, callbacks may silently disconnect or target stale objects. A final mechanic check always starts a fresh process. Unity domain reload can recreate managed state and sever an adapter connection. Unreal hot reload or live coding has different limits and does not make Blueprint instances or cooked content equivalent to a clean run. Godot script reload can also preserve misleading scene state.

5.3 Traversal and fragments

Traversal enters first because every later mechanic depends on reaching places. The gray-box controller supports movement, camera orientation, collision, and one interaction action. The test seam accepts abstract input actions and reports player position, grounded state, and named zone entry. It does not assert exact frame-by-frame physics across all machines; it asserts reachability, bounds, and absence of traps on the declared route.

Worked trace 5.1 — Traversal. From spawn [0,1,0], the driver holds move_forward for 1.8 illustrative seconds, turns right for 0.4 seconds, then moves 2.1 seconds. Telemetry must enter approach_a, remain within level bounds, and never report an error-level physics message. A screenshot at the turn checks that the warm fragment silhouette is visible against the cool wall. Counterfactual: if frame timing varies, zone entry may shift in time, but reachability and bounds remain invariant.

Fragments then add identity and a monotonic count. Each fragment has one stable ID from the fixed set {frag_a, frag_b, frag_c}. The authoritative collection function accepts an ID only when mode is PLAYING, the ID belongs to the expected set, and the collected set lacks it. Admission atomically hides or disables the pickup, emits one audio/visual event, updates the HUD view model, and logs the new set.

Invariant F1: collected_ids ⊆ expected_fragment_ids
Invariant F2: fragment_count = |collected_ids|
Invariant F3: 0 ≤ fragment_count ≤ 3
Invariant F4: every accepted ID emits exactly one collection feedback event

The UI reads a view model derived from authoritative state. It does not keep an independent mutable count. That decision eliminates the 3 collected, HUD says 2 class of disagreement at its source.

5.4 Drone, beacon, and UI in dependency order

The drone begins as a small state machine: PATROL, ALERT, DISABLED. A fixed route makes verification reproducible. Perception separates line-of-sight and distance from the state transition so tests can inject perception facts without depending on render pixels. Avoidance passes when the player reaches the far zone without entering ALERT for longer than the allowed grace interval. Disable passes when a valid close-range interaction changes the drone once to DISABLED, stops its threat behavior, and emits readable feedback.

The beacon depends on fragment state. interact at fewer than three fragments produces a blocked pulse and a short audio cue, with rate limiting so held input does not spam. At three unique fragments it changes once from LOCKED to ACTIVE, disables further interaction, starts the finale, enters COMPLETE, and exposes restart.

Figure 5.2 — Mechanic contracts meet at authoritative state. The UI and audio observe transitions; they do not own progression.

stateDiagram-v2
    [*] --> TITLE
    TITLE --> PLAYING: start
    state PLAYING {
        [*] --> Collecting
        Collecting --> Collecting: admit unique fragment / update set
        Collecting --> DroneAlert: drone perceives player
        DroneAlert --> Collecting: escape grace interval
        DroneAlert --> DroneDisabled: valid disable
    }
    PLAYING --> PLAYING: beacon input with count < 3 / blocked feedback
    PLAYING --> COMPLETE: beacon input with count = 3 / finale
    COMPLETE --> TITLE: restart / reset authoritative state

The presentation layer subscribes to admitted transitions. Collection flashes, drone state color, blocked beacon pulse, objective text, audio cues, and finale effects all carry stable event IDs into telemetry. That makes missing feedback diagnosable without asserting exact pixels. The creative director still decides whether the feedback is readable and tonally coherent.

5.5 Worked repair trace: stale editor, false failure

Task SF-DRONE-050 changes the alert grace interval from an illustrative 0.2 seconds to 0.6 seconds. The repository diff is correct and unit tests of the state function pass. The live editor, opened before the change, still runs an old script instance. The scenario reports an alert at 0.23 seconds, so the worker proposes another code change.

The harness notices that the editor observation carries source revision r17, while the task patch is r18. It classifies PRECONDITION_STALE_REVISION, stops repair, reloads through the adapter, and starts a fresh process. The scenario then clears at 0.51 seconds without alert. No second code edit occurs.

The lesson is not “always restart,” because rapid live iteration can be valuable. It is that environment identity belongs in every observation. Without it, the generative lane will rationally repair evidence from the wrong world.

5.6 What this does not prove, summary, and apparatus

These deterministic scenarios do not prove that movement feels responsive, the patrol is fair, the level reads well, or the finale is satisfying. Injected perception facts can verify logic while bypassing physics and occlusion defects. A scripted input route can miss alternative player behavior. Clean checkpoints reduce ambiguity; they do not eliminate regressions.

In Godot, signals, resources, and scene composition provide natural component seams. Unity teams might express equivalent seams with C# components, ScriptableObjects, prefabs, scenes, and play-mode tests. Unreal teams may use C++, Blueprints, data assets, actors, maps, automation tests, and Gauntlet. The invariant is not the engine idiom; it is authoritative progression state observed through stable contracts.

Signal Fire now supports traversal, unique fragments, drone avoid/disable behavior, gated beacon activation, feedback, completion, and restart in cumulative dependency order. Chapter 6 replaces selected gray-box art and sound through a provenance-preserving supply chain.

Review questions

1. Why should the HUD derive its fragment count rather than mutate its own copy?
2. Which project artifacts must not be edited concurrently?
3. What does injecting a drone perception fact test, and what does it bypass?
4. How did revision-bound observation prevent the stale-editor repair loop?

Design problems

1. Invariant design. Add a stun duration to the drone without adding a new enemy state that can overlap inconsistently with DISABLED.
2. Integration design. Split the three post-fragment tasks across workers while preserving one main-scene owner and one telemetry-schema owner.

Implementation lab 5 — Cumulative mechanic scenario. Build the smallest playable gray-box loop with the fixed state machine and telemetry. Pass: fresh runs verify traversal, three unique fragments, one duplicate rejection, both drone paths, early beacon rejection, completion, and clean restart; a capture shows every major feedback state. Fail: tests call internal setters without driving input, skip a clean process, or accept an independent UI counter.

Source notes. Official engine automation documents are C-class evidence for supported surfaces. GameCraft-Bench and JAMER are A-class examples of environment-state verification. The implementation order, invariants, trace values, and component boundaries are author-constructed for Signal Fire and are not benchmark findings.

06Chapter 6The Generated-Asset Supply Chain

Opening production question: How does a generated mesh or sound become an approved production asset without letting a provider write directly into the shipping project?

Chapter thesis: Generative media providers are asynchronous external factories. Their outputs remain quarantined until provenance, rights review, DCC normalization, technical validation, style review, engine import, and runtime verification all pass.

6.1 Start with an asset specification, not a provider

The engineering need comes first: produce a hero beacon and a modular environment prop family that satisfy the art bible and performance budget. A provider is a replaceable implementation behind an asset broker.

The hero beacon specification calls for a stylized industrial silhouette readable at 8–15 in-game meters, a stable circular base, three signal fins, a warm emissive core, no embedded text or logos, separate opaque and emissive material intent, a center-bottom origin, and a normalized size consistent with the project's meter convention. It must support simple static collision and a finale effect implemented in-engine, not baked into unknown animation.

The prop-family specification asks for three compatible pieces—a low barrier, a relay cabinet, and a cable support—with shared bevel language, broad planes, restrained detail, modular dimensions, and no hero-level texture density. Generation may return candidates, but the creative director selects direction before normalization consumes further time.

The asset broker interface is provider-neutral:

type AssetRequest = {
  requestId: string;
  kind: "mesh" | "texture" | "sound" | "voice";
  specificationUri: string;
  references: { uri: string; rightsBasis: string }[];
  providerProfile: string;
  maxCost: { currency: string; amount: number };
  outputRequirements: Record<string, unknown>;
  deadline: string;
};

interface AssetBroker {
  submit(request: AssetRequest): Promise<{ providerTaskId: string }>;
  poll(providerTaskId: string): Promise<"queued" | "running" | "succeeded" | "failed">;
  fetchRaw(providerTaskId: string, quarantineUri: string): Promise<RawArtifactManifest>;
  cancel(providerTaskId: string): Promise<void>;
}

The broker may not copy into res://art/approved or an equivalent production registry. Separation prevents a visually attractive response from skipping the factory checks.

6.2 Asynchronous generation, budgets, and raw manifests

A Tripo-class 3D service accepts a generation task, exposes task status, and returns artifacts later. The current Tripo generation API documents options related to generation, topology or face limits, UV, PBR, parts, rigging, retargeting, and formats; its quickstart and billing documentation describe task lifecycle and credit use. These are C-class descriptions of a named, changing service, not evidence that its outputs meet our art bar.

The harness reserves a provider budget before submission, records the quote or credit estimate, and reconciles actual use. Polling uses bounded exponential backoff and a deadline. A timeout does not mean the provider task failed; the task ID remains durable so a later session can resume. Retrying submission requires an idempotency strategy or explicit human approval because it can create duplicate charges and candidates.

manifest_version: 1
asset_id: sf_beacon_raw_candidate_04
request_id: ASSET-BEACON-012
provider:
  name: <provider>
  task_id: <external-id>
  model_or_mode: <reported-value>
timestamps:
  submitted_at: <iso-8601>
  completed_at: <iso-8601>
inputs:
  prompt_sha256: <hash>
  prompt_text_uri: quarantine/prompts/beacon-012.txt
  references:
    - uri: <internal-reference>
      rights_basis: commissioned-original
outputs:
  - uri: quarantine/raw/beacon-012/model.glb
    sha256: <hash>
    media_type: model/gltf-binary
cost:
  quoted: {unit: credits, amount: <value>}
  actual: {unit: credits, amount: <value>}
terms_snapshot:
  url: <canonical-provider-terms-url>
  retrieved_at: <iso-8601>
  sha256: <hash>
status: quarantined

Raw artifacts are immutable. Malware scanning, archive limits, file-type validation, and metadata inspection occur before a DCC tool opens them. Provider prompt, model or mode when reported, task ID, timestamps, raw hashes, cost, references, and a terms snapshot remain linked through every transformation.

6.3 DCC normalization is a production stage

Generation produces material for editing, not a production-ready promise. A Blender-class DCC stage owns geometry, UVs, materials, rig, scale, axes, origin, naming, collision, levels of detail, and export. The Blender Python API provides a scriptable implementation surface, including export operations, but our normalization contract is engine- and provider-neutral.

Figure 6.1 — Asset admission pipeline. No arrow goes from provider output directly to the shipping project.

flowchart LR
    S[Art bible + technical specification] --> B[Asset broker]
    B --> P[External provider task]
    P --> Q[Immutable raw quarantine\nmanifest + hashes + terms snapshot]
    Q --> N[DCC normalization\ngeometry, UV, material, scale, origin]
    N --> T[Technical validators\ntriangles, bounds, naming, collision, formats]
    T --> A[Creative style review]
    A --> I[Engine import staging]
    I --> R[Runtime scene + performance + capture]
    R --> G[Approved asset registry]
    T -->|reject with report| N
    A -->|reject or request variant| S
    R -->|import/runtime defect| N

For the static beacon, normalization removes disconnected debris, non-manifold surprises that matter to shading or collision, hidden geometry, excessive internal faces, and unneeded material slots. It establishes predictable normals and tangents, a usable UV layout, PBR-compatible material channels, declared texture color spaces, project scale, upright axis, bottom-center origin, descriptive names, a simple collision proxy, and an interchange export. Triangle and texture budgets are chosen from measured scene needs; “low poly” in a prompt is not a measurable budget.

For a rigged character, the stage would additionally own skeleton hierarchy, bind pose, weights, animation retargeting, deformation tests, and root-motion conventions. Signal Fire intentionally keeps generated meshes static because rigging would add a pipeline branch without serving the slice. The drone uses a studio-authored simple rig or procedural part motion.

6.4 Texture and audio factories

Image or texture generation follows the same rights and normalization principles. A candidate must declare whether it is concept art, a tiling source, a decal, or a final texture. The DCC stage verifies resolution, tiling seams, channel packing, alpha use, color space, compression, mip behavior, and whether generated lighting has been improperly baked into a material intended for dynamic light. A coherent prop family often benefits more from shared authored materials than from three unrelated generated texture sets.

Audio generation is also asynchronous production input. The ElevenLabs sound-effects API documents controls such as duration, looping, output format, and prompt influence for its named service. The interface we need is broader: request a short fragment chime, a blocked-beacon pulse, a drone alert, a disable response, and a loopable ambient bed within declared duration, loudness, sample rate, channel, and style constraints.

Normalization trims silence, removes clicks, checks loop boundaries, converts to the engine's approved format, sets loudness relationships, records transformations, and verifies import settings. The creative director listens in context. A pleasing isolated sample may mask the interact cue or fatigue the player when repeated.

6.5 Worked trace: beacon and prop family

The beacon request produces four candidates. Candidate 1 has the clearest fins but an unstable narrow base. Candidate 2 has a readable base but includes embossed pseudo-text, violating the specification. Candidate 3 matches the silhouette and avoids text but has twelve material slots and dense internal geometry. Candidate 4 is clean but too visually ordinary for a hero prop. The creative director selects candidate 3 as a normalization input, not an approved asset.

The DCC report records 168,000 illustrative input triangles, 12 material slots, a 4.8-meter bounding height under interpreted source units, and several internal shells. Normalization retopologizes or simplifies within the approved visual error, reduces material roles to opaque body plus emissive core, removes hidden shells, sets the target height from the level scale contract, creates a simple collision hull, and exports a new glTF/GLB with transformation-script hash. These values are a constructed trace, not provider performance claims.

Engine staging reveals that the emissive texture was imported as a color channel with an unexpected compression setting, muddying the finale. The engine adapter updates import configuration through a typed operation, reimports, and captures the beacon at standard distance under level lighting. The performance check measures the complete finale, not only the mesh. The creative director approves silhouette and material response.

For the prop family, a shared normalization recipe enforces modular dimensions and one material palette. A runtime capture shows a cable support at twice the intended scale. The raw artifact is not manually scaled in the main scene; normalization corrects units and re-exports, preserving instance consistency.

Table 6.1 — Transformation chain for an approved asset.

6.6 Terms, provenance, and careful claims

Provider terms and plan distinctions can change. Tripo's terms currently distinguish rights associated with free and paid use, but this book does not interpret those terms for a particular studio or jurisdiction. Before shipping, record the applicable account, plan, terms version, input rights, output restrictions, platform requirements, and review outcome.

“Commercial use allowed” is not a guarantee of copyrightability, exclusivity, uniqueness, non-infringement, publicity-right clearance, trademark safety, union compliance, or storefront acceptance. Generated audio and images carry comparable uncertainties. Do not ask a model to produce a legal conclusion from a provider marketing page. Escalate material uncertainty to qualified counsel or replace the asset.

Provenance is operational as well as legal. It lets the team reproduce an import, identify all builds containing a rejected asset, compare provider cost, and swap a dependency when a provider disappears.

6.7 What this does not prove, summary, and apparatus

A complete manifest does not prove rights, artistic originality, or aesthetic fitness. DCC validation does not prove that geometry performs in every scene. A provider API does not guarantee stable quality, cost, availability, or terms. Human approval can still miss derivative-looking forms or contextual problems.

Godot can import normalized interchange assets and exposes import plugins; Unity commonly converts them through its Asset Database and importer settings into prefabs and materials; Unreal often builds a richer content pipeline around import factories, data assets, LOD or Nanite decisions, collision, and cooking. The asset broker and raw quarantine remain outside every engine. Engine-native assets enter only after normalization.

Signal Fire now has an approved hero beacon, a coherent environment prop family, normalized sound cues, and complete transformation manifests. Chapter 7 verifies the integrated game through deterministic, multimodal, and human layers.

Review questions

1. Why may the asset broker not insert provider output into the shipping project?
2. Which identities make an asynchronous provider task resumable and auditable?
3. What does DCC normalization own that an engine import does not?
4. Why is “commercial use” language insufficient as a shipping conclusion?

Design problems

1. Schema extension. Extend the raw manifest for a generated voice line with performer-consent and localization fields, without asserting legal sufficiency.
2. Pipeline choice. Decide whether a generated drone should be rigged externally or animated from separate rigid parts in-engine. State slice-specific costs and verification needs.

Implementation lab 6 — Quarantine-to-runtime asset. Run one self-created or properly authorized mesh through raw hashing, manifest creation, scripted DCC normalization, technical validation, engine staging, runtime capture, and an approval record. Pass: the shipping registry can trace the asset back through every hash and transformation, and a raw artifact cannot be referenced by the game. Fail: manual edits are unrecorded, terms lack a dated snapshot, or engine import bypasses normalization.

Source notes. Tripo, Blender, and ElevenLabs documentation are C-class evidence for named API and scripting capabilities. Provider terms are first-party contractual text requiring current, context-specific review; this book offers no legal conclusion. The supply-chain architecture, specifications, illustrative counts, and approval decisions are author constructions.

07Chapter 7Verification and Agentic Playtesting

Opening production question: How do we verify a five-minute game whose correctness includes parsable code, runtime state, spatial behavior, visual readability, performance, and human experience?

Chapter thesis: Verification is a layered stack of differently fallible observers. Lower layers reject cheap failures early; deterministic gameplay tests establish explicit invariants; captures and separate multimodal review expose presentation defects; human playtesting owns comprehension and taste.

7.1 Build the verifier stack by claim strength

Verification begins cheaply. A parser or compiler checks whether the engine can interpret source. Import checks establish that referenced assets enter the engine under declared settings. A strict clean launch establishes that a process can initialize without forbidden errors. Deterministic gameplay scenarios drive inputs and assert state. Property checks explore invariants across seeds or action sequences. Telemetry and replay connect causes to outcomes. Screenshots and video expose perceptual state. A separate multimodal evaluator applies a rubric. A human playtest asks whether the loop communicates and feels coherent.

Figure 7.1 — Layered verifier with two judgment channels. A higher layer may discover failures that all cheaper layers truthfully missed.

flowchart BT
    P[Parse / compile] --> I[Import validation]
    I --> L[Strict clean launch]
    L --> D[Deterministic gameplay assertions]
    D --> R[Properties, replay, restart, save boundaries]
    R --> M[Telemetry + performance]
    M --> C[Screenshot and video capture]
    C --> E[Separate multimodal evaluator]
    C --> H[Human playtest and creative gate]
    E --> H

This order optimizes diagnosis, not prestige. If import fails, there is no reason to purchase a visual grade. If deterministic state is wrong, a beautiful screenshot should not rescue the build. Conversely, a correct state trace cannot certify readable lighting.

Outcome evaluation is a recurring lesson across executable benchmarks such as SWE-bench, OSWorld, AppWorld, ToolSandbox, and GameCraft-Bench. These A-class sources evaluate different environments and do not jointly establish a universal verifier, but they support inspecting environment state rather than trusting final text.

7.2 Deterministic scenarios, properties, and replay

The happy-path scenario starts from a clean build, enters play, traverses all required zones, collects three fragments, avoids the drone, attempts no early activation, activates the beacon, observes completion, restarts, and verifies a clean title state. Additional scenarios disable the drone, attempt early activation, revisit collected fragments, hold interact across frames, leave and re-enter detection, and restart at multiple phases.

Properties compress families of examples:

P1  Always: 0 <= fragment_count <= 3.
P2  Always: fragment_count equals the cardinality of unique collected IDs.
P3  Never: beacon ACTIVE while fragment_count < 3.
P4  Once drone DISABLED: it never returns to PATROL before restart.
P5  After restart: mode TITLE, count 0, drone PATROL, beacon LOCKED.
P6  Each accepted action has one corresponding feedback admission event.

Input replay stores abstract actions, logical ticks, seeds, and synchronization points—not raw keyboard timings alone. The runtime reports when it reaches a named checkpoint, and the driver advances. This reduces flakiness from frame timing while preserving the causal action path. Physics-sensitive checks use tolerances and zones rather than exact floating-point trajectories.

Signal Fire has no save-slot feature; that is a fixed non-goal, not an omitted test. The exported-runtime suite nevertheless starts once with an empty user-data location and once with deliberately stale or malformed transient data to verify that no editor residue or previous run changes the title-to-play contract. If a later variation adds persistence, save format, atomic write, corruption recovery, version migration, and resume position become new acceptance surfaces. Restart in this slice resets in-memory authoritative state; it must not quietly evolve into an unverified persistence system.

The verification result schema retains every claim and artifact:

{
  "result_id": "vr-2026-08-29-031",
  "candidate": {"revision": "d3a1...", "build_sha256": "7b9c..."},
  "environment": {"engine": "Godot", "version": "<pinned>", "machine": "ref-desktop-1"},
  "suite": "signal_fire_release_v1",
  "seed": 4103,
  "status": "fail",
  "claims": [
    {"id": "P3", "status": "pass", "evidence": ["trace:188-246"]},
    {"id": "VIS-DRONE", "status": "fail", "evidence": ["shot:drone-approach"]}
  ],
  "metrics": {"duration_ms": 287144, "min_sustained_fps": 53.2},
  "artifacts": ["trace.jsonl", "runtime.log", "drone-approach.png", "route.mp4"],
  "errors": [{"code": "DRONE_SILHOUETTE_LOW_CONTRAST", "layer": "multimodal"}]
}

7.3 Runtime observation and performance

Instrumentation records admitted state transitions, not every frame of every object. Stable sequence numbers detect loss. Logical ticks and wall time support ordering and cost analysis. Entity IDs and source revision prevent cross-run confusion. Logs classify errors and warnings. A telemetry heartbeat distinguishes a stalled runtime from a lost observation channel.

Performance verification runs a declared route in a release-like exported build after warm-up. It records frame-time distributions, sustained low intervals, memory, and expensive finale markers. A single average frame rate hides spikes. The scripted route samples title, traversal, drone encounter, three pickups, and finale because each stresses different systems. Reference hardware and graphics settings live beside results.

Visual regression uses controlled camera, resolution, settings, content revision, and tolerance. Pixel comparison is useful for unintended gross changes but fragile under nondeterministic particles, temporal antialiasing, platform rendering differences, and animation. Mask or stabilize known variable regions; never widen tolerance until every regression disappears. Unreal's official Automation Framework includes screenshot comparison; Godot and Unity can implement capture and comparison through their respective adapter and test surfaces.

7.4 Three failures that pass lower layers

Failure injection A — The invisible third fragment. Parse, import, launch, collection logic, and replay all pass. Telemetry establishes that frag_c is collectible on the scripted route. The screenshot reveals that its warm emissive material was lost during import, leaving a dark prop against a dark floor. A separate evaluator flags objective unreadability; a human confirms that a first-time player walks past it. The fault lies in import/presentation, not fragment logic.

Failure injection B — The unfair drone. Unit tests inject perception facts and the state machine passes. The full runtime trace shows ALERT while an occluding wall separates drone and player. A ray query is using a collision mask that excludes the wall layer. Only an integrated spatial scenario exposes it. The symptom is “drone feels unfair”; the cause is an environment-query configuration.

Failure injection C — The hollow finale. All deterministic states pass and frame time stays within budget. Beacon activation changes to COMPLETE; particles play; audio event telemetry fires. Video and human review reveal that the sound is nearly inaudible under the ambient loop and the camera faces away from the brightest effect. The state is correct but the experience does not communicate completion.

Table 7.1 — Diagnosis by first detecting layer.

These failures explain why launch is necessary and insufficient. Every lower verifier told the truth about its claim. The error was assuming that a narrow claim entailed the next one.

7.5 Separate evaluators and the human playtest

GameDevBench reports improvement from image or video feedback in its studied tasks, and GameCraft-Bench combines interaction replay with rubric-guided multimodal judgments. This suggests value in perceptual observation, not a solved aesthetic metric. A separate model evaluator receives the acceptance rubric, selected captures, telemetry summary, and no generator self-justification. It reports rubric item, observation, evidence location, confidence, and requested human check.

Separation reduces some self-confirmation but does not create independence. Generator and evaluator may share model families, training priors, prompts, or generic preferences. A visually polished but confusing level can receive a favorable grade. Repeated grades are a distribution; cost and variance matter. The evaluator may recommend a gate outcome, never make the ship decision.

The human playtest begins without a walkthrough. The creative director watches where the player looks, hesitates, misreads affordances, encounters the drone, interprets blocked activation, and responds to the finale. Questions follow observed behavior rather than leading it. Accessibility checks include input remapping assumptions, readable contrast, non-color-only state cues, audio alternatives where in scope, motion intensity, and prompt legibility. The slice's constrained accessibility scope is documented rather than implied to cover all needs.

7.6 What this does not prove, summary, and apparatus

Passing the stack does not prove absence of defects, general player enjoyment, accessibility for all needs, performance on undeclared hardware, or production readiness for a full game. Model grading is useful evidence but correlated and gameable. Human testing is richer but variable and expensive. Replay coverage remains finite.

Signal Fire now has a release-oriented verifier schema, gameplay properties, input replay, telemetry, performance measures, visual capture, separate evaluation, and a human playtest. The three injected failures are repaired and retained as regression cases. Chapter 8 makes this process durable across sessions and carefully introduces parallel work.

Review questions

1. Why should a verifier stack order checks by diagnostic cost and claim strength?
2. Which observation distinguishes a lost telemetry channel from a frozen game?
3. Why can a model evaluator be separate without being independent?
4. Which layer first detects each of the three injected failures?

Design problems

1. Property design. Define a property-based input generator that stresses held interaction without producing physically impossible player states.
2. Visual diagnosis. A screenshot regression changes after an engine upgrade. Specify how to distinguish intended rendering drift from a broken emissive import.

Implementation lab 7 — Layered release suite. Implement at least one check at every layer from import through human review and run the three failure injections. Pass: each failure is first localized to the expected layer with linked evidence, and the clean candidate passes three reset runs. Fail: a model verdict substitutes for deterministic state, screenshots lack fixed conditions, or only editor play mode is tested.

Source notes. Executable benchmarks cited in Section 7.1 and the game benchmarks are A-class, each bounded to its environment. Official engine test documentation is C-class. The verifier stack, schemas, properties, thresholds, and injected failures are author constructions. A model grade is never treated as ground truth.

08Chapter 8Long-Running and Multi-Agent Production

Opening production question: When the slice outlives one context window or one worker, how do we gain continuity and parallelism without multiplying shared-state failures?

Chapter thesis: Start with one bounded worker and durable artifacts. Add checkpoints, isolated environments, and reproducible handoffs before specialists. Parallelize only independent work with explicit integration ownership.

8.1 Durability before delegation

A context window is not a production record. The session event log, task ledger, repository revisions, raw asset manifests, engine observations, verification results, and decisions survive model resets. Each increment ends in one of four states: verified checkpoint, rejected patch with evidence, rolled-back attempt, or explicit blocker. “Still working” is not a durable state unless it names current ownership, artifacts, and next admissible action.

TapeAgents presents a structured tape as granular log and resumable state. Effective harnesses for long-running agents and Harness design for long-running application development report production patterns involving progress artifacts and generator/evaluator separation. Inspect checkpointing specifies restoration of agent state, events, store, and sandbox paths at turn boundaries. These sources support durability patterns; none guarantees exactly-once effects in an editor or provider.

handoff_version: 1
session_id: sf-session-014
objective: Integrate normalized beacon and verify finale
base_revision: d3a1...
current_checkpoint: SF-ASSET-090
completed_tasks: [SF-BOOT-010, SF-MECH-020, SF-MECH-030, SF-DRONE-050, SF-ASSET-090]
active_task:
  id: SF-INTEG-110
  owner: integration_worker
  worktree: <isolated-path>
  allowed_files: [game/main.tscn, tests/finale_scenario.gd]
known_state:
  editor: stopped
  imported_asset_hash: 2ce4...
  last_verification_result: vr-030
open_failures:
  - id: FAIL-071
    evidence: screenshot:beacon-staging
next_action: Apply reviewed placement patch, then run finale scenario
prohibited_assumptions:
  - Do not reuse the open editor from session 013

The handoff is executable context: a new session can verify every identity before continuing. A prose summary alone is too easy to drift.

8.2 Checkpoints, worktrees, and the build farm

A repository worker receives a branch or worktree created from a named revision and a closed allowlist. It never stages or merges on its own. The lead harness reviews diffs against ownership, runs gates, and integrates. Engine sandboxes are isolated as well: sharing one live editor between workers defeats repository isolation because caches, imports, and unsaved state become a hidden merge channel.

A checkpoint contains a revision, task state, engine version, dependency locks, manifest versions, successful verification result, and pending decisions. It does not need to preserve every transient editor selection. External effects such as provider tasks are recorded by durable IDs; rollback cannot unspend credits or unsend a request.

The build farm consumes frozen source and manifests. It imports or cooks in a clean worker, runs engine-specific tests, exports, hashes outputs, and uploads evidence. Build workers have no provider credentials and cannot alter source. Secrets are injected only for the minimum job and excluded from logs and artifacts.

Godot solo architecture. For the reference path, one lead harness admits a repository task into one worktree, invokes a CLI-first Godot adapter in a fresh process, runs the named scenario, normalizes logs and captures, and submits the candidate to deterministic then human review. A live editor is an optional diagnostic environment, never hidden shared state. This is the Chapter 3 architecture made durable: the task ledger and checkpoint allow a new session to recreate the local loop without the old chat or editor. It remains the preferred topology while one worker can make progress faster than coordination overhead.

8.3 Complete Unity editor-plus-CI architecture

Figure 8.1 — Unity hybrid editor and CI reference architecture. Live authoring and clean batch evidence are complementary, not interchangeable.

flowchart TD
    H[Human creative director] --> L[Lead harness + task ledger]
    L --> W[Isolated repo worker\nC#, tests, approved config]
    L --> U[Unity editor adapter\nmain-thread editor service]
    W --> U
    U -->|domain reload event| C[Connection supervisor\nre-handshake + state discovery]
    C --> U
    U --> P[Play Mode scenario\nInput System + telemetry + captures]
    W --> CI[Clean CI workspace]
    CI --> B[Unity batchmode\nimport, Edit Mode, Play Mode, build method]
    B --> A[Build artifacts + test XML + logs + hashes]
    P --> V[Verifier stack]
    A --> V
    V --> H

The editor adapter accelerates prefab and scene operations that benefit from Unity's object model. It marshals changes through editor callbacks, saves explicitly, and expects domain reload after compilation. The connection supervisor re-negotiates tool state rather than retaining invalid references. CI is the authority for clean imports, tests, and builds. Library caches may improve speed but are keyed and disposable; they are not evidence of source correctness.

The repository worker does not concurrently edit the same Unity scene or prefab that the editor adapter owns. Meta-file identities and serialized references are reviewed together. A play-mode capture from the live editor helps iteration; a clean batch/build run supports release evidence.

8.4 Complete Unreal asset-heavy architecture

Figure 8.2 — Unreal asset-heavy studio reference architecture. Asset admission, editor automation, and cooked runtime verification are separate control planes.

flowchart TD
    H[Human creative + art direction] --> L[Lead harness and dependency graph]
    L --> R[Repo workers\nC++, config, tests]
    L --> AB[Asset broker + raw quarantine]
    AB --> D[DCC normalization + validators]
    D --> IR[Approved interchange registry]
    R --> UE[Isolated Unreal editor sandbox]
    IR --> UE
    UE --> EP[Editor automation\nPython / utilities / controlled asset creation]
    EP --> AR[Engine-native asset registry\nownership + fingerprints]
    AR --> AT[Automation tests + screenshot checks]
    R --> UAT[Automation Tool\nbuild and cook]
    AR --> UAT
    UAT --> G[Gauntlet session\npackaged runtime + controllers]
    AT --> V[Verifier and integration gate]
    G --> V
    V --> H

Unreal's content gravity changes integration economics. Engine-native assets and Blueprints often require editor-mediated creation and may be binary. Each asset or map receives an exclusive owner for the task. The DCC stage still produces validated interchange artifacts; the Unreal editor stage converts them into controlled engine-native content. Automation tests cover engine and functional assertions. Automation Tool builds and cooks. Gauntlet orchestrates packaged runtime sessions, logs, controllers, and devices where appropriate.

The architecture is not a claim that Unreal always requires more people or that binary assets are inferior. It makes the asset lifecycle and merge constraints explicit for a content-heavy production surface.

8.5 The parallel studio topology and integration contracts

Only now do we add specialists. How we built our multi-agent research system reports benefits and substantially higher token use for breadth-first research in its production setting. AutoGen and MetaGPT offer programmable multi-agent architectures. These A/D or B-class sources show possible orchestration patterns, not that more agents improve a tightly coupled game task.

Figure 8.3 — Parallel studio with a serial integration waist. Parallel effort converges through isolated evidence and one integration owner.

flowchart TD
    H[Human creative director] --> L[Lead harness\nDAG, budgets, contracts]
    L --> G[Gameplay worker\nowned component files]
    L --> A[Asset pipeline worker\nquarantine + normalized outputs]
    L --> Q[Test worker\nindependent fixtures and scenarios]
    L --> E[Environment worker\nowned modular scene]
    G --> I[Integration owner\nshared scene and hub files]
    A --> I
    Q --> I
    E --> I
    I --> B[Clean build sandbox]
    B --> V[Independent verifier]
    V -->|fail with ownership routing| L
    V -->|candidate| H

Each work package names input revision, exact owned files or assets, interface version, expected outputs, verifier, and prohibited shared mutations. The gameplay worker can implement drone logic while the asset worker normalizes the beacon, because the interface and scale contract are fixed. A test worker can write fixtures against a stable telemetry schema. The integration owner alone edits the main scene.

Tasks that must not be parallelized include competing edits to a shared scene, project settings, input map, save schema, global event bus, telemetry schema, the same prefab or Blueprint, a binary level asset, or a mechanic whose contract is still being designed. Serial dependencies also include normalization before import approval and candidate freeze before release evidence.

Merge admission checks file ownership first, then syntax/import, interface version, deterministic tests, full integrated scenario, performance, captures, and human review. If two branches are individually green but fail together, integration reopens the task graph; it does not ask workers to merge around the symptom independently.

8.6 Worked trace and what this does not prove

The lead schedules three independent packages from checkpoint r24: drone audio mix, beacon normalization, and new early-activation test fixtures. The audio worker owns approved sound configuration, the asset worker owns quarantine and DCC outputs, and the test worker owns new fixture files. None may edit the main scene. All return evidence against r24.

Integration applies the test fixture first, imports the normalized beacon through the adapter, then updates the main scene once. The drone mix configuration follows. Full verification exposes a new conflict: the brighter beacon draws attention past fragment C, lowering its discoverability in the human route. No technical worker is authorized to solve that product tradeoff. The creative director chooses to reduce pre-activation beacon emission rather than move the fixed fragment. Integration records the decision and updates the art parameter.

Counterfactual: allowing the asset worker and level worker to “fix readability” independently could move both beacon and fragment, invalidating routes and tests. Separate context bought parallel effort; the human gate and serial integration preserved intent.

Multi-agent production does not prove better quality or lower total cost. More calls increase compute and coordination. Correlated models repeat mistakes. Isolation can hide an integration assumption. At Signal Fire scale, one capable worker may be faster until the contracts stabilize. Parallelism is justified by independent work, specialized tools, or context isolation—not by an organizational metaphor.

8.7 Chapter summary and apparatus

Signal Fire can now survive context reset, isolated work, clean builds, and a bounded parallel phase. The book has complete local Godot, Unity editor-plus-CI, Unreal asset-heavy, and parallel-studio reference architectures. Chapter 9 freezes a candidate, assembles provenance and release evidence, and returns the final decision to the human creative director.

Review questions

1. Which artifacts must survive a context reset?
2. Why must engine sandboxes be isolated as well as repository worktrees?
3. What complementary roles do Unity live-editor iteration and batch CI play?
4. Which tasks in the parallel topology must remain serial, and why?

Design problems

1. Handoff diagnosis. A resumed session has a valid repo revision but cannot identify which provider task produced a staged mesh. Specify the missing durable records and safest recovery.
2. Parallelization decision. Decide whether HUD polish, input remapping, and finale particles can proceed in parallel. Name shared hubs and required contract freezes.

Implementation lab 8 — Reset and handoff. Stop a development session after a verified mechanic, destroy its transient context and editor process, and resume from the durable handoff. Pass: the new session verifies identities, starts a clean environment, completes the next task without unstated knowledge, and integration rejects one deliberately out-of-scope edit. Fail: success depends on chat history, an open editor, or a worker modifying a shared hub outside ownership.

Source notes. TapeAgents is A/D, the two long-running harness reports and multi-agent production report are B, Inspect checkpointing and official engine automation pages are C, and AutoGen/MetaGPT are A/D. They support bounded patterns, not this topology's universal superiority. All four reference architectures are author synthesis.

09Chapter 9Shipping, Provenance, and the Human Creative Gate

Opening production question: What must be true—and what evidence must remain—before the creative director ships Signal Fire as a desktop vertical slice?

Chapter thesis: Shipping is a controlled transition from a frozen, verified source state to a distributable artifact. Reproducible inputs, provenance, platform checks, operational evidence, rollback, and provider contingencies inform the decision; the human creative director owns it.

9.1 Freeze the candidate and assemble the release pipeline

Release begins by freezing a candidate revision, engine version, dependency locks, approved asset registry, export profile, verifier suite, and reference-machine definition. No worker edits that candidate in place. A fix creates a new candidate and invalidates downstream evidence whose inputs changed.

Figure 9.1 — Release admission pipeline. Evidence is bound to the candidate; the ship gate can approve, revise, or reject.

flowchart LR
    F[Frozen source + locks + approved assets] --> C[Clean import / compile / cook]
    C --> T[Tests + scripted runtime]
    T --> P[Performance + accessibility checks]
    P --> B[Platform export]
    B --> H[Artifact hash + dependency/license/provenance manifests]
    H --> O[Crash/log smoke run + captures]
    O --> E[Release evidence packet]
    E --> G{Human creative and ship gate}
    G -->|approve| S[Store-ready candidate]
    G -->|revise| N[New revision and invalidated evidence]
    G -->|reject| R[Rollback / archive]

The clean worker has source and approved dependencies but not model-provider or asset-provider credentials. Build secrets, if required for a target, are injected for the minimum step and never written into source, logs, screenshots, or manifests. A secret scanner and artifact inspection run before upload.

Reproducibility means declared inputs and a controlled procedure can produce functionally equivalent artifacts, not necessarily byte-identical files across every engine and platform. Where deterministic bytes are achievable, hashes demonstrate them. Where timestamps, compression, signing, or platform tooling vary, record the cause and compare the appropriate content manifests and runtime behavior.

9.2 Manifests, costs, and operational fitness

The release packet links dependencies, licenses, generated assets, transformations, source, build, tests, runtime traces, captures, performance, accessibility scope, known issues, costs, and the human decision.

release_evidence_version: 1
candidate: signal-fire-0.1.0-rc5
source:
  revision: <git-hash>
  dirty: false
toolchain:
  engine: {name: Godot, version: <pinned>}
  adapter_version: <hash>
  build_image: <digest>
dependencies:
  lockfile_sha256: <hash>
  license_manifest_uri: evidence/licenses.json
assets:
  approved_registry_sha256: <hash>
  provenance_manifest_uri: evidence/assets.json
builds:
  - platform: desktop
    uri: dist/signal-fire.zip
    sha256: <hash>
verification:
  result_ids: [vr-041, vr-042, vr-043]
  full_route_video: evidence/full-route-rc5.mp4
  performance_report: evidence/perf-rc5.json
accessibility:
  declared_scope: evidence/accessibility-scope.md
  result: pass-with-known-limits
operations:
  crash_smoke_result: pass
  log_collection_verified: true
costs:
  model: {currency: USD, amount: <measured>}
  providers: {currency: USD, amount: <measured>}
  compute: {currency: USD, amount: <measured>}
known_issues: []
human_gate:
  decision: approve
  reviewer: <id>
  timestamp: <iso-8601>
  rationale: <record>

Cost accounting includes model inference, generation-provider charges, build compute, storage, and material human time where the studio tracks it. A benchmark score without cost is not a production estimate; AI Agents That Matter emphasizes cost, reproducibility, holdouts, and confounded evaluation comparisons. For this project, actual ledger entries replace generic claims about AI being cheap or expensive.

Operational fitness includes startup time, crash behavior, log collection, window and input behavior, settings persistence if any, and clean uninstallation or artifact packaging appropriate to the desktop target. The team performs a smoke run outside the editor and from a fresh extraction path. Logs have a documented user location and exclude secrets or unnecessary personal data.

9.3 Accessibility, performance, and store-ready evidence

The slice declares what it supports: keyboard and mouse controls with a documented remapping path or fixed-input limitation; prompts readable at target resolution; critical fragment, drone, and beacon states not conveyed by color alone; separate control of major audio groups if implemented; subtitles or visual equivalents for gameplay-critical sounds; bounded camera motion; and pause/restart behavior. Missing support is a known release constraint, not an invisible assumption.

Performance results belong to the exact exported candidate, reference machine, settings, and route. The release review examines sustained frame-time problems, memory growth across restart, import or shader stalls in a fresh run, and the finale peak. Editor profiler numbers are diagnostic but do not replace packaged evidence.

A store-ready evidence packet includes representative screenshots, a complete unedited route capture for internal review, concise feature and control descriptions that match reality, asset and dependency manifests, current platform requirements, known limitations, privacy disclosures if any telemetry leaves the device, and support/contact paths appropriate to the release. The chapter does not provide store-specific legal or submission advice because requirements change and vary by platform.

9.4 Rollback and provider failure contingency

Rollback preserves the last approved source revision, dependency locks, asset registry, build artifacts, and evidence packet. A failed new candidate does not overwrite them. If a shipped issue appears, the studio can identify which builds contain an asset or dependency, reproduce the reported path, and choose a hotfix, rollback, or withdrawal under the relevant platform's current process.

Provider contingency begins before failure. The model policy is replaceable because tasks and tool observations use studio schemas. The asset provider is replaceable because raw requests, references, manifests, and normalized deliverables sit behind the broker. Generated audio can be replaced from its specification. Community engine bridges are optional adapter implementations, not the sole representation of engine commands. Build procedures pin required toolchains and archive enough metadata to reconstruct them within licensing constraints.

If a provider disappears after raw generation, the approved normalized asset and complete provenance remain. If terms change before release, the studio reviews the applicable snapshot and current obligations, seeks qualified advice when material, or replaces the asset. If an MCP bridge is abandoned, the adapter contract can be reimplemented through official engine surfaces. Replaceability has a cost, but it prevents one volatile tool from becoming the book's architecture.

9.5 End-to-end Signal Fire release review

Candidate rc5 starts from a clean extraction and reaches the title screen. Three deterministic runs with declared seeds pass. The first route avoids the drone; the second disables it; the third stresses early beacon interaction and restart. Unique fragment identities, authoritative HUD state, drone occlusion, beacon gate, completion, and reset properties pass. Logs contain no prohibited errors.

The performance report meets the local target on the reference machine. The fresh run exposes one short shader-compilation hitch below the target; the rubric distinguishes a transient warm-up event from a sustained low interval, and the report keeps it visible. Memory returns within tolerance after three restarts. The exported build, not editor play mode, supplies the final measurements.

Provenance traces the beacon and prop family from provider tasks through raw hashes, DCC transformations, engine import settings, runtime captures, and approval. Audio manifests identify each generated or authored source and normalization. Dependency licenses receive a current review. The build hash matches the evidence packet.

The human playtest finds the three fragments, understands the drone's alert, discovers the disable interaction from the existing prompt, reads the early beacon rejection, and recognizes completion. The creative director judges the warm-signal versus cool-industrial art direction coherent, but notes that the disabled drone sound is sharper than the rest of the mix. Because it is noticeable but not confusing or unsafe, the director may approve with a recorded post-slice improvement, or reject and create rc6. The architecture does not make that taste decision automatically.

Decision record 9.1 — Ship gate

9.6 What this does not prove, summary, and apparatus

A reproducible pipeline does not prove a defect-free artifact. A provenance manifest does not resolve all rights questions. A store-ready packet does not guarantee platform approval or market success. Accessibility checks cover the declared scope, not every need. Three deterministic runs do not characterize every possible player trace. The creative gate does not become objective because it is recorded.

The project has nevertheless crossed a meaningful boundary: Signal Fire is an observed, five-minute desktop game with a title/restart flow, traversal, three fragments, one avoidable or disable-able drone, a gated beacon finale, coherent feedback and audio, normalized generated art, instrumentation, tests, an export, and linked evidence. The studio can explain how every material artifact entered the build and why the human decided to ship or revise it.

Capstone implementations may preserve this contract through three engine paths. A Godot capstone emphasizes text-oriented repository work, CLI import/test/export, a small editor plugin only where needed, and a lightweight runtime driver. A Unity capstone emphasizes a supervised editor adapter, domain-reload recovery, Edit Mode and Play Mode tests, batchmode CI, and prefab/scene ownership. An Unreal capstone emphasizes DCC and engine-native asset admission, exclusive asset ownership, Python or editor utilities, Automation Tool, Automation tests, and Gauntlet packaged sessions. None may weaken the player-observable rubric to fit a convenient tool.

Review questions

1. Which inputs must freeze before release evidence is collected?
2. Why might reproducibility mean functional equivalence rather than byte identity?
3. How does provenance support operational rollback as well as rights review?
4. Who owns the final Signal Fire ship decision, and what evidence informs it?

Design problems

1. Evidence invalidation. A final audio change touches only mix settings. Identify which evidence must be regenerated and which manifests may remain valid, with reasons.
2. Contingency. Replace the 3D provider while preserving the hero-beacon specification and admission contract. Name the provider-specific fields that may change and studio invariants that may not.

Implementation lab 9 — Release candidate. Produce a clean desktop export and the release evidence schema above. Pass: source is clean and frozen; build hash, three runtime results, performance, captures, dependency/license and asset provenance, known limits, cost totals, and a real human gate are linked; a new source edit invalidates the candidate. Fail: evidence comes from the editor, provider credentials enter the build job, or an automated grader makes the ship decision.

Source notes. AI Agents That Matter is treated as A/D-class research and methodological critique for evaluation concerns in its studied agent literature. Official engine export and automation documents are C-class capability evidence. Provider terms and platform requirements require current first-party review. The release pipeline, review, schemas, thresholds, and candidate outcomes are author-derived production specifications.

Final Glossary

Action. A structured request for an environment transition. “Place beacon instance” is an action; “make it better” is not yet one.

Approved asset registry. The set of normalized assets admitted for engine use, each linked to raw provenance, transformations, validations, and a creative decision.

Asset broker. The least-privileged component that submits external generation requests, tracks asynchronous lifecycle and cost, and stores raw manifests. It cannot place assets into the shipping project.

Build artifact. A platform-targeted output produced from frozen inputs, identified by a hash and linked to its toolchain and evidence.

Checkpoint. A recoverable, mergeable production state with source identity, task state, environment assumptions, and verification evidence.

Clean launch. A new engine or runtime process started against a declared revision and environment, without relying on unrecorded live-editor state.

Creative director. The human component that owns intent, taste, scope, art direction, tradeoffs, and the ship decision.

DCC normalization. The controlled stage that converts quarantined media into technically consistent geometry, UVs, materials, scale, axes, origins, rigs, collision, LODs, and interchange exports.

Deterministic lane. Code and policy that enforce exact schemas, permissions, budgets, hashes, builds, imports, and verifiers. Deterministic does not mean bug-free.

Engine adapter. The boundary that translates studio commands into engine-specific file, editor, runtime, observation, test, and build operations.

Environment. A stateful world that actions can change: repository, engine editor, exported runtime, provider, DCC process, build service, or person.

Evidence packet. A candidate-bound collection of hashes, logs, traces, results, captures, manifests, costs, known limits, and human decisions.

Generative lane. A model-mediated process that proposes plans, code, layouts, diagnoses, or asset candidates within deterministic boundaries.

Harness. The controller that computes context, invokes a model policy, validates and routes actions, updates session state, records traces, applies budgets and policy, and decides what happens next.

Idempotency key. A stable identity that lets a stateful service recognize a repeated logical request and avoid duplicate mutation or charge.

Main-thread marshaling. Moving a validated request from a transport or worker thread onto the engine thread authorized to mutate editor or runtime state.

MCP. Model Context Protocol, a host/client/server protocol for exposing capabilities. It standardizes connection mechanisms, not game semantics, tool quality, or authorization policy.

Model policy. The nondeterministic conditional process that proposes the next message or action from current context.

Observation. A structured report of environment state after or during an action, bound to run, revision, sequence, and target environment.

Provenance manifest. A durable record connecting source or provider task, references and rights basis, raw hashes, terms snapshot, transformations, costs, imports, approvals, and builds.

Raw quarantine. Immutable storage where untrusted external artifacts remain until inspection and normalization. Shipping code cannot reference it.

Repository worker. A bounded worker authorized to inspect and modify a closed set of text, code, or configuration files in an isolated branch or worktree.

Scenario. A controlled runtime procedure with initial state, input sequence, synchronization, expected observations, and decision rules.

Session. Durable task identity and event history. It is larger and longer-lived than the model's current context window.

Signal Fire. The fixed recurring vertical slice: one compact stylized 3D level, three fragments, one patrol drone, one beacon, and a five-minute title-to-restart loop.

Tool profile. The task-specific subset of engine or service tools exposed under a particular authority policy.

Verifier stack. Ordered evaluators that establish bounded claims from parse and import through runtime state, performance, multimodal review, and human playtest.

Vertical slice. A short, representative, end-to-end path through the intended product quality bar; not a miscellaneous feature sample.

Thirty-Day Capstone Plan

The capstone produces a playable build and evidence packet, not a pitch deck. Use the Signal Fire mechanics and art constraints unless an instructor explicitly approves a variation. Budget one focused day for each numbered step. When a task finishes early, spend the remainder improving evidence or reducing scope risk; do not silently add features.

Days 1–5: Contract and control plane

1. Write the player-observable state machine, fixed non-goals, reference hardware, performance budget, and human checkpoints.
2. Create the task, engine-command, observation, verification-result, asset-manifest, and release-evidence schemas.
3. Implement task admission with closed path permissions, revision preconditions, budgets, and rollback declarations.
4. Implement the smallest engine adapter operations: inspect, clean import/compile, launch, named input, observation, stop.
5. Produce the title-to-playing boot shell and evidence trace. Checkpoint A passes only if a clean process reaches title, accepts start, spawns correctly, and links observations to a revision.

Days 6–10: Traversal and progression

6. Build gray-box traversal with a stable spawn, bounds, collision, camera, and abstract input actions.
7. Create three fixed fragment component instances with stable identities and one-shot admission.
8. Derive the HUD from authoritative fragment state and add collection feedback telemetry.
9. Implement early beacon rejection and activation at exactly three unique fragments.
10. Add completion and restart reset. Checkpoint B passes only if deterministic scenarios reject duplicates and early success, reach completion, and demonstrate clean restart under the tested conditions.

Days 11–15: Encounter and presentation contract

11. Implement the drone's fixed patrol and telemetry state machine.
12. Add integrated distance and line-of-sight perception with explicit collision masks.
13. Add readable avoidance and disable paths without changing the one-enemy scope.
14. Add placeholder audio and visual events for collection, alert, disable, blocked beacon, and finale.
15. Run a blind gray-box playtest and repair only comprehension blockers. Checkpoint C passes when both drone paths and the complete loop work through real inputs.

Days 16–20: Asset supply chain

16. Freeze the art bible, scale convention, hero-beacon specification, prop-family specification, and audio specifications.
17. Submit or manually source properly authorized candidates through the provider-neutral broker; record costs and raw manifests.
18. Normalize the beacon in a DCC stage: geometry, materials, UV, scale, axes, origin, naming, collision, and export.
19. Normalize the prop family and audio; validate modular dimensions, shared style, formats, loop points, and relative loudness.
20. Stage imports, run runtime captures and performance probes, and hold the creative approval. Checkpoint D passes only when shipping references point exclusively to approved normalized assets.

Days 21–25: Verification and repair

21. Implement parse/compile/import and strict-launch gates from a clean environment.
22. Implement the full deterministic suite, properties, three seeds, replay synchronization, and restart stress.
23. Add telemetry health, frame-time and memory reporting, screenshots, and a complete route video.
24. Inject the dark fragment, see-through-wall drone, and hollow finale failures; verify that each localizes at the intended layer.
25. Conduct separate multimodal review and a human blind playtest. Checkpoint E passes when all deterministic checks pass and every perceptual blocker has a linked repair or explicit rejection.

Days 26–30: Candidate and evidence

26. Freeze dependencies, engine version, approved asset registry, export profile, and candidate revision.
27. Build from a clean worker, run tests, export desktop, hash the artifact, and smoke-test a fresh extraction.
28. Complete dependency/license, provenance, cost, accessibility-scope, performance, crash/log, known-issue, and rollback records.
29. Run the end-to-end release review: three scenarios, full video, evidence audit, and creative director playthrough. Any source change creates a new candidate.
30. Record approve, revise, or reject. Archive the candidate, evidence packet, task ledger, handoff, and capstone retrospective. Final pass: another engineer can obtain the declared toolchain, identify every source input, run the packaged game, reproduce the verification procedure, and understand the human decision without access to the model conversation.

Capstone variation rules

A Godot implementation may keep scenes mostly text-oriented and rely on the headless CLI, but final evidence must include an exported runtime. A Unity implementation may use editor scripting for prefab and scene work, but must recover cleanly from domain reload and reproduce evidence in batch CI. An Unreal implementation may use editor-native content, Python or utilities, Automation Tool, Automation tests, and Gauntlet, but must isolate binary ownership and verify a cooked build. Provider substitutions are allowed behind the broker. Mechanic expansion is not.

The capstone fails if it presents only source files, an editor video without a packaged build, unmanifested generated assets, model self-grading, or a release decision with no human owner. It succeeds when the game is observable, the production state is recoverable, the external inputs are traceable, the architectural seams are replaceable, and the evidence supports exactly the claims the team makes.