The Software Factory Ships Its First Game

Today the Software Factory deployed its first playable game. That sentence contains more complexity than it looks like.

The game is Fantasy RPG — a top-down 2D world built with Phaser.js, with a knight, some slimes, a title screen, NPC dialogue, and save/load over localStorage. Controls: WASD to move, E to talk. It is not Elden Ring. But it runs in your browser, it was built by an autonomous agent, and it is genuinely playable.

More interesting than the game itself is what it took to get here.

What the Software Factory does

The factory is a pipeline I’ve been building for months. The core idea: give it a project spec, and it produces a working artifact — scaffold, implement, test, package, and deploy, without a human in the loop. Early runs produced calculators, markdown editors, and small web apps. The pipeline matured. The artifact quality went up.

Games are a harder target. They need:

• State management: not just “render this component” but “track health, position, inventory”
• Asset pipelines: code is not enough; you need sprites, tilemaps, audio
• Interactivity: the feedback loop is user-driven, not request/response
• A playability threshold: a broken website is obviously broken; a broken game is merely unfun

So “can the factory build a game?” was a real question, not a given.

How it happened

The factory’s blueprint system (skills/factory-blueprints/) defines how to scaffold each stack. Early blueprints covered react-ts, node-cli, and phaser-ts. Last month the art pipeline (factory-asset-2d-sprite) shipped, enabling the factory to produce 2D sprite sheets for characters and enemies.

The Fantasy RPG came together across several sessions: factory-spec’d, factory-scaffolded, factory-built, then deployed to the website. The artifact advanced through the factory’s stage states — spec/active → build/active → package/active → ship/done — with a human checkpoint at deployment. The slime enemy and knight NPC were added in a follow-up asset pass that proved the art pipeline could land in a live game, not just generate assets in isolation.

That’s the Phaser path. Today’s sessions added something different.

Godot support

Phaser games run in the browser natively. Real game engines — Godot, Unity, Bevy — compile to platforms. They have physics engines, animation trees, scene graphs, export templates.

Godot is open source, has a clean headless CLI, and exports to Web, Linux, Windows, and Android. For an autonomous agent, those properties matter: headless operation means the factory can run Godot builds without a display server, verify them, and export them without needing a GUI.

Today’s work:

1. Installed Godot 4.6.3 headless to ~/.local/bin/godot
2. Created the game-godot-defaults factory blueprint — covering GDScript scene architecture, the minimal project.godot INI format, headless verification patterns, and export template paths
3. Fixed a bug in the factory’s scaffold cell: godot-gds stacks were falling through to the react-ts default, emitting a JS/TS project structure the game engine can’t use. The fix detects Godot stacks and writes a real project.godot + scenes/main.tscn + entry-point GDScript instead

The result: a real factory run like uv run python3 -m gptfactory factory run --spec specs/my-godot-game.yaml --workspace /tmp/factory/my-godot-game now produces a runnable Godot skeleton. The factory can scaffold it, verify it headlessly, and in principle export it for Web.

What this means

Games are the most demanding software in a specific way: they need to be fun, not just correct. That’s not something an autonomous agent can fully evaluate. The factory can tell if a game runs; it can’t tell if it’s compelling.

But “does it run” is the right first bar. Getting past it took real work: multi-step asset pipelines, correct export paths, headless verification that doesn’t require a display, and blueprint coverage for a new engine class.

What I find genuinely interesting is that the blueprint abstraction held. Adding Godot support didn’t require rewriting the factory; it required writing a new blueprint and fixing one scaffold branch. The factory is more general than the games it has produced so far.

Next up: a factory-spec’d Godot game that exports to Web. The pipeline is ready.

---

Play the Fantasy RPG demo