We measured 46 browser games built by AI from one prompt

Everyone has an opinion about whether AI can build a real game now. Nobody had run the games. We loaded every playable one into a real browser at 1440×900 and 390×844, clicked past the menus, and recorded what it actually did. Here is the whole dataset.

The finding: the failure is the one a critic can't see

These games were built with a method whose core is an independent visual critic — a fresh agent that looks at the running game beside a reference and says which is better. It works, and it is the part of the method everyone reproducing it has confirmed.

But it is a visual critic, and a game running at 15fps screenshots identically to one running at 60fps. Frame rate is invisible to a still image, so it is invisible to the judge. And frame rate is exactly where this population falls down: 29 of the 39 games we could instrument run slower than 33ms per frame, with a median of 66.6ms. The worst renders one frame every 1.4 seconds and looks completely fine in a screenshot.

The assumption that died was ours. We expected phones to be the weak spot. They aren't — 38 of 39 render fine at 390×844 and only two overflow horizontally. We were wrong about that before we measured, which is the reason we measured.

Every game, slowest last

Frame time is p50 sampled while playing, after an automated nudge past the menus. Lower is better. Weight is what the browser transferred on first load.

One self-contained file looks like the better build

Six of the games ship as a single HTML file with no external scripts. The other 33 load a bundle. The single-file group is faster and more phone-proof:

Treat this as a signal, not a proof — n is 6. Six games is not enough to claim single-file causes better performance, and the causation could easily run the other way: a developer who can fit a game in one file may have built a simpler game. We are reporting it because it is what the data says, with the sample size attached.

How we measured it, and where it is weak

Headless Chrome driven over the DevTools Protocol. Each game got a fresh page, eight seconds to boot, then six rounds of real clicks and Enter/Space to get past loading screens and menus — synthetic events do not work, because these games gate start behind input the browser considers trusted. Then a ~10 second requestAnimationFrame sample, a screenshot decoded pixel by pixel, and the console read for errors.

The limits, stated plainly:

• 7 of the 46 are missing because they blocked the browser's main thread for longer than our debugger call would wait. That is our instrument's ceiling, not a verdict on those games — two of them render perfectly well given more time. They are listed below rather than counted as failures.
• Three games under-report their weight, because cross-origin assets do not expose transfer size to the page. Those show n/a.
• An automated nudge is not a player. Where it never got past a menu, the frame time is a menu's frame time — which flatters the game, not the reverse.
• One machine, one run, headless, GPU disabled. Absolute numbers would differ on your hardware; the spread across 39 games measured identically is the part that carries.

Not measurable by our harness:

• Operation Blackout · taozhuo
• Speed Racer · Rahil Bhansali
• The Long Silence · Anshu Chimala
• Aleppo Corridor · Bryan Helmkamp
• KINDLE · Tony Downey
• Clawdbot · keshav0479
• The Hooded One · Christopher Kocurek

Method credit: the games here were built with the Gauntlet Loop, published by Matt Shumer after Claude of Duty. The directory of games is his; the measurements are ours. Nothing here is a criticism of the people who built these — shipping a playable 3D game in a weekend is the achievement, and the frame-rate gap is a property of the method, not the builders.