Loop Engineer - Kaiju QA

Test small. Help big. A spatial game where aspiring developers learn AI-assisted development through goals, evidence, regression testing, and a safe release—on desktop, mobile, or WebXR. Very meta....

Comment

Short project description

Kaiju QA is a tactile educational game about a well-meaning baby kaiju whose fast fixes are not always safe. Players stage test cases, run a baseline, add an edge case, observe a regression, replace an over-broad rule with a targeted one, rerun the complete suite, and stamp a release only when every result is fresh and passing.

The same lesson runs from one browser codebase on desktop, mobile, and WebXR. It turns an abstract AI-era engineering habit—goal, change, evidence, gate—into something learners can see and manipulate.

Inspiration

AI can produce a plausible change in seconds, but speed does not teach the judgment needed to decide whether that change is safe. New developers often see the happy path work and treat it as proof, even when an edge case or an old requirement has quietly broken.

We wanted to make verification memorable without turning it into another lecture or code editor. A helpful baby kaiju became the perfect metaphor: the creature is trying to help, the first result looks impressive, and the real monster is the regression nobody tested. That led to Kaiju QA, a short spatial game where evidence—not confidence—earns the release.

What it does

The game teaches an emerging AI-era practice: Loop Engineering. Rather than prompting until something looks right, a Loop Engineer designs the recurrence around the agent—goal, action, observation, adjustment, and an explicit pass/stop/escalate gate. The game also places that inner loop inside the wider software development lifecycle, including operation and maintenance after release.

Kaiju QA teaches evidence-driven release judgment through direct interaction. In the Training Yard, the player completes a nine-step guided sequence:

  1. Stage a service-car scenario.
  2. Pull the test lever and record a baseline.
  3. Add a fragile-tower edge case.
  4. Test before changing behavior.
  5. Install an intentionally broad safety rule.
  6. Rerun the old scenarios and catch the ambulance regression.
  7. Replace the broad rule with a targeted slow zone.
  8. Verify the full suite under the current rule.
  9. Press the release stamp only after all evidence is current and passing.

Three transfer districts—School Crossing, Harbor Load, and Storm Shift—then remove most of the tutorial scaffolding and ask players to apply the same loop to new hazards. Wrong choices create useful, persistent evidence rather than a game-over screen, so recovery is always one meaningful action away.

Desktop mouse, keyboard and switch-style actions, mobile touch, and XR controller rays all map to the same verbs: grab, move, place, pull, and press. Captions, narration controls, reduced motion, visible status words, and a semantic non-canvas state summary keep the core lesson available beyond color or animation alone.

Core features

  • One complete beginning-to-ending learning arc in under three minutes.
  • A deterministic baseline, scoped change, observable result, regression, and release or escalation decision.
  • Spatial evidence such as traces, attempt overlays, scenario coverage, or prototype diffs that remains visible between runs.
  • Equal semantic controls on desktop, touch, and WebXR; XR improves embodiment without hiding functionality behind a headset.
  • One-handed interaction, large targets, captions, non-color state cues, reduced-motion behavior, and one-action retry.
  • Static-host-friendly critical path with no account, backend, live model, or network dependency after load.

Audience and potential impact

Primary learner: STEM students, first-year computer-science/software-engineering students, bootcamp learners, and career switchers who use AI tools but have not yet built strong verification and release judgment.

Secondary user: instructors who need a short classroom activity or formative assessment that demonstrates reasoning rather than vocabulary recall.

Specific learning evidence: the player must define observable acceptance, inspect external evidence before adjusting, preserve valid criteria during a regression, and stop or escalate at an authority/risk boundary.

The submission should claim an engaging introductory practice opportunity—not professional mastery or proven learning gains unless a real pilot is completed.

Why it is different

Loop Engineer is not a syntax lesson, conveyor factory, node editor, or chatbot quiz. The player does not win by writing the shortest program or finding a clever prompt. They win by making a bounded change and producing enough evidence to justify the next lifecycle decision.

The closest familiar genres expose programming, automation, or system repair. Loop Engineer makes acceptance criteria, attempt memory, regression tests, human authority, rollback, and release confidence the actual toys.

How we built it

The game is a TypeScript and Vite web application built on IWSDK 0.4.2. A pure, renderer-independent reducer owns campaign progression, attempts, evidence freshness, regressions, and release eligibility. The 3D scene is a projection of that deterministic state, so an animation can never decide whether a test passed or whether a release is allowed.

IWSDK interaction entities provide shared pointer, touch, keyboard, and XR-ray behavior. Mixed-reality placement uses immersive-ar, hit testing, horizontal surface validation, optional anchors, and a manual fallback. The production build is static-host compatible and needs no account, backend, runtime model call, or speech service.

Codex with GPT-5.6 was used as the build-time collaborator. It converted the initial learning goal into acceptance criteria and a test matrix, researched IWSDK constraints and licensing, implemented and reviewed independent code slices, authored model and browser tests, diagnosed playtest findings, and assembled the evidence and submission video. GPT-5.6 is not presented as an in-game API feature; it was the reasoning model used through Codex to build and verify the project.

The human owner retained the product decisions. They selected Kaiju QA, required the step-by-step tactile tutorial, rejected the cluttered initial layout, directed the full-bleed workbench and camera controls, requested passthrough placement and draggable evidence cards, and required fixes for road layering and task-arrow alignment before accepting the release.

