One self-contained file
Markup, styles and logic in a single HTML file. Nothing to install, nothing to bundle, and nothing to keep in sync.
Under the hood
Every game here is one file, and it asks the network for nothing.
No engine, no framework, no build step, no dependencies to update. Each of the twenty games draws its own artwork at runtime, generates its own sound, and runs the same from a web server, a folder on a disk or a sandboxed host.
Drawn at runtime
Every shape is painted on a canvas each frame, so the artwork costs bytes of code rather than kilobytes of images.
Sound from code
Each sound is a short waveform generated with the Web Audio API as it plays. No audio files and nothing to preload.
The constraints
What one file actually buys you.
The single-file rule is not nostalgia. It removes a whole class of problems at once: no version skew between assets, no half-loaded state, no build artefact that can differ from the thing that was tested, and no dependency that can be deprecated out from under a game.
Instant start
The only thing to download is the file itself, so a game begins in the time it takes to fetch a small page.
One shared shell
All twenty games share the same platform layer — input guard, saving, pause handling, particles, frame loop — so one fix reaches every game at once.
Works offline
Nothing is fetched while playing and scores are kept in local storage, so a game keeps working with the network switched off.
Nothing to leak
No analytics, no ad script, no font to download. There is no third-party code running inside a game.
The frame loop
Small decisions that decide whether a game feels fair.
Most of the work in a browser game is not the game. It is the timing, the input and the resizing, and each of those has its own way of going quietly wrong.
- A single requestAnimationFrame loop drives everything, and the time delta is capped so one slow frame cannot teleport the player through a wall.
- Input is scoped to the stage. The page continues below the game, so a keypress or a swipe on the text must never move the player.
- The canvas is sized from its CSS box and scaled by devicePixelRatio, so it stays sharp on a high-density screen without changing the game's own coordinates.
- Collisions are tested against the distance travelled rather than a single point, so a fast object cannot pass through a thin one between frames.
Why there is no engine
An engine would make some of this easier and all of it heavier. For games this small the engine would be the largest thing shipped, and it would be the part that ages — a dependency to pin, update and re-test. Writing the few hundred lines a game actually needs keeps the whole thing auditable: you can read a game from top to bottom and know exactly what it does.
What is shared, and what is not
Everything that is not the game is shared. The head, the styles, the stage markup, the Playables SDK guards, the audio layer, best-score storage, the on-screen input guard, particle feedback and the frame loop all come from one shell. A game supplies its layout, its opening state, its per-frame step, its drawing and its input bindings — and nothing else. That is what makes twenty games maintainable by one person.
How scores are stored
Best scores are written to local storage in the player's own browser, and nothing is uploaded. Inside a sandboxed host the game uses that platform's own storage call instead, which is the only mechanism such an environment permits. There is no account, so there is nothing to sign into and nothing about a player held on a server.
Read a game top to bottom before you trust it
Open any of the twenty games and view source. There is no minified bundle, no third-party code and no network request to trace.