The console I wanted didn't exist. Not a console with a better library: a console where the library gets written, on demand, in the gap between having an idea and wanting to play it. Somewhere around fifteen minutes. Long enough to make a coffee, short enough that the idea is still interesting when the game arrives.
That sounds like a toy premise until you notice how much of modern entertainment is spent on the wrong side of it. The average evening with a games library is mostly browsing. Scrolling a grid, reading a description, watching thirty seconds of a trailer, deciding no. The catalogue got enormous and the search got worse, and at some point the bottleneck stopped being is there a game like this and became can I find the one I mean.
If making a small game costs minutes, that whole problem inverts.
A model that writes a game is not a game studio
Every capable coding model can write a game loop. Ask for a platformer and you'll get a platformer's source code: physics, collision, a jump with coyote time, probably a comment about tuning the gravity constant. It will look right. It will also be a text file, and a text file is not a game.
The distance between those two things is where all the work actually is:
- The code needs an engine to run inside, at the version it was written against, with its dependencies installed.
- The game needs art and sound, in the formats the engine imports, at the dimensions the engine expects.
- Someone has to run the exporter and get a build out: a step with its own toolchain, its own templates and its own failure modes.
- Somebody has to check it boots, because a build that fails on load fails silently and looks exactly like a build that works until you open it.
- And it has to end up somewhere a person can click a link and play it, on the device they already have in their hand.
None of those are reasoning problems. They're tooling problems, and they are precisely the things a chat box cannot do. So the studio is not a prompt box wired to a model. It's a machine.
What the machine is
Each session gets a cloud microVM with a container on it: the game engine, its export templates, a headless browser, an asset pipeline, and a coding agent with a shell. The agent has the same things a human developer would have, which is the entire point: it can run the engine's CLI, read the error, fix the scene file, re-import, re-export, and try again, without a person mediating each step.
The VM stays warm across a conversation. That single decision is why the second change to a game takes seconds instead of minutes: the import cache is hot, the build artifacts are on disk, and a small edit is a small rebuild. Spinning up a fresh sandbox per message would be cleaner and would make the product feel broken.
Assets get generated to the game's own style brief rather than pulled from a pack, which sounds like the flashy part and is actually the fussy part. A sprite sheet at the wrong cell size doesn't look wrong: it looks like the animation code is buggy. Getting generated art to arrive in the shape the engine expects is unglamorous plumbing that decides whether the game reads as made or as assembled.
Then the build gets played, automatically, before anyone sees it. The exported web build is loaded in a headless browser and driven for a few seconds: does it boot, does it hold framerate, does the console stay quiet. Failures go back to the agent. You are not the test harness.
Why the browser, and not an app
Generation collapses the cost of making a game. The moment it does, distribution becomes the bottleneck, and every distribution channel we built over the last fifteen years assumes the opposite economics. App store review is measured in days. A generated game is measured in minutes. You cannot put a three-day queue behind a fifteen-minute idea and call the result instant.
The web has no queue. A build exports to WebAssembly, publishes to a CDN, and becomes a URL. Send the URL to someone and they play it: on a phone, on a laptop, on a controller, on the browser built into their television. No install, no account, no store page. The friction of showing someone your game drops to the friction of sending them a link, which is to say, none.
The web charges for this, and honestly: download size matters, memory ceilings are real on older phones, and audio can't start until someone touches the screen. Those are budget decisions you make before generating, not surprises you discover afterwards. For arcade-sized games with one strong mechanic, which is exactly the size a generative studio is good at, the trade is overwhelmingly worth it.
Everyone gets an address
Games land at a personal arcade: yourname.vbgnt.com, laid out
like a console dashboard rather than a file listing. Big cover art, a hero
shelf, arrow keys and D-pad navigation so it opens on a television without a
remote-control fight. Deep links to a single game, because most sharing is
"play this specific thing", not "browse my work".
There is no feed. That's deliberate, and it's the decision I'd defend hardest. The moment a ranking decides who gets seen, briefs start optimising for the ranking instead of for the person who was going to play the game. A studio whose distribution is send someone a link keeps the incentive pointed where it belongs.
The part that needs a rule
A machine this good at pastiche is good at pastiche of things that aren't yours. Ask for the game you're nostalgic for and you may get it: sometimes refused, sometimes vaguely, occasionally with a fidelity that makes you close the tab. Model behaviour around famous intellectual property is genuinely inconsistent, which means the rule cannot live in the model. It has to live in the product.
So: mechanics and genres are open, and always have been, that's why there are a hundred legitimate battle royales. Characters, art, music and names belong to whoever made them. In practice this is barely a limitation, because the useful prompt shape was never a franchise name anyway. It's an era and a texture: late-90s shareware, four colours, chunky outlines. You get the feeling you were actually after, and you get a game you can put on the internet under your own name.
That last part isn't a legal footnote. A game you can't share isn't a game: it's a screenshot. Publishability is the constraint that keeps the whole thing honest.
What it changed
The thing I didn't predict is how quickly "I wonder if" became a complete sentence. An idea used to need justifying: a weekend, a project folder, the sunk cost of having started. Now it needs a sentence and a coffee. Most of what comes out is disposable, and that turns out to be fine; disposable games made for one specific person on one specific evening are a real category, not a lesser version of a commercial one.
The scarce thing stopped being production capacity. It's taste: knowing which single mechanic is worth building around, and being able to say so concretely. That skill doesn't get automated by the thing that automated production. If anything it's the only part that got more valuable.
Frequently asked questions
How long does it take to generate a playable game?
Minutes rather than hours for a first playable build, with small 2D games faster than 3D ones and art-heavy briefs slower than mechanically simple ones. The long pole is rarely the code: it is generating and importing assets, exporting the web build, and testing it. Follow-up changes are considerably faster because the project and the machine building it are already warm.
Is an AI-generated game any good?
The first build is a draft that already runs, which is a different and more useful thing than a design document. Whether it is good depends almost entirely on the brief: a single sharp mechanic described concretely produces something worth playing, while a vague genre label produces a competent, generic shell. The iteration loop afterwards is where a draft becomes a game.