A first-person shooter that fits in 5,234 bytes
The standing world record for the smallest first-person shooter has held since 2004 at 97,280 bytes. tinyFPS is a complete, playable FPS in 5,234 bytes, roughly eighteen times smaller. The application to break that record has been submitted to Guinness World Records.
Eighteen copies of tinyFPS fit inside the current record. Nineteen do not. For scale, the stylesheet behind the page you are reading is larger than the entire game.
Nothing in the file that could be computed instead
Written from scratch in x86 assembly as a single MS-DOS executable. No engine, no framework, no compression, no asset bundle. Every byte in the file is an instruction someone chose to put there.
The discipline is simple to state and hard to follow: if a thing can be calculated at startup, it does not get stored.
The rendering
- Real-time 3D by raycasting, the technique behind Wolfenstein 3D
- Perspective floor casting under the walls
- Brick texturing with distance shading
- Double buffered, so there is no flicker
- VGA mode 13h, drawn a column at a time
The game
- A maze that regenerates every round
- Three weapons, each with its own fire rate, damage, magazine, and reload
- Enemies that path to you by flood fill
- Crosshair hit markers and a rotating radar
- Endless waves, scoring, and a full HUD
Where the bytes went
- Sine and cosine tables generated at startup, not stored
- The color palette computed at runtime
- The map bit-packed, then unpacked by a single instruction
- A custom keyboard interrupt handler for simultaneous input
- Logic gated to the timer tick, so speed is frame-rate independent
Verifiable by anyone
A record claim is only worth as much as its reproducibility. The submitted binary rebuilds byte-for-byte identically from source on any machine with an assembler.
What it is up against
The standing record is held by a 2004 demoscene release that packed a full 3D shooter into 96 KB by generating its textures, models, and music procedurally at load time. It is a landmark piece of engineering and it has gone unbeaten for over twenty years.
Beating it is not a matter of writing the same thing more carefully. It means giving up the generated-asset approach entirely, because the generators themselves cost more bytes than the whole budget.
Where the bytes were nearly lost
A size record is mostly a sequence of decisions about what to throw away. These were the ones that mattered.
The tables problem
A raycaster needs sine and cosine for every column of the screen, every frame. The conventional answer is a lookup table baked into the file, and that table alone would have eaten a meaningful share of the entire budget.
Instead the tables are computed into memory at startup. The code that generates them is a fraction of the size of the data it produces, and the file ships with none of it.
The map
Storing a maze as one byte per tile is the obvious approach and it is wasteful, because a wall is one bit of information. The map is bit-packed to a fraction of its natural size, and unpacked during collision checks by a single processor instruction rather than a routine.
Real-time input
The straightforward way to read the keyboard gives you one key at a time, which makes moving, turning, and firing simultaneously impossible. That is not a shooter.
So the game installs its own keyboard interrupt handler and maintains a key-state table, which is how holding three keys at once works. Game logic runs off the system timer rather than the frame loop, so the speed is identical on a 386 and in a browser emulator thirty years later.
Making it a real game
The easy version of this record is a tech demo: walls, movement, nothing else. It would be considerably smaller and it would deserve an asterisk.
The budget was spent instead on the things that make it arguable as an actual FPS. Three distinct weapons with their own handling. Enemies that path toward you rather than drifting. Hit feedback, sound, a radar, waves, and a score. The claim is stronger for costing more.
Because constraints are the whole job
Nobody needs a shooter in 5 KB. But a codebase that small has nowhere to hide waste, and the habits it forces are the ones that matter in paid work.
The same instinct that asks does this need to be in the file at all is the one that makes a client's website load instantly on a phone in a parking lot, and keeps an agent system running inside a budget instead of quietly burning through one.
It is also the most honest answer available to the question every buyer is really asking, which is whether the person they are about to hire is actually any good. Marketing copy cannot settle that. A binary you can download, rebuild, and measure yourself can.
Play it, then look at the size
It runs in the browser with nothing to install. The whole game is smaller than most images on the web.
Play tinyFPS