Godogen — From Prompt to Playable Game

Godogen — From Prompt to Playable Game

What Is This?

Godogen is a system that turns a sentence into a playable game. You describe what you want — "a 3D snowboarding game with procedural terrain and tricks" — and an AI pipeline designs the architecture, generates the art, writes all the code, tests it visually, and delivers a working Godot project. The entire process runs autonomously, with the human receiving progress updates over Telegram, Slack, or another connected channel.

It is not a game engine, a code generator, or an asset marketplace. It is an autonomous development pipeline, orchestrated by AI, that performs the full creative and engineering process from concept to playable build.

The Problem

Building a game, even a simple one, requires a rare combination of skills: software architecture, graphics programming, art direction, asset creation, and relentless debugging. The typical indie developer spends weeks wiring up boilerplate before reaching the interesting parts. Prototyping a game idea to see if it's fun takes days or weeks, not minutes.

Large language models can write game code, but they struggle with the full picture: maintaining visual consistency across dozens of assets, debugging spatial bugs that only appear on screen, and coordinating the dozens of interdependent files that make up a real project. Asking an LLM to "make a game" produces impressive demos that fall apart the moment you look closely.

The Approach

Godogen solves this by decomposing game development into focused stages — art direction, architecture, asset generation, implementation, visual QA — and encoding deep domain expertise into each one. Rather than one monolithic prompt trying to do everything, each stage has focused instructions, clear inputs, and clear outputs. The stages communicate through structured documents, not conversation, which means the system scales without drowning in context.

The system is implemented as three skills: **godogen** (the orchestrator and task executor, running the full pipeline in a single 1M-token context window), **godot-api** (Godot class API lookup, forked to avoid loading large docs into the main context), and **visual-qa** (visual quality assurance via Gemini Flash and Claude vision, also forked). The godogen skill loads stage-specific instructions progressively — reading each sub-file only when that pipeline stage begins — so the context window stays focused throughout a multi-stage run.

The repository carries two parallel source trees of these skills — one for Claude Code (`claude/`) and one for Codex (`codex/`) — so either host agent can run the pipeline. A `publish.sh` in each tree drops the runtime skills into a fresh game repo, and the host agent's slash command (`/godogen`) then drives the build.

The key insight: **visual verification closes the loop.** Every piece of work is tested by capturing actual screenshots from the running game and analyzing them with a vision model. This is how a human