Boulder Dash: The Grid That Taught Physics

Almost every game you play was authored. A designer decided that this door needs that key, that this jump should be just barely makeable, that the boss has three phases. The content is a series of decisions somebody made, and playing it is a conversation with those decisions.

Boulder Dash was mostly not authored. Peter Liepa wrote down a handful of rules about what a rock does when there is nothing underneath it, ran them across a grid sixty times a second, and the game fell out. Forty years later people are still finding new things inside those rules, which is a claim you cannot make about very many designed levels.

The rules, in full

Here is essentially the entire simulation. A boulder or a diamond with an empty cell beneath it falls. If it is resting on top of another rounded object — a boulder, a diamond, certain walls — and there is space to the side and below, it rolls off. Anything falling from a height crushes what it lands on, including you. Dirt supports rocks; dig the dirt out and the rock has nowhere to be.

That is it. That is the physics. It fits in a paragraph and it runs as a local scan of the grid: for each cell, look at your immediate neighbours, apply the rule, write the result. Liepa has said directly that cellular automata and Conway’s Life were on his mind, which you can see in the shape of the code without being told. Life produces gliders and guns from four rules about neighbour counts; Boulder Dash produces avalanches, chain reactions and traps from about as many rules about support.

The origin story is worth having straight. Chris Gray brought Liepa a game he had written, and Liepa — who had been experimenting with automata on his own — rebuilt it around the falling-rock rule set. First Star Software published it in 1984, on the Atari 8-bit first and then the C64, and the C64 version is the one that colonised European playgrounds. Both men are on the credits and both belong there; the collaboration is the reason the game exists in its actual form.

Why emergence beats authorship here

The magic of the rule set is that it produces situations nobody designed. Dig a tunnel under a diamond and the diamond falls, which you knew. Dig a tunnel under a diamond that is sitting on a boulder that is wedged against a wall, and what happens next is a small cascade that resolves in a state you did not predict and now have to live in. The cave has changed permanently. You caused it. Nobody wrote it.

This is the property that keeps Boulder Dash alive. An authored puzzle has one solution and a fixed amount of content — once you know it, it is spent. A rule system has a state space, and every cave is a starting position within it. The sixteen caves that ship with the game are hand-placed arrangements, and Liepa was a good level designer, but the caves are prompts. The interesting bit is what the rules do to them once you start pulling things out.

Compare it to something like M.U.L.E., which is the other 1980s masterpiece of emergent systems and reaches the same place from economics rather than physics. Both games are small. Both have rule sets you can explain over a pint. Both generate more play than their file size has any right to. And both were made in an era when a designer could not fall back on content volume, because there was nowhere to put it.

The cruelty is structural

Boulder Dash will kill you for a mistake you made ninety seconds ago and have already forgotten. That is the direct consequence of a persistent simulation: actions have permanent effects, and some of those effects are that a rock is now somewhere lethal or, worse, somewhere that makes a required diamond unreachable.

Most games would consider that a bug. A modern designer would add an undo, or make the rock respawn, or gate the fatal configuration behind a check. Boulder Dash lets the cave become unwinnable and does not tell you. You can spend three minutes in a cave that has been dead since the first ten seconds.

I have a lot of time for this, and the reason is specific: the alternative destroys the thing that makes the game work. If the simulation is prevented from reaching bad states, then the simulation is no longer the authority — the designer is, standing behind it with a veto. The moment you know the game will not let you break it, every rock becomes a suggestion. The whole tension of Boulder Dash is that the rules are indifferent to your progress. They are just rules. They will happily arrange themselves into a position where you have lost.

That indifference is also what makes success feel earned. When you thread a seven-boulder cascade and come out the other side with the exit open, no designer congratulated you. The physics did what physics does and you were correct about it.

The amoeba, which is where it gets clever

The rule set has one component that behaves unlike the rest, and it is the best thing in the game. The amoeba grows into empty space at random. If you wall it in completely so it has nowhere to grow, it turns into diamonds. If you let it grow past a certain size, it turns into boulders.

Look at what that does to the player’s job. Every other element in Boulder Dash is reactive — it sits there until you disturb it. The amoeba has an agenda and a clock. Suddenly you are managing a growing thing whose growth you want, up to a point, and then you urgently want it contained, and the containment has to be built out of the same dirt and boulders you were going to use for something else. It converts a spatial puzzle into a timing puzzle without adding a single new verb.

Butterflies and fireflies do a version of the same trick — creatures that explode into diamonds or into empty space when crushed, turning your rocks into a manufacturing process. The magic wall, which converts falling boulders into diamonds for a few seconds after it activates, adds a resource with an expiry. Each of these is a small local rule bolted onto the same scan. None of them required a new engine.

A note on when I met it

Boulder Dash landed in 1984, which is right at the edge of my own C64 memory — the machine was in the house by then, and the tape that mattered was one that had been round several other houses first. I make no claim on the release. What I can say is that the game was still on the pile years after the games it shipped alongside had gone, and the reason was that it never ran out. A cave you had solved could be solved again a different way, because the rocks did not care how you had done it last time.

That durability is the argument for the whole approach. Content wears out at the rate you consume it. A rule set wears out at the rate you exhaust its state space, and Boulder Dash’s state space is large enough that a construction kit was the natural next product.

The line of descent

Repton took the grid to the BBC Micro. Emerald Mine took it to the Amiga and made it harder. Supaplex dressed it as circuitry. The Boulder Dash Construction Kit in 1986 did the obvious and honest thing by handing the rule set to the audience, which is what you do when you know the rules are the game.

The modern descendants are less literal and more interesting. Impossible Mission, the other 1984 C64 landmark, arrives at a similar destination — a game where the enemies obey legible rules and understanding is the only weapon — from the direction of animation and character rather than physics. Anything built around a consistent simulation the player learns by poking it, from the physics sandboxes to the deduction games, is doing what Liepa did on a grid of characters. Thrust is the closest C64 sibling: another game where the whole content is a physical law applied without mercy.

Boulder Dash runs on everything, has been remade a dozen times, and the C64 version is still the right one — it is the version where the scan rate, the sound of a falling rock and the size of a cave are all set where they were set originally. Play the first four caves and pay attention to what your hands learn without being told. That is the game teaching you a physics you were never given a manual for, one rock at a time.