AI Agents Built My Game in Godot, Then Ported It to Unity. Here's What I Learned

Crush Depth is a submarine game. You dive from a rig, salvage wrecks, watch your air and your hull, and get back up before something goes wrong.

Every line of it came from Claude Code agents. I write the asks, look at the screenshots and play the builds. I don't write code and I don't open the editor. The Godot version got to about 38,450 lines of GDScript and 124 Python tests.

Here's the 30-second trailer, cut from in-game footage of the Godot build:

Building that way changes what you want from an engine. These are the lessons that held up.

Agents need to play the game with no screen

The most useful thing in the repo isn't game code. It's a small TCP bridge. The game listens on a local port and takes one JSON command per line. Get the state, step a few frames, press a button, take a screenshot, quit.

Tests and agents play the game through it, headless, with a fixed seed. In lockstep mode, two runs with the same seed give the same state.

That bridge is what made the engine switch cheap. The Unity build answers the same commands with the same JSON. So the Python tests, the MCP server the agents use to see the game, and the playtest bot run against both engines. About 92 of the 124 tests talk only to the bridge. They run against Unity as they are, once the systems they test are ported.

If you're building a game with agents, build this first.

Stop the agents guessing APIs

The models were trained on older engines. Left alone, they write Godot 3 code in a Godot 4 project. In Unity they write rb.velocity, which is now linearVelocity. Some of these compile and do the wrong thing. Some don't compile at all: GetInstanceID() is a compile error in Unity 6.7.

Two things fixed it:

1. A lookup tool for each engine. godot_api.py and unity_api.py answer from the exact engine source and manual for the version the project pins. If the tool says "no member", the member doesn't exist and the agent doesn't use it.

2. Hooks on every file edit. They block outdated API and print the lines to fix. The Unity hook also blocks hand edits of scene and prefab files, so agents change scenes through editor scripts.

Each engine also has a doc of what changed since the version the models know, plus the gotchas. The Unity one lists 54. Here's one from Godot. Jolt physics is the default only for projects made in 4.6 or later, so this project still runs Godot's own physics. It's the kind of fact an agent gets wrong unless something stops it.

This was the biggest single jump in agent output quality, and it's cheap to build.

Pick the engine on look and agent effort

Godot wasn't getting close to the key art, so I asked the agents for a Unity spike. The first round compared licences, build sizes and edit-to-test times. I threw that conclusion out. What mattered was how close each engine got to the key art, and how much agent effort it took to get there.

So round 2 tested the look. An agent exported the real Godot scene: 147 meshes, about 7,300 placements and 289 textures, plus the lights, decals and fog. Unity editor scripts rebuilt it in HDRP from code, with the same assets.

Then fresh agents judged it blind. Each judge saw the key art and two unlabelled frames in a shuffled order. They scored each frame out of 10. Unity won 12 of 12 picks across two views and two sets of frames. Its mean scores ran from 5.5 to 6.2 and Godot's from 3.8 to 4.3.

That result has limits, and the write-up kept them:

1. The judges are agents, not players.
2. Some of Godot's faults were tuning. The dark fog band, the warm grade and the heavy marine snow could all be fixed in Godot.
3. Neither engine is near the key art yet.

So I played the Unity build myself. My note back to the agents was: "unity is the clear winner, lets green light a full port. It looks stunning."

Agents make a test port cheap

The first Unity rebuild of the scene took 56 minutes. The agent hit 12 blockers on the way, and each one took between 2 and 14 minutes to fix.

A few examples:

• Every light was off, because Godot's light masks went through a float cast and came out as 0.
• The kelp rendered red, because HDRP's translucent material uses a skin profile by default.
• The fog didn't apply, because the volume profile saved empty.

None of these are hard, but each one eats an afternoon when you hit it by hand. The agent logged each blocker with its start time, end time and fix, which is how I have the numbers.

Test on your weakest device before you pick a render path

The game has to run on a Steam Deck. So before the full port started, the spike scene went on the Deck with a 60-second bench. The target is 30 fps.

Around the same time, Unity marked HDRP as deprecated in Unity 7, with support through the first Unity 7 LTS. That settled it, and the port went to URP. It costs some look: URP has no volumetric fog, so the light shafts are gone and the frame reads flatter. New URP features in 6.7 (GTAO, screen-space reflections, AgX tonemapping, Surface Cache GI) win some of it back. Getting the Deck to 30 fps at native is its own lane in the plan.

A beta engine brings its own bugs

I pinned the port to the Unity 6.7 beta for those URP features. That has a price. On day one the agents found:

1. -nographics breaks URP's GTAO, so any step that touches the renderer needs a GPU.
2. URP volumetric fog is in the 6.7 source, but it's compiled out.
3. Surface Cache GI with screen-space decals fails to compile on Metal.

Each one went to the render lane with a workaround in code.

Plan for many agents from day one

I run several agents at once, each in its own git worktree. Unity doesn't make that easy out of the box. The editor locks its project folder, and each worktree needs its own Library folder of about 5.7 GB.

The fix is to seed each new lane's Library with an APFS clone of a warm one. A new lane is then ready in 74 seconds, against 223 seconds for a cold import.

On my M2 Max with 32 GB, four Unity jobs at once was the ceiling. Each job took 93 seconds and 6.6 GB of RAM stayed free, with no swap. So there's a hard cap of four Unity editors across all agents, and every Unity job goes through one script that waits for a slot.

What I've checked, and what I haven't

Checked:

• The blind look test, with the limits above.
• The Deck numbers.
• The first port lane. Unity's check script passes from a clean clone in 113 seconds. The existing smoke test passes against the Unity player through the same bridge.

Not checked yet:

• The full game in Unity. The sub, the cockpit, the world, the creatures and the surface are still in their own lanes.
• 30 fps on the Deck at native resolution with URP.
• A blind look test on URP. The frames that won were HDRP. I moved to URP on my own eye.

What I gave up

1. The Godot game. It's frozen now. It stays runnable as the reference the Unity port is checked against, then it goes to an archive.

2. HDRP's water and volumetric light. I traded them for Deck performance and a pipeline with a future.

3. A stable engine. A beta has its own bugs, and the agents now spend time on them.

4. Disk and memory. The Unity editor is 9.2 GB, every lane needs its own Library, and a single Unity job peaks around 10 GB of RAM.

Ask what agents can drive

When agents do the building, the engine question changes. "Which engine can agents drive, test and fix with no screen? And how close does it get to the look I want?" Cost and install pain barely register next to that.

The reusable parts of this setup are on GitHub at github.com/Danm72/ai-gamedev-kit. It's MIT licensed. In it:

• 7 Claude Code skills: asset-forge, big-feature, feature-breaker, game-manager, look-critic, playtest-bot and steam-deck. Each one lists what it assumes about your project.
• The API lookup tools: godot_api.py and unity_api.py answer from the exact engine source, so the agent stops guessing.
• The guard hooks: they block Godot 3 syntax and outdated Unity API on every edit.
• The JSON bridge: a Godot version, a Unity version, a Python client and an MCP server, so one test suite drives either engine.
• The two engine cheat sheets for Godot 4.7 and Unity 6.7.