Claude Code can make real games: not just the single-file canvas demos that go round on social media, but Godot projects with scenes, imported art, audio, touch controls and a build that runs in a browser. We use Claude Code for game development every day, because it is the agent that builds every game in the vbgnt studio: more than fifty of them since July, 2D and 3D, most of them from a paragraph of description.
It is also the thing we have watched fail in the most specific ways. This is what we have learned about pointing Claude Code at game development: what it makes well, which engine to give it, how to set it up, and the failures that only show up once you have run it a few hundred times.
What kind of games can Claude Code make?
Small, complete games with one strong idea. Across the studio's gallery that means arcade games, platformers, puzzle games, kart racers, top-down shooters, cozy 3D exploration, card and board games, and online multiplayer for two to eight players. A first build from a good brief typically has one mechanic, a coherent art direction, controls for keyboard, gamepad and touch, menus, sound, and an exported build that boots.
Where it struggles is the same place every generator struggles: large amounts of authored content, systems whose parts interact in ways nobody wrote down, and feel. Claude Code can make a jump. It cannot tell that the jump is floaty, because it has never held a controller. That judgement is still yours, and the loop that works is short: play for ninety seconds, describe what felt wrong, let it change the code, play again.
It also does noticeably better at genre pastiche than at inventions from nothing. A 16-bit mascot platformer or a top-down twin-stick shooter comes with a dense, coherent set of conventions it already knows. A game with no precedent needs a brief that spells out what the player does with their hands, which is covered in how to prompt a game into existence.
Which game engine is best for Claude Code?
Godot 4, for most people, and the reasons are structural rather than a matter of taste. Claude Code works by reading files, writing files and running commands. An engine suits it to the degree that everything important is a text file and everything useful is a command.
| Engine | What suits Claude Code | What gets in the way |
|---|---|---|
| Godot 4 | Scenes and resources are readable text; GDScript is small; the editor runs headless to import, export and run the game; MIT licence | Training data mixes Godot 3 and 4 idioms; the web export has its own rules |
| Phaser or Three.js | Plain JavaScript, fastest route to a first frame, runs in any browser with no export step | No editor, no scene format, no asset import: you are writing the engine's missing half yourself |
| Unity | C# is well represented in training data; large asset ecosystem | Scenes and prefabs are large YAML files full of IDs; the editor is heavy to run headless; needs an MCP bridge to see anything |
| Unreal | Top-end rendering | Blueprints are binary; builds are slow and large; the least agent-friendly of the four |
The decisive feature is that Godot runs without a window. godot --headless --export-release Web produces a build from the command line, and the same binary can run the game and print its errors. That closes the loop: Claude Code writes a scene, exports it, reads what went wrong, and fixes it before you ever see it. With an engine that needs a person clicking in an editor, the loop runs through you.
If you only want to try a mechanic tonight, a single HTML file with Phaser is quicker and entirely reasonable. The difference shows up on the second day, when you want art that imports at the right size and a build you can send to someone.
How do you set up Claude Code for Godot?
Five things, roughly in order of how much they matter.
- Put the Godot binary on the PATH, at one version. Tell Claude Code which version in a
CLAUDE.mdat the project root, and tell it to check the API against the engine rather than memory. A model's training data is a blend of several engine versions, and an agent that can run the engine finds a mismatch in a second. - Give it a way to run the game and read the result. A script that exports the web build, loads it in a headless browser, and prints boot time, frame rate and console errors turns "I think this works" into a checked claim. Ours is the single most valuable file in the pipeline, covered in the agent plays its own game before you do.
- Give it eyes. Screenshots of the running game, and of generated 3D models from several labelled angles, let it catch the problems code review never will: a character facing backwards, a camera inside a wall, text off the edge of a phone screen.
- Write down your conventions as skills. Claude Code loads skills (folders with a
SKILL.mdand reference files) when the task matches. Ours cover 3D asset generation, 2D pixel art, Blender clean-up, online multiplayer, store marketing and inspecting 3D models. Every rule in them is a bug we hit once and did not want to hit again. - Add an MCP server if you work in the editor. If you keep the Godot editor open and want Claude Code to see the scene tree or run the game from it, a Godot MCP server bridges the two. We compared the options in AI tools for Godot, sorted.
What goes wrong when Claude Code builds a game?
The failures below are all ones we have seen in production, several of them more than once. None of them is visible by reading the code, which is the general lesson: generated games fail on load, not in review.
It writes Godot 3 into a Godot 4 project
The most common failure, and the most boring. KinematicBody2D instead of CharacterBody2D, yield instead of await, export var instead of @export. The parse error tells the agent immediately, provided something parses it. This is the cheapest reason to give Claude Code the engine rather than just a folder.
It kills its own process
This one took us a while. A game preview hangs, the agent decides to clean up, and it runs something like pkill -f godot or a loop over /proc/*/cmdline killing anything that mentions Godot. The Claude Agent SDK had passed the whole system prompt to the CLI as a command-line argument, and our system prompt mentions Godot. So the agent's own process matched, and the turn died with exit code -9, which looks exactly like running out of memory. We now pass the system prompt as a file and tell the agent to kill by process ID. If you script Claude Code yourself, check what is in its command line.
It waits on a render longer than the CLI will
Rendering 3D in a container without a GPU is slow: we measured 1.6 seconds per frame for a heavy scene under software rendering, so a routine preview can run past ten minutes. In print mode the CLI stops waiting on background tasks after ten minutes by default and ends the turn with whatever interim message it had, while the orphaned render carries on eating CPU under the next turn. The fix was not more patience. It was skipping the renderer on every frame nobody was going to look at, which took the same preview from about thirteen minutes to 41 seconds.
It ships a game with no sound on the web
Godot's web export plays audio differently from desktop. Adding an audio bus at runtime, putting effects on a bus, or fading a playing sound's volume up from silence all work on desktop and quietly fail in a browser, sometimes muting the whole game. Claude Code followed a recipe of ours that did exactly those things and produced a batch of silent games. That was not a model problem: a different model hit it too. The recipe was the problem, and the fix was a short list of web audio rules in the skill.
Touch controls whip the camera
On phones, Godot turns the first finger into mouse events so that menus work. A game whose camera reads mouse motion then jumps several hundred pixels when a second finger lands, because the engine's web build computes the drag from the wrong touch. Claude Code writes perfectly reasonable camera code that fails only on a real phone with two thumbs down. The test that caught it was playing on a phone; the rule that prevents it is now in the skill.
Generated 3D models face the wrong way
Rigged models from 3D generators follow glTF's convention and face +Z, while a Godot character controller conventionally moves along -Z. Claude Code will confidently assume one or the other. The fix is to render the model from labelled angles and measure its facing, then rotate it in the scene, rather than trusting what any model "usually" does.
Is Claude Code enough on its own?
For a programmer who is happy to own the pipeline, yes. Everything above is solvable with a Godot install, a test script, some skills and a few weeks of finding the bugs. That is roughly what we did.
If you would rather describe a game than maintain the harness around the agent, that harness is what vbgnt is: Claude Code running in a warm cloud machine with Godot, the asset generators, the headless browser tests and the web audio rules already in place, publishing to your own arcade and exporting to Windows, macOS, Linux, Android and iOS. The pieces are described in what an AI game agent actually needs.
The two also combine. The studio is an MCP server, so Claude Code on your own machine can create a game, pull down the Godot project, edit files where a prompt is too blunt, and push the change live:
claude mcp add --transport http vbgnt https://api.vbgnt.com/mcpSetup for Claude Code and other clients is on the MCP page.
Frequently asked questions
What kind of games can Claude Code make?
Small, complete games with one strong idea: arcade games, platformers, puzzle games, kart racers, top-down shooters, cozy 3D exploration, card games and online multiplayer for a handful of players. A first build from a good brief has one mechanic, an art direction, controls, menus, sound and a build that boots. It struggles with large authored content and with feel, which needs a person to play the game.
Which game engine is best for Claude Code?
Godot 4 for most projects. Its scenes and resources are readable text, GDScript is small, and the engine runs headless from the command line, so Claude Code can export the game, run it and read the errors itself. Phaser or Three.js is quicker for a one-evening prototype. Unity and Unreal work through MCP bridges but their scene and blueprint formats are much harder for an agent to read and edit.
Can Claude Code make a 3D game?
Yes. Most of the games built in the vbgnt studio are 3D. The hard parts are not the code: generated models need their facing, scale and pivots measured and corrected, and previews in a machine without a GPU are slow enough to need care. Given the engine, a way to screenshot the running game and an asset pipeline, Claude Code handles 3D scenes, cameras and character controllers well.
Do I need to know how to code to make a game with Claude Code?
Not to get a first playable build, but running Claude Code yourself means owning the setup: installing the engine, writing the test script, fixing the environment when a build fails. If you would rather describe the game than maintain that, a studio built on Claude Code, such as vbgnt, does the setup for you.
Can Claude Code publish my game?
Only if you give it a way to. Claude Code can run Godot's export from the command line, but uploading to a store or host needs credentials and tooling. The vbgnt studio publishes every build to your own arcade automatically and exports for Windows, macOS, Linux, Android and iOS, and Claude Code on your own machine can drive it through the vbgnt MCP server.
