Snake on a Nokia 6110 is one of the most-played games in human history. The reasons it endured are not nostalgia. They are a near-perfect set of design decisions, most of them accidental.
A Game That Outlived Its Platform
The Nokia 6110 launched in 1997 with a built-in game called Snake. The phone is long gone. The phone company that made it is essentially gone too. 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 currently still one of the most-played casual games on the web.
If you were designing a game in 1997 to outlast everything around it, you would not have written Snake. The graphics are a monochrome 84×48 LCD grid. The game logic is a few dozen lines of code. 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, twenty-eight years 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:
- The snake moves continuously in one direction.
- Pressing a direction key changes the snake's direction (with constraints — you cannot reverse).
- The snake eats food, grows longer, and scores a point per food eaten.
- Hitting a wall ends the game.
- 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. Tetris pieces stacking faster on top of accumulated lines is another. 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 multiplayer (one variation, big change). Snake Cube added a third dimension (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. Even modern players who would not deliberately choose a thirty-year-old game often end up playing one and remembering why it was loved. YoyoArena's Snake is in the library precisely because the game works as well in 2026 as it did in 1997. The design has not aged. The platform has changed; the game has not.
A Closing Thought
There is something humbling about a game from 1997 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.
