GodotMaker: AI-Powered Text-to-Game Pipeline

Why I Built This

In game development, especially early ideation and market validation stages, teams often come up with more ideas than they can develop. The usual approach is to discuss and pick one idea for development, only to find out after a couple of weeks that the idea is not viable, making the previous discussion and development efforts wasted. I built GodotMaker to allow individuals to turn their ideas into playable prototypes quickly, validating the feasibility and fun of their ideas. This will significantly speed up the early stages of game development, helping developers find truly worthwhile game concepts faster.

Why Choose GodotMaker

Many tools promise that AI can help you make games. Once you actually try to build with them, the same problems tend to show up:

• You only want to realize an idea, but end up sitting at your computer testing builds, taking screenshots, and feeding the agent step-by-step feedback.
• The platform says it is building your game, but the code and project stay on its servers, making it hard to fully download the work or keep developing elsewhere.
• You may get an interesting demo, but it is not grounded in a mature game engine, so iteration, debugging, extension, and publishing become difficult.
• What is mostly a development workflow gets wrapped in platform markup on token usage and a locked runtime environment.

GodotMaker takes a different path: bring the game idea, let it shape that idea into a GDD, then let agents run through planning, implementation, tests, gameplay runs, screenshots, evaluation, and fixes. When the run finishes, you review a real Godot project on your disk.

The code is yours. The GodotMaker framework is source-available, the workflow is local-first. Want a better game? Refine the idea or GDD and run another iteration.

What Makes It Different

• No-human-in-the-loop by default. Like long-running goal modes in modern coding agents, GodotMaker keeps going after you state the target.
• From natural language to a complete game project. Your input can start as a simple game idea; GodotMaker helps turn it into a design contract.
• The code is yours. The output is a normal Godot project with source files, scenes, assets, tests, screenshots, and reports.
• Design-driven iteration. This is not a one-shot generator. You can keep improving the idea or GDD and keep raising the quality of the game.
• Built on a mature engine. The result lands in the Godot ecosystem, where you can continue debugging, extending, exporting, and publishing.
• No middleman markup. GodotMaker is the workflow layer. It does not resell agent work through a closed platform.
• Source-available framework. The GodotMaker framework is public to inspect, run, modify for permitted uses, and contribute to.
• Driven by GodotMaker CLI. The command-line tool drives the workflow end to end so you can run GodotMaker with minimal manual coordination.

External agent runtimes and model providers, such as Claude Code, Codex, Gemini, OpenAI, xAI, or Tripo, may have their own pricing, quotas, and data policies. GodotMaker keeps the framework source-available, the workflow local-first, and the generated project on your machine.

What The Agents Do

During a run, GodotMaker agents keep moving the design forward:

• turn your idea into GDD.md, tasks, scenes, systems, assets, and acceptance criteria
• implement gameplay in Godot
• write gdUnit4 unit tests while writing code
• create end-to-end tests that operate the game like a player
• run the game and capture screenshots
• compare the result against the GDD
• route missing behavior, broken UI, and visual problems back into the fix loop

A small prototype usually takes about 5-8 hours of agent runtime. You do not need to manually drive each stage or keep an eye on it the whole time; the workflow is designed to keep going on its own.

Community

• Discord

Quick Start

npm install -g godotmaker-cli

mkdir my-game
cd my-game

# Bring your game idea, then run:
godotmaker-cli --agent claude-code

Use Codex or OpenCode for the same workflow:

godotmaker-cli --agent codex
godotmaker-cli --agent opencode

The CLI drives the workflow from idea capture and GDD planning to a playable Godot prototype. Agent selection resolves in this order: --agent, project .godotmaker/config.yaml, CLI-global ~/.godotmaker/cli/config.yaml, then the default runner. Advanced users can still run the underlying role commands directly in Claude Code (/gm-*), Codex ($gm-*), or OpenCode (/gm-*).

For framework development:

git clone https://github.com/RandallLiuXin/GodotMaker.git
cd GodotMaker
pip install -r tools/requirements.txt
python tools/check_env.py

Requirements

You only need to set an API key when your project configuration selects an API provider. Image generation and visual QA can use runtime-native providers only when the selected agent runtime supports them; OpenCode projects should configure codex or API-backed image/VQA providers.

Learn More

• Installation
• Your first game
• How it works
• Common problems
• Roadmap
• Full docs

Status And Boundaries

GodotMaker is preparing for a public alpha under a source-available license. The CLI, agent-runner support, visual QA, and packaging workflow are evolving quickly. Core gameplay generation is usually the most reliable part of the flow. Because AI output is still variable and the art pipeline is still alpha, a completed run may still need a follow-up pass with a coding agent to correct visual wiring issues such as the wrong atlas region, missing animation setup, or incomplete asset binding.

Current boundaries:

A dedicated art-production UI is planned to make curation, slicing, replacement, and review more reliable.

If this direction resonates with you, star the repo, try the CLI, and open issues for the game genres, workflows, and production problems you want GodotMaker to handle better.

Runtime Note

GodotMaker itself is a workflow layer. Actual execution depends on external agent runtimes. These agents are not components maintained by this repository, and long-running automation can occasionally run into runtime-level issues such as silent timeouts, completed work that does not exit cleanly, transient tool failures, rate limits, or child processes that need cleanup.

Most one-off agent failures can be recovered by stopping the current run and starting godotmaker-cli again; the workflow is designed to resume from local project state. Feedback and issue reports are very welcome. If possible, include the key details for that run and the project's .godotmaker/ directory, which often contains the state and reports needed to diagnose the issue.

License

Business Source License 1.1. See LICENSE. Each released version converts to Apache License 2.0 four years after that version is first publicly distributed. The games you build with GodotMaker fully belong to you, subject to any third-party engine, asset, model-provider, runtime, or dependency terms that may apply.