Run Claude Code Game Studios or godogen in a live Godot editor

Six minutes into the run, Coin Climb's code was finished and its unit test passed. Claude Opus 5.5 then played the level coin by coin, reached the win screen, and captured the frame. The line telling you to press R sat on top of a dimmed ledge and looked boxed in. No parse check, unit test or headless run catches that. A picture of the running game does.

It moved the text onto its own bordered panel, played to the win screen again, and filed both frames, before and after, under production/qa/evidence/ in the game's folder. That is the rule of the repo it was running, Claude Code Game Studios, carried out against a live Godot 4.7.2 editor through Flockbay's MCP server.

This page shows how to set that up, for Claude Code Game Studios and for godogen, and what each did in one real run: the prompt, the tool calls, and their real output.

Claude Code Game Studios, by Donchitos, is a template that turns a Claude Code session into a studio: 49 agents from directors down to specialists, 74 skills run as slash commands such as /setup-engine, /create-stories and /dev-story, hooks and path-scoped coding rules, with agent sets for Godot 4, Unity and Unreal Engine 5. One setting, modes.rigor, picks how much process it asks for, from a one-page brief at minimal to all eight sections of a game design document at full.

godogen, by htdt, is a generator rather than a template. It publishes a thin set of files into a game repo, a runtime manifest, a one-page engine guide and an asset-generation skill, and the agent builds the game from them, for Godot in GDScript or C#, Bevy, Babylon.js or three.js, with Claude Code or Codex.

As of 2 November 2026 they have 33,000 and 7,273 stars on GitHub, and both are MIT licensed. You might expect repos that size to be about their agents. Read their READMEs and the rule they hold hardest is about the game. Claude Code Game Studios will not close a story that changes what the player sees until the game has been launched, looked at, and a screenshot kept in production/qa/evidence/, at every rigor level. godogen's manifest has the agent judge its progress by the game running, not by a build that compiles, and show the result working rather than say it works.

What neither repo can give the agent is the running game itself. That comes from the engine and the tools around it. Flockbay is a free AI game maker built on Godot, and its desktop app serves those tools over MCP: Claude Code runs the game headless or in the Game screen, plays it with input actions by name, reads stdout and Godot's errors, reads live properties off the scene tree, and captures the viewport, all against the Godot editor the app has open.

The repos: Donchitos/Claude-Code-Game-Studios on GitHub, htdt/godogen on GitHub.

A 64-bit Windows 10 or 11 PC, a Mac with Apple Silicon, or an x86_64 Linux machine. Both runs on this page were on Windows 11.

Claude Code, on a paid Claude plan or an Anthropic Console account. The runs used Claude Code 2.1.309 on Claude Opus 5.5, with Flockbay's server as its only MCP server.

Flockbay, which brings its own Godot: you do not need Godot on your PATH. In both runs Godot ran only through Flockbay's tools, on the Godot 4.7.2 the app bundles.

For Claude Code Game Studios, Git, plus what its README lists for its skills and hooks: Bash, which comes with Git for Windows, and Python 3. For godogen's publish step, Python 3 and rsync, which means macOS, Linux, or WSL on Windows.

Install Flockbay and open a game. Both runs started from a new, empty 2D game made by the app, saved under Documents\Flockbay with the game's name. A Godot project you already have works too: press Open Godot project… and Flockbay asks before it adds anything to it.

Leave the game open. The tools that change scenes work through the Godot editor the app has open, and the tools that play the game start it there.

The Flockbay app writes this for you with the real paths filled in: open Connectors, press Set up on Connect your agent (MCP), press Turn on, pick Claude Code and press Copy. The three paths are specific to your machine and stay the same from one sitting to the next, so you paste it once. Below is the shape, with the paths as placeholders.

Paste it into PowerShell and press Enter. It registers one MCP server, flockbay, with --scope user, so Claude Code finds it in any folder, the game's included. In a Claude Code session, /mcp should list flockbay as connected. How to make games in Claude Code walks this step in full, with its troubleshooting.

Its README starts a project by cloning the repo. A Flockbay game is already a folder with project.godot in it, so clone the repo somewhere else and copy the studio in beside project.godot: .claude/ with the agents, skills, hooks and rules, CLAUDE.md, project.yaml, and the design/, docs/, production/ and src/ folders. Keep its LICENSE with it, as MIT asks. That is exactly what went into the game for the run on this page, unchanged.

Change My Game to your game's folder name. A new Flockbay game has none of these, so nothing in it is overwritten.

Then open a terminal in the game's folder and start claude there. Its README says to start Claude Code at the project root, the folder with CLAUDE.md and project.yaml in it: from a subfolder, the studio's hooks, deny rules and permission prompts do not load.

Setup in its own words: Donchitos/Claude-Code-Game-Studios on GitHub.

The run on this page used Donchitos/Claude-Code-Game-Studios at commit 05ad7c8, of 19 October 2026, and this prompt, word for word. It asks for /setup-engine at minimal rigor, the README's default, and for a game small enough to finish: one screen, one enemy, primitives for art.

