Once you can make a small game in minutes, you discover the actual bottleneck was never making it. It's the ten minutes afterwards, when you want someone else to play it, and the honest answer is "install this, trust me".
Nobody installs. That's not a slight on your friends: it's the correct response to an unsigned binary from a person who described it as "a thing I made this afternoon". The web build isn't a compromise chosen because native was hard. It's the only target where "here, try this" is a link rather than a favour.
Distribution is the constraint now
Generative tooling collapses the cost of production. The moment it does, whatever was second-most expensive becomes the thing that decides how the product feels, and for games, that's distribution.
Every channel built over the last fifteen years assumes the old economics: a game takes months, so a few days of review is noise, and a store page is a reasonable ask because you'll have one product for years. Reverse the production cost and those assumptions invert. A three-day review queue in front of a fifteen-minute idea doesn't slow the product down; it replaces it.
| App store / Steam | Web build | |
|---|---|---|
| Time to share | Days (review) | Seconds (a URL) |
| What the recipient does | Install, sign in | Taps a link |
| Suits many small games | Poorly: one listing each | Naturally |
| Reaches phone + desktop + TV | Separate builds and listings | One build |
| Ceiling on scope | Very high | Real, and it binds |
That last row is the honest cost, and it's covered below. Everything above it is why the trade is worth making for games of this size.
One build, four ways in
The underrated property of a web build is that it reaches four different input models without four different projects: if the input is designed in rather than ported on afterwards.
- Touch. Not a virtual D-pad bolted over the corner of the screen. Controls designed for thumbs from the start: generous hit areas, gestures where they fit, and a UI that assumes a finger is covering a third of the display.
- Keyboard and mouse. The desktop default, and the one everyone remembers to handle.
- Gamepad. The browser Gamepad API works, in every modern browser, with no permission prompt. A controller connected over Bluetooth to a phone or a laptop just appears.
- Television. The browser on a TV or a console, driven by a D-pad. This is the one that gets forgotten and the one that makes an arcade feel like a console, which means directional navigation with a visible focus state, and text sized for ten feet, not ten inches.
Handling all four is a design constraint at generation time, not a port. The difference shows immediately: a game that assumed a mouse and got touch bolted on afterwards feels exactly like what it is.
What the web actually costs
Three real constraints, all of them budget decisions made before generating rather than surprises discovered afterwards.
Download size
Every byte is on the critical path to first play. A native game streams assets after launch; a web game largely doesn't. This is a hard cap on how much generated art a game can carry, and it's a good discipline: it pushes towards games that read by shape and palette rather than by texture resolution, which is also the look that generates best.
Memory
WebAssembly runs inside a memory ceiling, and on older phones that ceiling is lower than you'd guess. It binds on asset count and on long sessions more than on frame complexity. Arcade-sized games with short sessions sit well inside it; open-world ambitions do not.
Audio can't start on its own
Browsers won't let audio play until the user has interacted with the page. Every web game needs a real first tap: a title screen, a "press to start", and a game generated without one launches silent and feels broken. It's a small thing that fails loudly.
Threading, and why it usually doesn't matter
Multi-threaded WebAssembly needs SharedArrayBuffer, which
needs cross-origin isolation, which means serving every asset with the right
COOP and COEP headers and keeping the whole game same-origin. It's
achievable (the headers go on the distribution and the arcade keeps its
assets local), but a single-threaded export sidesteps the whole class of
problem and runs fine for games at this scale.
The pragmatic position: default to the single-threaded export, send the isolation headers anyway so a threaded build works the day it's worth having, and don't spend the complexity budget until a game actually needs it. Almost none do.
The part that's easy to miss
A URL is not just a convenient install method. It's a different social object. You can put it in a message, in a group chat, on a TV's home screen, in a QR code on a poster at a party. Someone can play your game for ninety seconds, decide it's not for them, and close the tab, with no account created, no install to uninstall, and no relationship with a store.
That low-stakes quality is what makes small, personal, disposable games work as a category. Raise the cost of trying something and only ambitious games justify the ask. Drop it to a tap, and a game made for one person on one evening becomes a reasonable thing to make.
Frequently asked questions
Are browser games good enough for real games now?
For the scale of game a generative studio produces, arcade-sized, one strong mechanic, minutes-long sessions, yes, comfortably. WebAssembly builds of mature engines hit 60fps on ordinary phones, gamepads work through the Gamepad API, and modern browsers handle 3D fine. The ceiling shows up in very large asset sets and long-session memory use, which is a reason to keep generated games sharp rather than sprawling.
Why not publish AI-generated games to the App Store or Steam?
Because store review is measured in days and a generated game is measured in minutes, so the queue would dominate the experience. Stores also assume a stable product with a marketing page, while a generative studio produces many small games that exist to be sent to a handful of people. A link that opens instantly on any device fits that shape; a store listing does not.