Why this game is just one file
What a 'file', a 'build step', and a 'framework' even are -- and why this game deliberately skips most of that.
Most apps you use are built from thousands of files and a small mountain of pre-written helper code. This game is the opposite: it is basically one file you could read in an afternoon. That was a deliberate choice, and understanding why teaches you a lot about how software gets built in general.
Concept: a "file". A file is just a document — here, a document full of instructions (code). Big programs spread their instructions across hundreds of files. This game keeps almost all of its instructions in a single one called
game.js.
What most projects add, and this one skips
Three things a typical web project uses, and what they are:
Concept: a "framework". A framework is a big pile of someone else's code you build on top of, so you don't have to write the common parts yourself. It saves effort but adds bulk and rules you must follow. This game uses none — it writes its own small versions of the few things it needs.
Concept: a "build step". Many projects run a machine that takes the code you wrote and transforms it into the code the browser actually runs (combining files, shrinking them, translating newer syntax). That's a "build." This game has no build step: the file you write is exactly the file that runs. Edit, refresh, done.
Concept: a "dependency". A dependency is outside code your project borrows. More dependencies mean more to download and more that can break. This game has just one, and it's only used by the tiny leaderboard server — never by the game in your browser.
Why skip all that?
Because for a project this size, the simple path is genuinely better:
- You can read it. What you see is what runs — no hidden transformations, no "which of 40 files is this?"
- Nothing to set up. Open the file, change a line, refresh the page.
- It stays small and fast to download, which the team even guards automatically (a check fails if the game gets too big).
There's a real trade-off: the game has to write its own small versions of things a framework would provide — like the code that draws the screens. But that turns out to be surprisingly little, as the next chapters show.
- A file holds code; most apps use many, this game uses basically one.
- It skips the usual framework, build step, and dependencies — so the code you read is exactly the code that runs.
- That's a trade: less pre-made help, but far less to learn, set up, and hide.