Play the Factory's Godot Game in Your Browser
The autonomous software factory has shipped Godot ports before, but they lived in screenshots and eval logs. This one has a URL. Click it and you are playing a game an agent built, exported, and deployed end to end.
The autonomous software factory has built games before. I have written about them four times this month — the first Phaser game, the lore you can walk through, running the factory hot, and the eval that almost false-greened on a blank canvas. Every one of those posts had the same quiet gap: you had to take my word for it. The proof was a screenshot, an eval log, a green checkmark. You could not click anything.
This one you can click.
That is a Godot 4.6.3 build — not Phaser — web-exported to WebAssembly and served from a plain static bucket. An agent generated the port, exported it, wrote the deploy tooling, and pushed it live. No human touched the build.
Why Godot was the hard one
The earlier factory games were Phaser: TypeScript, a Vite scaffold, a small
JS bundle. That is a friendly target for a code-generating agent and a friendly
target for the browser. Godot is a different animal. It is a full game engine
that compiles to a ~37 MB .wasm blob plus a packed asset bundle, and getting
that to boot on a static host has one specific footgun that eats an afternoon if
you do not know it:
By default Godot’s web export ships with thread_support=true. Threads in WASM
need SharedArrayBuffer, and SharedArrayBuffer is gated behind
cross-origin-isolation — the host must send Cross-Origin-Opener-Policy and
Cross-Origin-Embedder-Policy headers. A public object bucket does not send
those, so the game loads to a black screen and a console error, and you start
chasing a bug that is not in your game at all.
The fix is to export the nothreads variant (thread_support=false). It
boots on any dumb static host with no special headers. That single line is the
difference between “works on my laptop behind a configured dev server” and
“works on a link you can paste into a tweet.”
One command from build to public URL
The other half of the work was making this repeatable. upload-artifact.py
handles single files; a Godot web build is nine files — HTML, the WASM, the
PCK asset pack, the JS loader, and friends — that all have to land under one
origin with a cache-safe key. So the agent wrote a
reusable deploy-godot-web.sh: it takes a Godot web export directory
and deploys the whole set to R2 behind a content-hashed key prefix
(.../greenfields/26b61ce952/), so the next factory game is one command away
from its own public URL. The COOP/COEP-vs-nothreads gotcha is documented inline
in the export config, where the next person to hit it will actually read it.
I verified the deploy the boring way: the public index.wasm is byte-exact
with the local build (37,700,666 bytes, application/wasm), and all nine assets
return 200. A playable link that 404s its own engine is worse than no link.
Why this matters
The interesting claim about a software factory is not “an agent can write code.” That is table stakes now. The interesting claim is that the loop closes on a shippable artifact — something a stranger can use without me in the room. A green eval is a proxy for that. A URL you can hand to anyone is the real thing.
Every prior factory-game post moved the proxy. This one moves the artifact.
Honest limits
This is a demo, not a finished game. It is the Greenfields town zone of the larger port, the WASM payload is heavy (a 37 MB cold load is a real cost on a phone), and subjective polish — art, game feel, story — still goes through an LLM critic cell and human review, not an automated gate. The next slice is wiring the factory’s generated lore NPCs and quests into the Godot port so the world has something to do, not just somewhere to stand.
But it boots, it plays, and it is one link away. Go walk around.