Godogen: publish a thin game repo and let Claude Code or Codex build the Godot, Bevy or Babylon.js game

What Godogen generates, and what it does not

The README describes the flow in one line: godogen, then a game repository, then a game. You describe a game, and an agent builds it, generates the assets, runs the engine and proves the result. This repository holds the generator. You publish from it into a fresh game repository, choosing the engine and the host agent, and the agent then works inside that new repository from a short engine guide.

That design decides who it suits. It is for people curious about autonomous game building who already use Claude Code or Codex and want a structured starting point rather than an empty folder. It is not an engine plugin, not an editor extension and not a template game you can open and play. The README is explicit that this repository is not a game.

A thin published repo, recreated from the guide

A published repository is intentionally small. The README lists what goes into it: a runtime manifest, a one-page engine guide and the asset-generation skill. The agent recreates the rest, including the project scaffold and the capture tooling, from the guide. In the source tree those parts live in prompts/runtime.md, the asset-gen/ skill and three engine guides, engines/godot.md, engines/bevy.md and engines/babylon.md. The publish.sh script renders the runtime layout for the engine and host agent you pick, and the README notes that engine and host are render choices at publish time, not separate source trees.

The engines get different treatment. Godot 4 projects are C# on .NET with build-time scene generation, runtime scripts and Jolt physics. Bevy projects are Rust with code-first ECS scenes and offscreen capture. Babylon.js games are TypeScript with Vite, served at a live URL. Keeping the published repo thin means the guide carries the method and the agent writes the project, which is also why a run is long: very little is handed to it ready-made.

Publishing a Godogen game repo

Publishing takes one command per game, with the engine and the agent as flags:

./publish.sh --engine godot   --agent claude --out ~/my-game
./publish.sh --engine babylon --agent codex  --out ~/my-game
./publish.sh --engine bevy    --agent claude --out ~/my-game

For Claude the published repo gets a CLAUDE.md and a .claude/skills/ directory; for Codex it gets AGENTS.md and .agents/skills/. Passing --force wipes whatever is already at the target before publishing again, so point --out at an empty directory unless you mean to start over.

The prerequisites are the real setup work. Godot projects need the .NET build of Godot 4 on PATH, Bevy needs Rust and Cargo, and Babylon.js needs Node.js 22.12 or newer plus Chrome or Chromium with hardware WebGL2 for browser capture. Every run needs Python 3 with pip, system packages listed in setup.md such as vulkan-tools, xvfb, ffmpeg and imagemagick, and three API keys: GOOGLE_API_KEY for Gemini image generation, XAI_API_KEY for xAI Grok image and video generation, and TRIPO3D_API_KEY for 3D generation. The README says it is tested on Ubuntu, Debian and macOS.

Asset generation across three providers

The asset-generation skill splits work by what each service does best, according to the README. Gemini handles precise references and characters. xAI Grok produces textures and simple objects. Tripo3D turns images into 3D models and provides rigged biped animation. Animated sprites come from Grok video, with loop detection and background removal.

That split is practical, and it also sets the cost and the failure points of a run. Three paid services sit in the loop, each with its own key, limits and output quirks, and a game that needs many characters or animations spends on all three. When an asset comes back wrong, the agent has to notice it in the running game and regenerate it, which is where the next idea in the project comes in.

Proof from the running game, and choosing your involvement

The README's principle is proof over claims: the agent judges results from the running game, either a live URL or a recorded clip, not from a clean compile, so visible defects drive the next iteration. That is the right standard for games, where code that builds can still render a black screen or a character sliding through the floor.

You decide how involved you are by how you frame the task. You can watch the live game, a Babylon.js URL or a Godot or Bevy project you run yourself, and steer at decision points. Or you leave the run unattended and receive a 15 to 20 second proof recording at the end. The agent reads the situation and picks between the two modes during the run. For a first attempt, the live Babylon.js mode gives the quickest feedback, because you see each change in a browser without building anything locally.

Long runs, servers and what is not documented

The README warns that a full generation run can take hours and suggests a server, ideally a GPU instance, because engine rendering and video capture are much faster with hardware acceleration. It recommends tmux or screen to survive SSH drops and the official remote-control interfaces of Claude Code and Codex to check in and steer from any device.

Some things are left open. The README does not say how large a game the approach handles, how much a typical run costs in API calls, or how to take a generated game further by hand once the agent is done. There are no tagged releases in the repository, the last push was on 2026-09-04, and changes are tracked in CHANGELOG.md. The project is MIT licensed, and the demo prompts in docs/demo_prompts.md are the best way to see what kind of game descriptions it was built around.

Editorial conclusion

Try Godogen if you want to see how far an agent can take a small game in Godot, Bevy or Babylon.js, and you have the Gemini, xAI and Tripo3D keys it needs. Publish with ./publish.sh into an empty directory, start with Babylon.js for the fastest feedback through a live URL, and run long generations on a GPU server inside tmux.

Frequently asked questions

Official sources

1. htdt/godogen on GitHub
2. Issues
3. License: MIT
4. Project website
5. README