The prompt also told Claude Code to run and test the game only through Flockbay's tools, and named them. That line is there for this page, so that every run and check is a tool call we can show you. Leave it out and Claude Code has the same tools; the line only made sure every check went through one.

Asking for input actions by name, move_left, move_right, jump and restart, is worth keeping. It is what lets the agent press jump in the running game rather than guess a key.

Claude Code ran /setup-engine first. flockbay_godot_status reported the Godot 4.7.2-stable editor open on the game, which matched the pin, so the skill filled in CLAUDE.md, technical-preferences.md and VERSION.md for GDScript and set modes.rigor to minimal in project.yaml. Its own setup check reported one mismatch, the expected one: the test command points at gdUnit4, which /test-setup installs and the run did not.

At minimal rigor the studio's design is a one-page brief. design/game-brief.md names the game, Coin Climb: eight coins on a single 1280×720 screen of ledges, one walker on the floor, a win screen, and a list of what is out of scope. Five stories followed under production/epics/coin-climb/, one per feature. The handover says it wrote the code itself rather than running /dev-story on each story.

The input map went in through flockbay_set_input_action, one call per action, and the viewport size and the 2D physics layer names through flockbay_set_project_settings. Ten scripts and five scenes later, flockbay_script_errors answered with Godot's own parse check: no errors in 10 scripts.

The coin counter got a test scene that quits with exit code 0 on a pass and 1 on a failure. flockbay_run_headless ran it on the bundled Godot and returned the exit code and the scene's stdout, below as it came back. A second headless run booted the main scene for 3 seconds: exit code 0, 0 errors and 0 warnings.

A headless run proves the game starts. It cannot show you a win screen. For that the run asked flockbay_run_headless for a drawn background run, which renders the game at 1280×720 in a window off your screen, muted, and leaves your own Play alone.

The route took eight legs, low-left ledge to middle, middle to high-left, up to the top, and back down the right side to the floor. Each leg was a flockbay_game_input call: hold a direction for a number of physics ticks, press jump on a given tick, watch that coin's collected signal, and sample the player's position on the way. Below is the second leg as it came back. The drop to the floor's right corner carried the player past its coin to the wall, x 1246 against the coin's 1210, so one more short step left took it.

The samples settled the numbers a playtester argues about. Run speed is 320 px/s. A jump rises 166 px, from y 660 to an apex of 494, which clears the 120 px between ledges. The last coin sat on the enemy's path, so the call waited for the enemy to turn and walk left past x 600, then ran in behind it.

Then the edges: touching the enemy emitted died and put the counter back to 0 with the coin back in place; restart reset the player to (60, 660); and a run-and-jump from x 400 cleared the enemy walking toward it, with no died.

The eighth coin brought up the win screen, and the frame showed the hint line over the dimmed ledge. The fix put the text on a PanelContainer, and flockbay_scene_tree showed it in the scene the editor had open. A fresh drawn run then set the player onto each coin with flockbay_game_input's set steps, since the real route had already been played, and the new win screen is the first picture on this page.

Restart from the win screen was checked with flockbay_game_screenshot, which reads values from the same frame it captures. Below is what came back: the player back at (60, 660), the counter at 0, the win screen hidden.

The last check was a real Play in the Game screen, the one you press, with a short burst of input: flockbay_play reported 0 errors and 0 warnings. The playtest record is production/qa/playtest-2026-11-02.md, a table of every check, how it was run and what was read back.

From start to handover: 10.7 minutes, 58 model calls on Claude Opus 5.5, and about $4.47 at API prices. The run went through a Claude subscription, so that figure is an estimate, not what it was billed.

The 41 Flockbay calls were 15 flockbay_game_input, 6 flockbay_game_get, 4 flockbay_run_headless, 4 flockbay_set_input_action, 3 flockbay_game_screenshot, 2 flockbay_script_errors, 2 flockbay_scene_tree, 2 flockbay_godot_status, and one each of flockbay_play, flockbay_set_project_settings and flockbay_guide. Beside them were 26 file writes and 20 shell commands, about half of those reading the studio's own skill references and templates.

The handover left three things to you: a lead's sign-off on how the level looks, which the studio's rules require for a visual story, how the game feels to play, and a real gamepad.

godogen's publish.sh renders its files for one engine and one agent into a target folder. For a Godot game in GDScript on Claude Code, point --out at the game's folder. It writes CLAUDE.md from godogen's runtime manifest, godot-gdscript.md, the asset-gen skill under .claude/skills/, a .gitignore if there is none, and runs git init. Keep godogen's LICENSE.md with them, as MIT asks.

publish.sh is a Bash script that needs Python 3 and rsync, so run it on macOS, Linux, or WSL on Windows, where a game in Documents\Flockbay is at /mnt/c/Users/ followed by your user name and /Documents/Flockbay/. The PC these runs were on has neither, so the same substitutions were made by a short script; the files are the ones publish.sh writes. Leave off --force: it empties the target folder first.

godogen also publishes for Codex with --agent codex, which writes AGENTS.md and .agents/skills/ instead. A Flockbay game already has an AGENTS.md, Flockbay's note on how to run that game, and publishing for Codex replaces it. We ran the Claude flavour only.

