Snake: From Nokia 3310 to the Browser

Snake is the cockroach of game design — said with admiration. It has survived arcade cabinets, home computers, monochrome phones, smartphones and browsers, essentially unchanged, for half a century. We maintain our own browser Snake, and rebuilding a classic by hand teaches you why it refuses to die. This post covers both halves: the history of how a 1976 arcade concept ended up in a billion pockets, and the specific, opinionated choices inside our implementation — including one subtle collision rule that most casual clones get wrong.

1976: Blockade, and a genre by accident

The lineage starts with Blockade, a 1976 arcade game by Gremlin Industries. Two players steered ever-growing walls around a shared arena, each trying to force the other into a crash — no food, no growth mechanic, just trails and doom. It was a competitive game, closer to what later generations would call the light-cycle duel. The single-player mutation arrived over the following years across dozens of home-computer variants, and titles like 1982's arcade Nibbler added the piece that completed the formula: food that makes you longer, turning your own past into the obstacle. That inversion is the entire genius of Snake — the game does not need to attack you, because every point you score is converted directly into future danger.

1997: the Nokia moment

Snake's second life began in 1997, when Nokia engineer Taneli Armanto built a version for the Nokia 6110. It shipped pre-installed, and then the Nokia 3310 (2000) carried it to genuine ubiquity — that phone alone sold on the order of 126 million units, and Snake variants ultimately shipped on hundreds of millions of Nokia devices. For a huge share of humanity, Snake was the first video game they ever owned, played on an 84×48-pixel monochrome screen with two buttons. It is worth pausing on that: the most widely distributed game of its era needed no color, no sound worth mentioning, and a display smaller than a modern app icon. The design carried everything.

Why this design refuses to die

Snake survives because it compresses three rare properties into one rule set. The rules fit in a sentence: eat, grow, don't hit anything. The difficulty is self-generated — the game never gets harder by cheating, it gets harder because you succeeded, which players instinctively accept as fair. And the skill ceiling is genuine: filling a large fraction of the board demands real spatial planning, the kind of path-ahead thinking that mathematicians recognize as flirting with Hamiltonian cycles. Very few designs offer a five-second tutorial and a lifetime of headroom on the same screen.

Inside our version: the numbers we chose

Our implementation runs on a 20×20 grid drawn on a 400-pixel canvas, so each cell is exactly 20 pixels. We tried finer grids and the game got worse on phones: swipes need coarse cells to feel decisive, and 400 cells is already enough room for a snake several hundred segments long before space becomes the enemy. The pacing formula is one line: the snake steps every 160 milliseconds at the start, and each food eaten subtracts 4 ms, with a hard floor at 70 ms. In human terms the game begins at about six moves per second and tops out near fourteen — past that, testers stopped reporting "fast" and started reporting "unresponsive," because at some speed the game outruns the input rather than the player.

Two smaller rules do a lot of quiet work. Direction input ignores exact reversals — pressing left while moving right does nothing — because an instant U-turn into your own neck is never what the player meant; it is the single most common accidental death in careless clones. And food never spawns on the snake's body: the spawner picks only from genuinely free cells, which sounds obvious until you play a clone where a hard-earned 60-segment snake hides the apple somewhere under itself.

The tail rule most clones get wrong

Here is the subtle one. Suppose your head is about to move into the cell currently occupied by the tip of your tail. Collision or not? The naive implementation says collision — the cell is occupied, you die. But think about the timing: in the same tick that your head arrives, the tail vacates that cell. The correct rule, and the one we implement, is that moving into the tail's cell is legal, except on the tick right after eating, when the snake grows and the tail does not move. Our collision check literally excludes the last body segment unless the snake is growing this turn. Chasing your own tail in a tight loop is one of the oldest survival techniques in Snake; an implementation that kills you for it is not stricter, it is wrong. Getting this right cost one extra parameter in one function — and it is precisely the kind of detail you only discover by writing the game rather than copying it.

Fifty years, two buttons

There is something reassuring about a design that has needed no patches since the Carter administration. If you want to test whether your thumbs remember the old religion, our Snake is here — swipe or arrow keys, best score kept in your own browser, and the tail rule implemented the way tradition demands. Fair warning: 160 ms per step feels leisurely for exactly the first four apples.