Why every game here is a single HTML file
The single-file rule is not nostalgia. It removes a whole class of problems at once, and it is the constraint the rest of the design is built around.
Twenty games, twenty files, and each file is the whole game. There is no bundle to build, no asset directory, no manifest and no framework to update. Opening one of them in a text editor shows you everything it does, in the order it does it.
That is an unusual way to ship a game in 2026, and it is worth being explicit about why it is a decision rather than a limitation we never got around to fixing.
What the rule removes, not what it adds
Most of the complexity in a small web project comes from the seams between its parts: the build step that transforms source into something deployable, the asset pipeline that hashes and copies files, the dependency tree that has to be pinned and re-tested, and the possibility that what was tested is not quite what shipped. A single file has none of those seams, because there is nothing for them to join.
The practical consequence is that a game cannot get into a half-loaded state. There is no frame in which the code has arrived but the artwork has not, because the artwork is not a separate thing. A request either completes and you have the whole game, or it fails and you have a browser error page. There is no in-between to design around.
What it costs
Being honest about the trade: a single file means you write your own frame loop, your own input handling, your own collision tests and your own sound. None of that is hard, and all of it is work that an engine would have done for you. You also lose the asset pipeline, which means every image has to be either drawn in code or embedded, and every sound has to be generated or encoded into the file as text.
The offsetting gain is size. A complete game in this catalogue is under thirty kilobytes, which is smaller than a single photograph on a typical website. It starts in the time it takes to fetch a small page, which matters far more than any feature an engine would have added.
How twenty of them stay maintainable
A single file per game would become unmanageable if each one reimplemented the platform layer. So the layer is shared: the head, the styles, the stage markup, the SDK guards, the audio, the best-score storage, the on-screen input guard and the frame loop come from one shell, and a game supplies only its layout, its opening state, its per-frame step, its drawing and its input bindings.
The result is that a fix to the frame-loop cap or the audio envelope lands in all twenty games at once, while the part that makes each game that game is still a few hundred lines in one place. That balance is the whole reason the model works at this scale.
When the rule should be broken
It should be broken when a game genuinely needs something a single file cannot hold: a large licensed soundtrack, a level editor, a physics engine doing real work, or a live service with a server behind it. Those are all legitimate products, and none of them is what this catalogue contains.
For a small game that has to start instantly and work offline, the single file is not a constraint to work around. It is the design.
Want to go deeper?
Building something for the browser? Send us a link and we will tell you honestly whether it fits.
