Pixel Vault: A Playable Museum of Game Design History
Every prototype is one HTML file. Under 50KB. No frameworks, no CDN, no npm. Double-click and play. Pixel Vault is a growing museum of playable game mechanics built from scratch, organized by lineage, and playable forever in any browser. Two published tracks cover 70 years of arcade history and the AI archaeology overlay that shows what the machine sees inside each mechanic.
It started in a notes folder one afternoon. No plan. No design doc. Just a canvas element and curiosity. By the end of that day I had a Pac-Man clone running in a single HTML file. Pure JavaScript, zero imports, playable by double-clicking.
Then I made another one. Then another. Before I set up a dedicated repo, the pattern was already showing itself.
That project is Pixel Vault. A museum of every fundamental game mechanic in its smallest possible form. Hundreds of playable prototypes and counting, organized by genre, annotated with lineage notes, and all of them playable right now.
The Constraint Is the Feature
Every game in Pixel Vault has the same rules:
- One HTML file. No external JavaScript, no CSS, no images.
- Under 50KB. That is 51,200 bytes including all the code, all the styles, all the UI.
- Canvas-based. 800 by 600 logical pixels. 60 frames per second.
- Playable offline. Double-click the file and it runs. No server, no internet.
These are not limitations I am working around. They ARE the design.
When you strip away the engine, the asset pipeline, the physics library, and the package manager, what you have left is the mechanic itself. The pure interaction. Pong is not a game about paddles and pixels; it is a game about timing and prediction. Asteroids is not about triangles and rocks; it is about momentum and commitment. The constraint forces you to understand what each game actually IS at its core.
And when you rebuild them from scratch, you start to see the family tree.
Two Published Tracks
The collection is organized into tracks. Think of them as two lenses on the same history — with a third frontier being actively explored.
Track 1: Archetypes. The foundational track. Reconstructions covering 20 genre series across the full arc of arcade history. Paddle games from the 1972 Pong lineage. Maze games from Pac-Man through Bomberman. Fixed-position shooters from Space Invaders through Galaga. Platformers, puzzlers, racing games, RPGs, tower defense, fighting games, sports simulations. Every major family in the history of interactive entertainment, traced back to its roots.
Each one carries a metadata block at the top of the file: series code, era designation, mechanic description, ancestry chain. Not just "this is a maze game" but "this is a maze game that descends from Pac-Man (1980) through Bomberman (1983) into the procedural generation patterns of the 2010s."
Track 2: AI Archaeology. The same games viewed through a different lens. Press the H key in any of these and an overlay appears showing the AI concept lurking inside the mechanic: neural pathfinding, generative terrain, emergence from simple rules. Same mechanic, different perspective. The game plays the same. But you can see what the machine sees.
This track asks a specific question: what if AI had been available when these mechanics were invented? Not what would the AI make — but how would the same human designers have seen their ideas differently?
The Frontier: AI Evolution
Alongside the published tracks, I am running a longer experiment. I have built well over a hundred AI Evolution prototypes — games that do not descend from any known human ancestor. Novel interactions. Atmospheric experiments. Mechanics that do not have a genre name yet.
Some of them are genuinely strange. Others are familiar-feeling but unfamiliar-playing. I am mining the edges between known genres, looking for something nobody has built before.
The honest answer about what I am looking for: one mechanic, somewhere in this frontier, that creates a feeling in the player which has never been created before. Not a new story on an old mechanic. Not a reskin of Tetris. The interaction itself.
I do not know which prototype number that will be. That uncertainty is the whole point of casting a wide net. You build many to find the one. This is the ongoing work — recording history while also trying to make some.
The Museum, Not the Arcade
The distinction matters. An arcade wants you to keep playing. A museum wants you to understand what you are looking at.
Every game in Pixel Vault has an info panel (press the question mark key). It tells you the game's history, its mechanical lineage, what era of game design it represents, and why that particular interaction mattered when it first appeared. The gallery page lets you browse by series, filter by track, and launch any game in a dedicated playback engine that fills the screen and gets out of the way.
The compendium is worth time on its own. It traces 70 years of game design through the creators who shaped it. Not just "Shigeru Miyamoto made Mario" but the full chain: Ralph Baer's Magnavox Odyssey in 1972, Nolan Bushnell's Atari, Tomohiro Nishikado's Space Invaders, Iwatani's Pac-Man, and the branching tree that followed. More than 70 designers, each connected to the prototypes that carry their DNA.
If you are curious about who invented the things you have been playing your whole life, start there.
How It Gets Built
Agent mode. That is the honest answer.
I work in Claude with agent mode running inside VS Code. The workflow is: pick a series, identify the next mechanic in the lineage, describe what I want, and let the agent generate the file. Then I play it, break it, refine it, and play it again. Most prototypes take one session. Some take three. (If you want a deeper look at how that workflow actually operates, Agentic Development: How to Build Software with AI Agent Workflows covers the full picture.)
The constraint makes this possible. Because every game is self-contained, there is no build step. No integration tests against other games. No shared state. You write the file, you open the file, you play the file. The feedback loop is measured in seconds.
A five-job CI pipeline runs on every push: structural validation, size checking, metadata parsing, security scanning, and catalogue regeneration. If a game fails any check, it does not merge. The QA dashboard lets me test every game in the browser and rate it on a four-tier system: Broken, Playable, OK, Certified.
The batch tools handle the tedious parts: injecting touch controls for mobile, updating disclaimer text, polishing canvas text contrast. All Python scripts that operate on the files without needing to understand the games.
Desktop-First
Pixel Vault was designed and tested on desktop. The constraint-based architecture — keyboard controls, 800×600 canvas, 60fps loops — is optimized for that context.
Mobile support is a work in progress. The touch control layer is built and injected into all games, and many do run on phones, but the experience can be clumsy. I am actively working out the remaining bugs. If you hit something rough on mobile, that is an honest note, not a finished product.
For now: desktop is the place to play. Double-click any game and it fills your browser.
The Technical Contract
The architecture decision records in the repository document every structural choice. Why single files. Why 50KB. Why canvas instead of DOM. Why requestAnimationFrame instead of setInterval. Why multiple tracks instead of one flat collection. Why metadata blocks appear before the DOCTYPE declaration.
These decisions are not arbitrary. Each one solves a specific problem:
Single files mean zero dependency rot. The games written in 2025 play identically in 2026. They will play identically in 2036. No framework will deprecate. No CDN will go down. No package version will break.
50KB means the mechanic fits in your head. If a game needs more than 50KB, it probably has mechanics that do not belong together. Split them. Simplify. Find the core.
Metadata blocks mean the collection is self-documenting. Any tool can parse the comments at the top of the file without loading a game engine. The manifest, the catalogue, and the gallery all generate automatically from those blocks.
Open Source and License
Pixel Vault is open source on GitHub.
The engine is GPL-3.0. The templates, tools, gallery, play engine, and all infrastructure code are licensed under the GNU General Public License v3. If you fork the engine and distribute it, your fork stays open. That is the deal.
The game content is CC BY-NC-SA 4.0. The individual game HTML files — all the prototypes, the archaeology overlays, the evolution experiments — are licensed under Creative Commons Attribution-NonCommercial-ShareAlike 4.0. You can fork them, study them, adapt them, and share them with attribution, for non-commercial purposes. Derivatives carry the same license.
What this means in practice: Fork the engine to build your own collection. Study any game file to see exactly how it works. Adapt the templates for your own prototypes. The five starter templates cover base canvas, grid, particles, physics, and audio patterns. Each is a working game skeleton under 10KB. If you have kids between 8 and 14, point them at the gallery — they can view the source of any game that interests them and see exactly how it works. That is the real museum experience.
The collection lives at play.joshuaayson.com. The history lives in the compendium. The source code is on GitHub. The same constraint-first philosophy also runs through Four Films From Code — animated short films built from Python, numpy, and stick figures with the same zero-dependencies rule. And if you are curious about the rest of what is being built, the projects page has the full set.