A 3D Game in One Day: Building BOINGWARD with AI Agents

BOINGWARD is a 3D mobile game where a rusty robot on a pogo stick that never stops bouncing climbs a tower of floating platforms. There is no jump button: the pogo launches by itself on every landing, and you choose where it lands with your left thumb and where you look with your right.

This post covers the game's first day. The first commit landed at 8:47 a.m. on October 4, 2026, and the 148th at 6:06 p.m. In between came a build installed on an iPhone, a hand-designed course, more than forty platform types, medals, achievements, a climb mode about a kilometer tall, and an online race server that is not switched on yet. I did not write the code. I ran several Claude Code sessions at once, made the decisions and tested on my phone. The game is still in development and not in any store; I list what is ready and what is not further down.

I had already built Kalecik the same way. What was different this time: the job was bigger, and we changed engines in the first hour.

The starting point: a design pack

There was no code, just a design pack: product vision, pogo physics, mobile controls, multiplayer, level design, art direction, economy, UI flow, performance budgets and a roadmap, each in its own document. The most useful part was the list of non-negotiables:

• Pogo bouncing is the main way to move. There is no conventional jump button.
• Skill decides races; cosmetics never change physics.
• In ranked races, players never collide physically.
• Rewarded ads are opt-in; no ad after every death.
• No package, service or paid SDK is added silently; the decision is documented first.

The pack also had a "don't do this" folder: earlier concept images that were rejected for looking too much like Fall Guys. Showing the agents what the target is not, as well as what it is, cut the art-direction debate short. The name was chosen with the same care: once names like Pogo Panic, HopBound and Hopspire turned out to be taken, BOINGWARD stayed. The document says it plainly: not finding a name in search results is not trademark clearance, and that check comes before launch.

Why Godot instead of Unity?

The pack was written for Unity 6 and C#. The same morning, before the first commit, we moved to Godot. The reason went into the project's rules file: a Unity project can only be open in one editor at a time, batch build cycles are slow, and binary scene files plus .meta files create merge conflicts between agents working in parallel.

In Godot, scenes, code and resources are plain text. Agents can import and run tests from the command line without ever opening the editor: godot --headless --path game -s tests/run_tests.gd. That is what made several sessions on one project possible. The stack became Godot 4.7.2, statically typed GDScript, the Mobile renderer and the Jolt physics engine.

Parallel sessions: everyone owns a folder

The first plan had three sessions, each with the folders it owned written down:

• Lead: pogo physics, integration, tests, export settings.
• B: touch input, camera, UI, haptics, settings.
• C: course, visual style, sound.

Each session worked in its own git worktree on its own branch and only touched its own folders. Shared files such as project.godot or the pogo tuning resource could only be changed by the lead; the others wrote their requests into their reports. Small contracts connected the pieces. The input node, for example, exposes only two things: get_move() for the stick direction and consume_look_delta() for the camera drag. The pogo emits bounced, state_changed and respawned signals. The camera team never needed to know the pogo's internals, and the pogo team never needed to know about the touch screen.

As the day went on, more sessions joined: performance, multiplayer networking, the platform kit, section replay, achievements, the level list and mascot animation were each built on their own branch and merged into main.

There was one snag. When several sessions ran the full test suite on the same Mac at once, the CPU maxed out and timing-sensitive network tests failed at random. The fix was simple: the test script takes a machine-wide lock, only one full run happens at a time, and the others wait their turn.

How the day went

Times come from the commit log; work done on a branch can be timestamped before its merge.

Time	What happened
8:47	Godot baseline commit: pogo physics, tests, lab scene
9:11	iOS export preset; debug build installed on an iPhone 15 Pro Max
9:38	Course, pogo, camera, UI and audio merged into one scene
10:01	First platform kit (9 pieces)
10:29	Multiplayer core: versioned protocol, authoritative race server, bots
11:23	Custom splash screen
1:40 p.m.	Checkpoints only count when you land on their pad
2:17 p.m.	Section replay: every attempt at a section plays back at once
2:27 p.m.	Achievements and stats service
3:38 p.m.	Second platform kit: 24 more types
4:48 p.m.	Air tricks: state machine, reward, bail
4:58 p.m.	Level list and medal times
5:34 p.m.	Main menu
5:39 p.m.	Climb mode: one hand-built tower about 1 km tall
6:06 p.m.	Last commit of the day

Tests are the only proof that something works

The most important line in the rules file, in my view, is this one: "Never claim a feature works unless it was run. If something can only be verified on a phone, say exactly that." Agents write code very fast; the only thing that shows fast code actually works is tests.

By the end of the day the repository had 33 test files and 15 separate test suites: physics, UI, both platform kits, the course, networking, replay, achievements, the climb, levels, the menu, performance and mascot animation. About 26,800 lines of GDScript in total. On top of all that sits one more check: the same physics test runs at 30, 60 and 144 frames per second, and the results must match exactly. I explain how in the pogo physics post.

The most useful tests turned out to be the course bots. A bot tries every hop one by one with the real pogo physics; if even a bot cannot reach a platform, the course is wrong. That part is covered in detail in the level design post.

What the phone told us

The phone showed something the computer did not. On an iPhone 15 Pro Max the game held 60 frames per second, but frame times were uneven: 23.4 milliseconds at the 95th percentile. The cause was the 120 Hz display refresh clashing with the 60 fps cap, so frames arrived at a mix of 8, 17 and 25 millisecond intervals. With high refresh turned off, the same measurement dropped to 17.3 milliseconds. A 120 fps mode came back later with physics interpolation, as an option in the settings. With Kalecik we had seen 120 Hz heat the phone; that story has its own post.

My part

The agents wrote the code, but I set the direction. I rejected the Fall Guys-like visuals. The air tricks came from one sentence of mine: "if it pulls off a cool move, it should bounce higher." The agent turned that into a risky, optional reward system; the details are in the trick design post. I tried every interim build on my phone, and the multiplayer server was tested on a real network with eight bots over my phone's hotspot. The bug that test found is in the multiplayer post.

What is ready and what is not

A lot came out of one day, but not all of it is finished. The honest list:

• Playable: the Spire course, the climb mode, medals, achievements, section replay, settings.
• In the code, hidden from players: online racing. The server and its tests are ready; the menu button is hidden.
• Half done: the physics and animation for air tricks are in, but the on-screen TRICK button is not wired to input yet.
• Not measured: performance on any Android device, and a five-minute heat trend on the iPhone.
• Store: the game is not on the App Store or Google Play, and the menus are only in English and Turkish for now.

I keep the current status on the BOINGWARD page.

The rest of the series

1. Pogo Stick Physics in Godot: A Character That Bounces by Itself
2. Level Design from Measured Metrics, Checked by a Bot
3. Risk and Reward: Designing Air Tricks for a Pogo Game
4. Cheat Checks on Mobile Networks: Server-Authoritative Racing in Godot

Frequently Asked Questions

Can you really build a game in one day?

A playable prototype, yes; a store-ready game, no. BOINGWARD's first day produced the core gameplay, two modes and a lot of tests. Store art, device testing, language support and switching on the online mode are still in progress.

Unity or Godot for building games with AI agents?

If you plan to run several agents on one project in parallel, Godot's plain-text files and editor-free test runs make life much easier. Unity's single-editor lock and binary file merges make that setup hard. With a single session, the difference is smaller.

Don't parallel Claude Code sessions break each other's work?

Without rules, they do. Three things worked here: each session had its own worktree and its own folders, only the lead changed shared files, and the sessions talked through small written contracts. A lock that allows only one full test run at a time also ended the random test failures.