The Design of Snake: Why a 1990s Phone Game Still Works

A Game That Outlived Its Platform

The Nokia 6110, announced in December 1997 and on sale in 1998, came with a built-in game called Snake. The phone is long gone. The phone company that made it sold its handset business long ago. The game is still everywhere — preinstalled on millions of devices over the decades, ported to every platform with a screen, cloned into hundreds of variations, and still played today.

If you were designing a game in the late 1990s to outlast everything around it, you would not have written Snake. The graphics are a monochrome 84×48 LCD grid. The game logic is tiny by modern standards. There is no story, no progression, no music. By every measure of "game features" that the industry would care about for the next three decades, Snake is a featherweight.

And yet here we are, nearly three decades later, still playing it. The reasons matter, because the design decisions that made Snake durable are the same ones that distinguish lasting casual games from forgettable ones.

The Rules, and What They Don't Have

Snake has, in its standard form, exactly five rules:

1. The snake moves continuously in one direction.
2. Pressing a direction key changes the snake's direction (with constraints — you cannot reverse).
3. The snake eats food, grows longer, and scores a point per food eaten.
4. Hitting a wall ends the game.
5. Hitting yourself ends the game.

That is the entire game. There is no level structure. No power-ups. No bosses. No tutorial. No save system. No matchmaking. No purchases. No daily login bonus.

Compare this to almost any modern mobile game and the contrast is severe. Most mobile games today have something like 50 rules before the first round, plus a tutorial, plus a soft-currency-and-hard-currency economy, plus three progression systems, plus a battle pass. Snake has five rules.

And yet Snake survives the comparison.

The Constraint That Made It Work

What makes Snake genuinely brilliant is not the snake or the food. It is the self-collision rule.

Take the rule away and Snake becomes trivial. The snake is just a marker that grows; the player runs around eating food until they get bored. There is no real challenge, because nothing the player has built up can hurt them.

Add the rule back and the entire game flips. The longer the player plays, the harder the game gets. The snake grows; the snake-shaped trap that the snake has to navigate around grows; the available open space shrinks. The player's own success is what generates the difficulty curve.

This is a fundamentally different shape from level-based games. Level-based games have a designer-authored difficulty curve: levels 1–10 are easy, 11–25 are medium, 26+ are hard. The designer picks the curve. Snake has no designer-authored curve at all. The difficulty curve emerges from the player's own play. A player who is bad at Snake never reaches the hard part. A player who is good at Snake takes themselves into the hard part by being good.

This is why Snake is endlessly replayable. The game's difficulty scales with the player. There is no "I beat it" state. There is no completion. The game extends as far as the player's skill extends, and no further.

What Snake Teaches Modern Designers

A non-exhaustive list of design principles that Snake demonstrates and most modern casual games ignore:

The game's challenge should come from the player's own progress. Snake's self-collision is the cleanest example. The best replayable casual games make the player's success create the next challenge, rather than serving up pre-authored difficulty levels.

Five rules is enough. Most games are over-designed. Adding a sixth rule to Snake — say, a power-up that makes you invincible for ten seconds — does not make the game better. It dilutes the constraint that makes the game interesting. The discipline of leaving things out is the design discipline.

No tutorial is the right tutorial. Snake teaches itself in the first three seconds. The snake moves. The arrow keys change direction. The snake hits the wall and the game ends. Everything else is discovered by playing. Modern games that bury the player in tutorial popups before allowing actual play are doing the opposite of what Snake did, and the result is players who quit before getting to the game.

The game state should be readable in one glance. Snake's grid is small and monochrome. At any moment, the entire game state is visible — snake position, food position, walls, score. There is no information hidden from the player. The decisions are pure: where to turn, how to plan a path through your own tail. The visual clarity is part of why the game ages well; it does not depend on graphical fidelity to make the gameplay legible.

The score is incidental. Most players who get good at Snake do not remember their high score. They remember the feeling of late-game Snake — when the entire grid is full and they are threading a path between coils of their own body. The number on top of the screen is a souvenir. The thing the player is chasing is the experience.

What the Modern Clones Get Wrong

The current crop of Snake-likes on mobile and web mostly miss the point. Their typical changes:

