// case study
Gravity Golf went from PRD to playable physics game through autonomous repair loops.
Gravity Golf is a Godot 4 mini-golf slice set on a small planet. Agents built the scene, arcade gravity, surface collision, slingshot aiming, scoring, UI, state server, and harness QA flow.
This page is a sanitized site copy created from surviving Gravity Golf artifacts: repository history, controller broadcast context, task history aggregates, and agent learnings. The raw log archive is not treated as complete, and raw logs are not copied verbatim because they can include local paths and personal context.
// what was built
A tiny golf game with a real physics loop, not just a static scene.
The PRD asked for a planet, ball, hole, arcade-style gravity, surface bounces, slingshot aiming, scoring, and UI. The final repository contains Godot scripts for all core systems plus scene wiring and test coverage for setup, gravity, collision, slingshot, scoring, and UI.
The important part is the stabilization path. Gravity Golf did not simply pass on the first attempt. Agents found broken physics, scene-state issues, UI API mistakes, duplicate state server behavior, and harness polling failures, then repaired them through queued bug tasks and QA reruns.
// systems
The build covered the whole first playable slice.
Arcade gravity
The ball accelerates toward the planet center with configurable pull and game-state telemetry.
Collision and hole detection
Agents fixed surface bounce behavior, no-clip issues, and false-positive hole triggers.
Slingshot and scoring
Drag power, launch direction, stroke count, par tracking, and completion messages were wired into the scene.
Task graph animation from the Gravity Golf run.
// broadcast excerpt
The broadcast log shows a stabilization story.
These excerpts are copied from surviving broadcast context and sanitized. Internal task IDs remain because they are useful evidence; local paths, personal account names, and raw process details are omitted.
[2026-05-08 22:29 | gravity-golf-t01-4681] US-001 Scene Setup complete. Planet, ball, and hole render with a playable initial layout. [2026-05-11 22:46 | gravity-golf-t02-4682] US-002 Gravity Simulation complete. Ball is pulled toward the planet center with arcade-style gravity. [2026-05-13 14:03 | integration-gravity-golf-1778693284] Collision physics fixed. Ball bounces off planet, hole detects ball entry. [2026-05-13 15:26 | gravity-golf-t05-4685] Hole Detection and Scoring implemented: stroke count, par tracking, hole completion signal, and tests. [2026-05-13 16:44 | qa-bug-gravity-golf-9e0fb2c834d1] Fixing ball movement: move_and_collide(..., test_only=true) prevented actual movement. [2026-05-13 17:16 | qa-bug-gravity-golf-6edc4f497457] State server game_state returns full data. Remaining harness issue is environmental, not core game code.
// what the agents learned
Gravity Golf exposed different failure modes than Chess-2.
The agent learnings repeatedly mention practical runtime lessons: check git history before duplicating work, use headless script validation for fast Godot checks, prefer state polling over screenshots in headless mode, and verify scene tree state before assuming gameplay code is broken.
The biggest game bug was concrete: physics appeared to run, but the ball did not move. The root cause was a `test_only=true` collision call combined with a starting position inside the planet. Agents fixed the movement method and repositioned the ball and hole onto the surface.
// limitations
This was a playable first slice, not a finished commercial game.
Gravity Golf proves a smaller but important end-to-end loop: generate a game from a PRD, integrate physics and UI, detect runtime defects, repair them, and finish with harness QA. It does not claim multiple levels, polished art, mobile packaging, or release readiness.
// more evidence
Compare it with the longer Chess-2 run.
Chess-2 was larger and more game-system-heavy. Gravity Golf is useful because it shows the same controller converging on a compact physics game with repeated QA repair loops.