We usually think of game design as a process of creation where a designer conceives a game in their mind and projects it into the world. In this article, I propose an alternative metaphor. What if design isn’t a process of creation at all? What if it is a process of exploration?
THE LIBRARY OF BABEL
Jorge Luis Borges’ 1941 story The Library of Babel describes a universe that consists of nothing but a gigantic library. This library contains all possible 410-page books. This means that somewhere in its near-infinite stacks one can find a book holding every combination of characters that can fill a 410 pages. It holds a book that is 410 pages of nothing but the letter a. It also contains a book that is all a’s except the last letter, which is b. And so on through every combination of letters.
Since every possible book is represented, there is nothing that can be written that is not in the Library. The vast majority of the Library is gibberish – just random strings of characters spelling nothing. But hidden away on its shelves one could also find
Everything: the minutely detailed history of the future, the archangels’ autobiographies, the faithful catalogues of the Library, thousands and thousands of false catalogues, the demonstration of the fallacy of those catalogues, the demonstration of the fallacy of the true catalogue, the Gnostic gospel of Basilides, the commentary on that gospel, the commentary on the commentary on that gospel, the true story of your death, the translation of every book in all languages, the interpolations of every book in all books.
The Library of Babel is finite. There are only so many ways an alphabet can be arranged in a 410-page book. The number is far larger than the number of atoms in the universe, but it is still not infinity.
THE LIBRARY OF PLAY
The Library of Babel has many strange subsections. One holds every possible biography of your life, each written in a different style and emphasizing different aspects of your history, but all true, including your future and death. Another contains recipes for every conceivable way to make hamburgers. Another holds every religious creation myth imaginable. One holds every game design book possible (including my new one, recently published by O’Reilly, Designing Games).
I’m interested in one special subsection of the Library. This subsection contains a detailed description of every game design that could possibly exist. In it you would find every impossible-to-implement dream design that could be scrawled in children’s schoolbooks. You’d find the misguidedly huge design document I wrote for my mod Elemental Conflict years ago. You’d also find a perfect description of StarCraft II at its latest patched state, as well as perfect descriptions at all of its previous and future patches. I call this subsection the Library of Play.
The job of a game designer is to search through the Library of Play and find a design that fulfills their purpose of their game. If they’re making a kids’ educational game, they need to find a design that educates and entertains kids well. If they’re making a core action game, they need one that gets players’ blood pumping.
The designer does not invent the game. He navigates through the Library of Play and finds it. Because in a sense, every game design already exists as a possibility in the Library. We just have to unearth them.
If the Library were randomly ordered, all we could do would be to try designs one by one, keeping ones we thought were good until we ran out of time. And since the designs are random, almost all of them are completely dysfunctional as games. So this strategy would almost always return a near-worthless game.
But the Library isn’t randomly ordered. And this is the property that makes it possible for us to find smart ways of searching through it.
THE DESIGN LANDSCAPE
To think about how to search the Library of Play, we need to layer another metaphor on top of it.
Imagine similar designs are placed closer to each other. Two different StarCraft II‘s which vary by a single tuning variable are directly adjacent. The differently-patched designs of StarCraft II all fall in the same neighbourhood (though they’re not adjacent because each one is different from the others in several ways). Some distance away are all the differently-patched versions of the original StarCraft, which are related to StarCraft II but not as related as the different patches of StarCraft II. At some greater distance we find other RTS games like Age of Empires. Far away, in entirely different regions of Library, we might find the designs for Joust, Donkey Kong, Halo, and MineCraft. These games are very distant from StarCraft II because they are so different from it.
We can imagine all these designs as a sort of landscape. You might standing on top of Doom II, take one step, and then be on a version of Doom II where the zombies do slightly more damage. Walk a ways, and you might find the original Doom. Walk a much longer distance, and you might find Quake, and then Unreal. As you travel around the landscape, the design you’re on top of morphs every so slightly with every step you take. Some spot on this landscape corresponds to every game that could possibly exist.
Now we can imagine this landscape as having hills and valleys according to how well each design fulfills our design goals. A high peak is an elegant design that engages and fulfills players. A deep valley is unbalanced, dysfunctional, emotionally flat, and inappropriate for our design goals.
This is similar to the “fitness landscape” from evolution. Your design landscape might be different from mine if your design goals are different. BioShock might be a high peak for me if my goal is to create emotionally intense, art and narrative-drien single player games. But if you’re trying to make a casual multiplayer game for kids, BioShock is a deep valley since it serves none of your design goals.
(A side note: In reality, there are too many ways to change a design for all adjacent designs to fit together on a 2D plane. So the “landscape” actually has some massive number of dimensions corresponding to all the tiny ways that a design can change. There are all of the “directions” in which a designer can move. However, we can’t possibly visualize a surface in billions of dimensions. So for the purposes of visualization we can imagine this landscape as a 2D surface over which a designer can travel around. Just keep in mind that one design can have millions of neighbors and a designer can move in billions of directions away from any point – not just four.)
Another strange quality of this metaphorical landscape is that it is choked in fog. It’s hard to see anywhere except where you are. Often, the fog is so thick that you can’t tell whether taking a single step in one direction will take you up or down a slope. And it’s nigh-impossible to see peaks in the distance, except in the haziest of ways. This is the landscape you, the designer, must search. Your job is to find those high peaks of design perfection amongst the foggy troughs of boredom. You get no map and you can barely see.
But you do get one tool – an altimeter which can tell you how high you are. But this altimeter is slow and inaccurate, and you can’t move while taking a reading. This metaphorical altimeter represents the data you get by playtesting your design. Playtests tell you if you’re on a high slope or a low trough by the reactions of players. But they’re expensive and slow, and you have to stop and take the time to do them. This is why the altimeter is so limited and inaccurate. Good navigation information is hard to come by.
Given this situation, what method of exploration do we use to seek our peak?
Everything we do to try to improve a game’s design can be understood as a way of finding high peaks on the design landscape.
One strategy is to move slowly and take constant readings on the altimeter. This is the process of test-driven iteration, where designers make only small changes at a time, and confirm the effectiveness of their moves with frequent playtests. This hill-climbing approach is effective in that it is guaranteed to find a nearby peak. The problem with hill-climbing is that the nearby peak might not be very high. We might end up on top of a small hill, while Everest waits for us not far away in the fog, unexplored due to the timidity of our small-stepped approach.
We can hill-climb quicker. We might charging forward across piles of designs, barely testing them, not even really understanding them. This is more rapid development with less testing.
Many designers go fast at first, skipping across mountain ranges, then slow down near the end of development to hunt for the highest peak in the local area. This process of slowing down even continues after release – the years-long post-release balance patching on a popular game is akin to the designer shuffling around on the mountaintop they climbed during development, trying to find the largest cobblestone to stand on.
Sometimes we take giant, blind jumps, with only the vaguest idea of where we’re going. Notch’s MineCraft was inspired by Dwarf Fortress. In effect, Notch stood on the peak represented by Dwarf Fortress and saw an unexplored continent surrounding it. He took a giant leap across that block-building continent and landed on the slope of another peak that he called MineCraft. He then hill-climbed his way up to it, using the trick of publicly-released alpha builds to get accurate altitude readings. Most long, blind jumps are not nearly so successful. But they are the only way to escape the local-peak problem inherent to hill-climbing methods.
No designer walks the landscape alone. Imagine the design landscape as a buzzing field of activity. Popular regions teem with designers mapping the land in greater and greater detail, sometimes tripping over each other in the process. Other regions are largely ignored because they’re not peaks for most people – these areas represent niche games with few customers, so only a few designers brave these lands. Still others hold massive peaks, but nobody climbs them because they have yet to be discovered. Some designers speed wildly across the landscape. Others climb slowly, methodically, steadily up the nearest peak, checking altitude all the while. A brave few take giant leaps across continents. A few of those land on mountaintops; most fall in valleys and die.
THE SHAPE OF THE LANDSCAPE
The key to optimizing our methods of exploring the landscape is in understanding its shape.
For example, imagine there was one perfect game, and every other game was only a better or worse imitation of that game. Such a design landscape would have a single glorious peak and slope downwards in all directions. In such a Mount Fui-like landscape world, hill-climbing is the only coherent strategy.
But we don’t work on such a design landscape. The shape of our land is much more interesting than this.
First, the landscape is not totally random, but nor is it totally regular. It is a complex mixture of slopes, planes, peaks, and pits. Some regions may be relatively flat. In these areas, most changes to a design won’t affect its effectiveness. Other areas may be extremely spiky. In these regions, small changes can make or break a design.
Second, there are many high points. Some are close together: Halo is a good action shooter with friends, and so is Call of Duty 4. These two high points fulfill most of the same goals, but they are quite different (though not so different as to be on different continents). Some are far apart: Age of Empires fulfills many of the goals of Halo while living on a totally different continent.
Third, there are many steep drops. Tune one parameter out of whack, remove one character, and an entire design can collapse due to power imbalances or narrative incoherence. These steep pits appear even around the slopes and peaks of mountains; it’s easy to find small changes that can destroy even very well-developed designs. In fact, these broken designs are so common that they are the majority of the landscape; when we journey around we do it on the ridges between these deep fissures.
This shape suggests that we need a mix of search strategies to get the best results. We need some hill-climbing to find local peak, but we also need to take some great leaps to get over deep valleys.
The precise mix for any given designer depends on their creative goals and situation. Early in the process, make great leaps to find new mountain ranges. Later, hill-climb to optimize your situation. If you’re on a “spiky” region where small changes have large effects, go slowly. If you’re on a large flat plateau, move faster. The main exploring party of designers can send off smaller groups to scout nearby and distant lands. This is like breaking off prototyping teams, as Double Fine did to come up with the base designs for Stacking, Iron Brigade, and others.
The design landscape isn’t a final answer to any question. It is a mode of thought. It is a metaphor that pushes the mind into the mode of searching for a design instead of creating a design. And that’s a useful metaphor to flip into from time to time, because our core metaphor is the frame through which we see every design problem. A different frame can show us answers that we could never have seen before.
The idea of searching forces us to face our true ignorance about the design landscape around us. Nobody can see through the fog the way they wish they could, and nobody can plan a precise path up an unknown peak until they are climbing it. It makes us realize how small we are in this vast hyper-dimensional Library of Play that extends beyond the limits of a thousand imaginations. It makes us value the reliable observations we do have, because they are so rare.
So if you’ve got something good that you want to improve, climb slowly and carefully. If you’re starting wild and want to do something new, close your eyes, muster your courage, and jump.
Cross-posted from tynansylvester.com
This article was inspired by a chapter on the landscape of business plans in Eric D. Beinhocker’s The Origin of Wealth (Harvard Business School Press, 2006), starting around page 233.
Borges’ story The Library of Babel can be read in English translation here. You can read the wiki page here.