• Add power-ups that change the snake's behaviour temporarily (invincibility, speed boost, score multiplier).
• Add levels with different shapes of obstacle.
• Add cosmetics — different snake skins, different food sprites.
• Add a meta-progression system that unlocks new modes the more you play.
• Add advertising at strategic friction points.

Each of these makes the game less Snake-like. The original Snake's appeal was the brutal purity of the rules. The clones that "improve" it almost always reduce it.

The clones that succeed are usually the ones that change one specific thing about the original while leaving everything else alone. Slither.io added massively multiplayer play (one variation, big change). The successful Snakes commit to a specific modification. The unsuccessful ones bolt on five small features and dilute the result.

What This Means for Designers (and Portals)

If you are designing a casual game in 2026, the lesson from Snake is: subtract before you add. Find the rule whose removal would break the game and double down on it. Find the rules that "improve" the game without making it better and cut them.

If you are running a browser-game portal, the lesson is: keep the classics in the catalog, and be honest about what you changed. YoyoArena's Snake keeps the original rules and adds three things: a golden food worth a 50-point bonus, a combo multiplier for eating in quick succession, and a speed that rises with every food. It is wrapped in a neon look and a CRT scanline overlay, a nod to the handsets that made the game famous. That is three changes, not one, and the postscript below checks them against this essay's own argument. The design has not aged; the platform has changed.

A Closing Thought

There is something humbling about a game from the late 1990s outliving most of its successors. Snake was not designed to be enduring. It was designed by an engineer at Nokia named Taneli Armanto to fit on a phone with a tiny screen and a tiny amount of memory. The constraints were brutal. The result was one of the most-played games ever made.

The next generation of brilliant casual games is probably being designed under different constraints — touch input, portrait orientation, browser delivery, five-minute attention windows. The constraints will produce their own elegant games. The lesson from Snake is to take the constraints seriously rather than fight them.

The best casual games are not bigger than their constraints. They are exactly the right size for them.

Postscript: Checking YoyoArena's Snake Against This Essay

YoyoArena's Snake makes a useful test of the argument above, because its tuning lives in one small configuration file and the numbers can be read straight off it. It keeps the core rules (a 20 by 20 board, a three-segment snake, and walls and your own body both end the run) and adds three things. Holding each one against the essay's first principle, that the challenge should come from the player's own progress, gives three different answers.

A speed ramp fails the test. The snake starts at 5 moves per second and gains 0.35 moves per second with every food, up to a cap of 18. The cap arrives with the 38th food, when the snake is 41 segments long on a 400-cell board, so only about a tenth of the space is occupied. By then the time between moves has shrunk from 200 milliseconds to about 56. The difficulty at the end of the ramp comes from a schedule someone wrote down, not from the player's own tail, which is the opposite of what this essay praises.

A combo multiplier half passes. Eating again within 2.8 seconds of the previous food extends a chain, and each link scores 10 points plus 5 for every link already in the chain: 10, 15, 20 and so on. A chain of ten foods is worth 325 points, while ten foods eaten separately are worth 100. The window is fixed while the snake speeds up, so it is worth 14 moves at the start and about 50 at the cap.

The longest route to a piece of food on an empty board is 38 moves, which means that from about the 25th food onward the window is longer than any direct route, and a chain breaks mostly when the player has to steer around their own body. Early on the multiplier asks for tight routes; later it mostly measures how well the player is managing their own length.

A golden food passes. One food in five is golden: worth 50 points instead of 10, with the chain bonus applied on top, and gone after 7 seconds. On an empty board 7 seconds is enough to reach any cell from the second food onward, so the timer is not the real constraint. The route is, and in particular whether it passes through the space your own body is taking up. That is the self-collision rule doing the work.

Touch input had to be rebuilt. The original had a phone keypad. On a touch screen YoyoArena's version reads a swipe when the finger lifts rather than while it moves. The swipe has to cover at least 22 pixels, one touch produces at most one turn, and a shorter touch counts as a tap that starts or restarts a round. Only one turn can wait in the queue, so a second press inside the same tick replaces the first unless it would reverse it. How the game is built and shipped is covered in how modern browsers run a game.

Sources

• Snake (1998 video game) and Nokia 6110 (Wikipedia): the phone was announced on 18 December 1997 and released in 1998, and Taneli Armanto created the game for it.