An agent can finish a game that compiles perfectly while the player character is stuck under the floor.

Godogen starts from exactly that problem. Alex Ermolaev's project is a set of skills and tools that lets Claude Code or Codex build a complete game for Godot, Bevy or Babylon.js from a description.

The pipeline builds the project, generates assets, launches the engine and then has to prove the result from the running game, not only from source code or a green exit code. Depending on the engine and execution mode, that proof can be a live playable URL or a short recorded clip.

That last part changes the workflow. In a game, compilation proves very little about what the scene actually looks like.

The expected result is visual proof

The current README summarizes the rule as "proof over claims". The agent has to judge the running game and repair failures that show up in the visible result or interaction. For unattended runs, the project asks for a short recorded proof rather than a statement that the build succeeded.

That exposes the project's chosen unit of validation: what the engine actually produced.

Compiling code is only an intermediate milestone.

The repository deliberately stays thin

The current README also says the published repository no longer tries to carry a huge recipe for every engine. It keeps a runtime manifest, a short engine guide and the asset-generation skill.

The idea is to let the agent reconstruct scaffolding and the proof loop from those rules instead of maintaining a mountain of engine-specific templates. Godot, Bevy and Babylon.js remain very different targets, but the common workflow stays compact.

It is a useful reminder that an agentic system is not just a model. It is also a documentation architecture: what knowledge is available, when it enters context and how it is presented.

Assets come from several generators

The pipeline does not ask one model to make everything.

The README assigns Gemini to some reference and character generation, Grok to textures and simpler objects, and Tripo3D to image-to-3D conversion. Animated sprites can use video generation with loop detection.

That means several API keys and a heavier stack than a simple Claude Code skill. Godogen also requires the chosen engine toolchain, Python, system utilities and, depending on the target, Chromium or GPU acceleration for rendering and capture.

The project is MIT licensed, but a full run is not necessarily local or free.

One source can now publish three engine workflows

The source repository can publish target projects for three engines.

Godot output uses C#/.NET projects with scene trees, scripts and assets. Bevy output uses Rust with code-first scenes and local docs. Babylon.js output uses TypeScript/Vite with hot reload and WebGL2 browser capture.

Claude Code versus Codex is then a publish-time packaging choice. The shared source is rendered into the structure expected by the selected host agent.

That architecture is quietly useful: do not maintain three separate workflows for three agents. Keep one source and adapt the packaging at the boundary.

A game becomes a multimodal test

Godogen is still young. Repository demos are not an independent benchmark of the quality or reliability of generated games. A pipeline working on a handful of prompts does not establish general robustness.

But the validation loop transfers well beyond games.

An agent building an interface should inspect the interface. An agent changing a chart should render the chart. An agent producing a PDF should open the PDF. An agent controlling hardware needs feedback from the physical system.

The more perceptible the output, the less useful a purely symbolic test becomes.

Godogen states that principle rather cleanly: until the agent has looked at the frame, it does not really know what it built.