Sixteen playable demos, none of them built by hand

Sixteen playable demos, none of them built by hand

Sixteen browser-playable games, from a sword duel to eight-player dodge ball, each built from a written brief by an AI agent connected to the editor over MCP. Here's the loop, and what we learned.

· Airogel

A red-hooded swordsman facing an armoured knight in a ruined brick courtyard

The demos page now holds sixteen games. They cover most of what the engine can do: a sword duel with telegraphed enemy attacks (Ashen Duel), a drift racer (Foundry Time Attack), a tiny planet with gravity that points at its centre (SELENE), a ten-second rewind mechanic (Timewinder), a stealth level with guard perception (Night Shift), and multiplayer rooms for soccer, dodge ball, tank battles, racing and a 3,000-object city block.

None of them was built by hand. We wanted to find out whether an AI agent, given only a written brief and the editor's MCP tools, could carry a game from nothing to a public link. It could, for all sixteen.

The loop

Each demo followed the same four steps, and each demo page now shows the brief it started from under How it was built.

  1. Write the brief. A paragraph for the small ones; a short design document for the bigger ones. The kind of game, how it should feel, the controls, how many players. No scene, no code, no assets.
  2. The agent builds in the editor. Connected over the editor's MCP interface, the agent creates objects, materials and lights, writes the Lua scripts, imports or generates meshes, textures and audio, and configures multiplayer rooms where the brief asks for them.
  3. It tests what it made. The MCP tools let the agent run the physics simulation and take screenshots, so it can look at its own work. It also writes rule tests for its scripts, and when it hits an engine limit it files a support ticket from inside the editor.
  4. Publish, then keep prompting. A publish check, then a public link. Every later change (a camera tweak, a new control, a balance pass) was made the same way: describe it, let the agent make it, republish to the same address.

What we learned

Real physics is what makes the agent productive. It can place a car and drive it, drop a ragdoll and watch it fall, without configuring colliders or writing a physics loop. Most of the agent's time went into game feel, not plumbing.

One language matters. Because every script in every project is Lua, the agent could read any demo's scripts as reference when building the next one. The same is true for people.

Letting the agent see its work changes the quality. Screenshot and simulation tools turned "I think this works" into "I checked, and the ball goes through the wall at this speed". Several of the more polished demos, including Ashen Duel's dodge window and Futbol Fan's broadcast camera, came from the agent noticing something in a screenshot.

The support tickets were real feedback. Agents filing tickets when they hit a wall gave us a steady list of engine gaps. Several of those tickets are now engine features: constraint motors used by Ragdoll Hero, the time-scale API behind Timewinder, and the custom gravity used by SELENE.

Try it yourself

The built-in assistant does the same thing from the editor's chat panel, and any MCP client (Claude, ChatGPT, Codex and others) can connect with OAuth. The AI game builder page explains both routes, and the MCP tool guide lists every tool the agents used. Start free, pick a demo whose brief you like, and write your own.