Challenges we ran into

Teaching a real engineering idea without a lecture

The lesson had to show why a passing happy path is insufficient, why a broad fix can regress old behavior, and why evidence becomes stale after a change. We turned each concept into a physical action and kept earlier outcomes visible so the player can compare runs instead of memorizing definitions.

Keeping one interaction model across screens and headsets

Desktop, portrait mobile, and XR have very different reach, camera, and input constraints. We used the same semantic game intents across mouse, touch, keyboard, switch-style controls, and controller rays, then adapted presentation and placement without creating a desktop-only alternate game.

Making evidence readable in a busy 3D scene

Early playtesting exposed overlapping controls, cards, routes, and task arrows. We rebuilt the scene as a full-bleed workbench, separated the rule rack and installation dock, made evidence cards draggable with live target connectors, fixed route depth behavior, and aligned the large and small task cues.

Proving the submission rather than merely describing it

We kept a deterministic model suite, real browser interactions, desktop/mobile evidence, IWER controller evidence, dated prompt logs, asset provenance, and independent reviews. The demo video explicitly labels concept visualizations and switches to a real browser capture for the working-product proof.

Ran through credits very fast.

This game requires a lot of credit because we used Sol on ultra to get things done faster in the little time we had to work on it.

Accomplishments that we're proud of

  • A complete four-district campaign that teaches the full goal → change → evidence → gate loop.
  • A deliberate broad-fix regression that makes the player's mistaken confidence visible without punishing experimentation.
  • One static web build that remains playable without a headset and supports desktop, mobile, keyboard/switch access, and an XR controller path.
  • A pure deterministic campaign model with 23 passing model/helper tests.
  • Passing merged-branch CI and a live GitHub Pages deployment.
  • A documented, compact asset set using Quaternius and Kenney CC0 models, original/code-native visuals, and offline Kokoro narration.
  • A 95.1-second English demo master with captions, specific Codex/GPT-5.6 narration, and a real working-prototype browser segment.

What we learned

The strongest way to teach verification is to let a learner make a reasonable mistake and then give them persistent evidence that explains the consequence. Failure became more useful once it stopped being a reset screen and became a comparison the player could act on.

We also learned that deterministic state and authored presentation are a strong pair for educational 3D work. The reducer makes every pass, regression, stale result, and gate testable; the spatial scene makes those same decisions memorable. Separating the two let us iterate on visuals and input without weakening the learning logic.

Finally, Codex was most valuable when paired with explicit human taste and release gates. It accelerated research, implementation, testing, and review, but the project improved when the owner challenged clutter, clarified the intended physical interactions, and refused to ship visual defects that tests alone would not catch.

What's next for Kaiju QA and Loop Engineer

  • Run a physical Quest headset comfort and performance pass in addition to the completed IWER controller/lifecycle verification.
  • Complete a full screen-reader and switch-user campaign review.
  • Add an instructor mode with a short debrief and classroom discussion prompts.
  • Build a scenario authoring format so teachers can create new goals, edge cases, broad fixes, and release gates without changing the renderer.
  • Expand Loop Engineer into additional short games that teach rollback, escalation, observability, and maintenance with the same evidence-first philosophy.
  • Pilot the lesson with students or career switchers and measure whether they transfer the regression-checking habit to a real AI-assisted coding task.

Built With

  • Codex
  • GPT-5.6
  • IWSDK 0.4.2
  • TypeScript
  • Vite
  • @iwsdk/core / Three.js
  • WebXR and immersive-ar
  • Playwright
  • Node.js test runner
  • GitHub Actions
  • GitHub Pages
  • Quaternius CC0 models
  • Kenney Factory Kit CC0 models
  • Blender 4.4
  • Azure FLUX.2-pro for the optional laboratory backdrop and concept hero
  • Kokoro-82M offline text-to-speech
  • HyperFrames for the narrated competition video
  • Python and Pillow for submission-image format conversion

How it will be built

  • Runtime: IWSDK 0.4.2, TypeScript, Vite, ECS, Interactable components, and one compact stationary 3D scene.
  • Delivery: one relative-path static build suitable for GitHub Pages.
  • Game logic: deterministic state machine; preauthored outcomes and traces; no physics on the critical path.
  • Inputs: shared semantic actions mapped to mouse, touch, XR ray, and optional direct grab.
  • Content: primitives first; selected Quaternius CC0 packs only after license and file-size review.
  • Verification: typecheck, production build, desktop/mobile browser E2E, IWER/WebXR interaction pass, evidence screenshots, accessibility and performance review.

How Codex and GPT-5.6 were used

Use concrete dated evidence here after implementation. Suggested structure:

  1. Codex converted the team prompt into acceptance criteria, risks, a test matrix, and an isolated branch/worktree.
  2. Dedicated agents researched learning design, market collisions, IWSDK constraints, art direction, narrative, humor, and Devpost requirements.
  3. Humans selected the concept, protected the learning objectives, and made final scope and taste decisions.
  4. Codex implemented disjoint code slices, integrated them centrally, and created browser/XR tests and durable evidence.
  5. Independent agents reviewed interaction, comfort, accessibility, and the final diff; humans accepted or rejected recommendations.

We had to ask codex to redo some things we explicitly told it to do and it didn't. you can see the prompts in the repo.

Built With

  • codex
  • gpt-5.6-sol
Share this project:

Updates