Publishing, in its own words: htdt/godogen on GitHub.

The run used htdt/godogen at commit 40542b6, of 16 October 2026, published as above, on Claude Code 2.1.309 and Claude Opus 5.5, in its own new 2D game. The prompt asks for the same game as run 1, without the studio's setup line. godogen has no setup step: its manifest points the agent at the engine guide and leaves the rest to the run.

It read godot-gdscript.md, set the four input actions and the project settings through Flockbay's tools, and wrote five scripts and one main scene: a player with coyote time, jump buffering and a short hop, eight floating platforms, ten spinning coins, a patrolling blob, and end screens for a win and a loss. flockbay_script_errors found no errors in 5 scripts, and it kept the project's status in README.md, as godogen's manifest asks.

After playing each platform hop on its own, the run tested a stomp: it set the player at (645, 450), above the blob, let it fall, and sampled position, velocity and dead twenty times a second. The rows below are the end of that call, trimmed. The player fell onto the blob and dead turned true on tick 507, with Godot's overlap reported a frame after the feet were already inside the blob.

The fix had the blob check contact itself every physics frame, comparing where the player's feet were on the frame before. The same drop afterwards bounced on tick 30 with no died. The bounce was small, which showed a second bug: the short hop for an early release was cutting it too, so the cut now applies only to the player's own jumps.

The third bug came from a side-on hit. The knocked-out player kept collecting coins as it fell off screen, so the HUD read 1/10 while the lose screen said 0/10. A dead player no longer collects coins.

godogen wants a result proven, not claimed. The run proved it with flockbay_play at a fixed 60 frames per second and seed 7: one Play in the Game screen from the first frame, 40 input events over 995 physics ticks, every one an input action, with the died signal watched. The first attempt reached 9 of 10 coins, the last hop 40 px short, so the final run right was held longer and the Play went again.

The second Play collected all 10 coins, stomped the blob and reached the win screen at 14.8 seconds, the second picture on this page. Below is the part of flockbay_play's answer that says so: no emission of died, and 0 errors and 0 warnings. After the coin fix, a third Play set up a side-on hit: died fired on tick 22, and flockbay_game_screenshot read coins_collected = 0 and state = Lost from the frame.

For a run you were not watching, godogen's guide also asks for a 15 to 20 second clip recorded with Godot's movie writer from the shell. This run's prompt kept Godot off the shell, so it made none and said so in its handover.

From start to handover: 9.7 minutes, 48 model calls on Claude Opus 5.5, and about $3.18 at API prices, again an estimate for a run that went through a subscription.

The 47 Flockbay calls were 25 flockbay_game_input, 4 flockbay_play, 4 flockbay_script_errors, 4 flockbay_set_input_action, 3 flockbay_run_headless, 3 flockbay_game_get, 2 flockbay_game_screenshot, and one each of flockbay_set_project_settings and flockbay_guide. Beside them were 7 file writes, 10 edits and 7 shell commands.

godogen wrote no design documents and spent more calls on play: 25 input calls against the studio's 15, and three bugs found by playing against the studio's one. That is one run each, on one small game, so read it as what happened, not as a ranking.

Neither repo was changed for these runs, and neither needed to know about Flockbay. Claude Code Game Studios brought the setup skill, the brief, the stories and the QA rule that a visual change needs a kept screenshot. godogen brought the manifest, the engine guide and the rule that the running game, not the build, is the judge.

Flockbay brought what those rules ask for, as tool calls on a live Godot editor: flockbay_script_errors for Godot's GDScript parse errors without running anything; flockbay_run_headless for an exit code and stdout, or a drawn run off your screen; flockbay_play for the Game screen, at a fixed frame rate and seed when the run needs to repeat; flockbay_game_input for input actions on exact physics ticks, with signals watched and properties sampled; flockbay_game_get for live values; and flockbay_game_screenshot for the frame itself, with values read from the same frame.

Everything they made is a plain Godot 4 project in a folder on your machine. Open it in Godot's own editor, read the GDScript, and commit it to Git.

Whether Coin Climb is fun. Both agents measured their jump and both reached the win screen. Claude Code Game Studios' handover said it plainly: how the game feels to play, and a real gamepad, are yours to check. Judging a game you did not code is where that part starts.

These are two runs, one per repo, on Windows 11, with Claude Code and Claude Opus 5.5, on a one-screen game. A larger game at a higher rigor level runs longer and writes more documents, as Claude Code Game Studios' README says of its own tiers.

Flockbay's server also connects to Codex, Cursor and other MCP clients, and the Godot MCP guide has the setup for each. These two repos were run on Claude Code only.

Connecting Claude Code to Flockbay is free, and both repos are free and MIT licensed. You pay Anthropic for Claude on the plan you already have. At API prices the two runs here would have cost about $4.47 and $3.18; on a subscription they came out of its usage.

Neither run generated art or sound: the prompts asked for primitives. godogen's asset-gen skill uses its own local tools or the paid APIs it names, on your keys, if you ask it for assets.