Incremental Accretive Design

This is the practice of starting with an existing design (usually a big hit by the competition) and adding some tidbit to make it better. It is the primary method by which new games are produced. Now, most of the pressure to stay conventional comes from publishers who reason that God favors the product with the bigger bullet list, but this book is for designers, not publishers, and so I shall concentrate on the problems on the designer side.

The first factor behind incremental design is simple laziness. Some young hot-shot plays Game X and greatly enjoys the game, so he decides to build the same game, only better. The thought process is simple: How could I make Game X even better? The young designer always thinks in terms of adding some new feature to the existing design, some additional twist or complication that would make the game more complex and therefore, in the designer's mind, more interesting.

The flaw in this reasoning is that it assumes the same level of experience in the playing audience. To appreciate the new, improved Game X1, the audience must have mastered Game X. The game aficionados who loved Game X will indeed love Game X1, but lesser players will find Game X1 intimidating. Take this process through several iterations, with Game X2, Game X3, and so on, and you end up with ridiculously complex games that appeal only to the aficionados. Then some brave soul comes along with a new, clean design, and the cycle starts all over again.

Design is not an accretive process! Piling on more features does not necessarily make the game any better it just makes it more complicated. Some designers seem to revel in features, shoveling more and more gew-gaws into the game, as if the size of the pile of features is a measure of the quality of the game. Incorrectissimo! Making a game bigger doesn't make it better; it just makes it…bigger.

Subtraction is just as important an element of good game design as addition. Truly great design is always characterized by a stripping out of unnecessary detail, and this is true of all forms of media, not just games. Da Vinci deliberately left out details of the Mona Lisa's face to more clearly show that enigmatic smile. Michelangelo's statue of David knowingly smoothes out some details of musculature and erases some natural wrinkles in the skin to enhance the sense of bodily perfection. Shakespeare's Hamlet overlooks lots of important details about its protagonist to sharply delineate the dramatic conflict of the play. And every teacher knows that the only way to help a student learn is to give him carefully measured doses of truth, leaving out confusing details in the early stages.

Yet there are few games that show any flair for simplification. Sid Meier's Civilization is one; Sid was so brutal in his simplification of history that I sometimes wince at the game's inaccuracies. Yet the result of Sid's design parsimony was one of the greatest computer games of all time. I can see many places in that game where a lesser designer would have succumbed to the temptation to pile it on; Sid's discipline in cutting out the dirt should be emulated by all designers.

LESSON 19

Improving a game design requires both addition and subtraction.

Conceptualizing by Topic Rather Than Content

A young game designer once told me with obvious pride that he was working on a "King Arthur game." I wasn't cruel enough to point out that he had already blundered from the get-go by thinking of it as a "King Arthur" game. But the fact is, the topic of a game has little to do with the core design problems. Consider, for example, the various kinds of "King Arthur" books and movies. There's Disney's The Sword in the Stone, a saccharin family drama; John Boorman's deep and mysterious movie Excalibur, with its flamboyant sex scenes and its animal-like armor; T.H. White's Once and Future King; Marion Zimmer Bradley's The Mists of Avalon, a feminist rendition of the legends; Mark Twain's A Connecticut Yankee in King Arthur's Court, a clever social satire; Mallory's Le Morte D'Arthur, presenting the French reworking of the earlier Celtic legends; and of course, the original Celtic versions, as partially recorded in the Mabinogeon, with their deeply symbolic, almost Jungian psychology. With all these versions of the legends floating around, it doesn't mean much to define anything in terms of "King Arthur." The topic could be used for anything.

Novice game designers, in their earliest conceptualizations, think of a new game in terms of its topic rather than its system. They talk about building a science fiction game, a fantasy game, a wargame, and so on. Some even go so far as to define their game by the graphic technology, referring to their concept as a "first-person game." Whenever you launch your game project in this way, you have already doomed your efforts to failure. Indeed, you really haven't decided anything. To say that you're going to do a "science fiction game" is about as informative as insisting that you're going to build an "electronic game."

This kind of nomenclature is useful for marketing purposes, because marketing people can't be asked to think in terms of the fundamentals of game design. But you're not a marketing person you're a game designer. You must use the nomenclature most relevant to the problems you face.

Concentrate on the problem that really lies at the core of your game: its interaction. Is the interaction going to be a matter of fast reflexes? Deep strategy? Complex logic? Intuition? Human insight? Random trial and error? What's the challenge of the game? How will the player interact with the game? What does the user do? These are the crucial questions, and so at the very outset of the game conceptualization process, you must concentrate on these questions. After you have answered these questions, then you can ask yourself what topic best serves these goals? Then and only then can you decide the topic. Don't be dishonest with yourself if the topic really is the initiating concept in your thinking, then you simply don't understand game design well enough to do a good job.

It is certainly possible to be inspired by a topic, and use that inspiration to guide your conceptualization process. For example, I have always held the ancient Celtic versions of the Arthurian legends in awe, because they rumble with deep wisdom. For years I have had a vision of designing an Arthurian game. However, my very first step after the inspiration is to ask myself, "What is it about these legends that inspires me? What is the substance, the message, the concept that I want to convey?" For me, that substance is the problem of leadership. How do you lead people to greatness when they're caught up in petty disputes? How can you inspire them to look beyond the needs of the moment and see the glorious vision you can see on the horizon? These were the ideas that I wanted to express in the game; I still have not figured out how to accomplish this, so the game remains unbuilt. Perhaps some day, I'll pull it off.

LESSON 20

Conceptualize your design in terms of its challenge, not its topic.

Storyboards

Storyboards have been a standard tool in the game designer's kit. Their primary value lies in pitching the game to executives who don't understand interactivity. The basis for this lies in the vanity of people (especially executives) in the games biz. Storyboards are what people use for making movies. If we use storyboards, then we must be as hoity-toity as the movie people. Or something like that.

What, exactly, does a storyboard do to help organize and understand the project? Certainly the screen sketches showing the various screens in the game are useful, but we used to do that long before we used storyboards. Every game designer must prepare a complete collection of the screen layouts required at every point in the game. But there's a huge difference between a pile of screen layouts and a storyboard: The storyboard communicates sequentiality, which the screen layouts do not. In other words, the storyboard suggests that the various screens will come one after another in a specified order.

Now, you as game designer may realize that in fact the order of screens is not cast in stone, that there will be lots of variation in the order of screens. But when you nail down that sequence by using a storyboard, you are implicitly imposing that sequence on every member of the team. The implication is that the player will not have as much freedom during the course of the game, that the player must follow the assigned path through the game.

LESSON 21

Lose the storyboards.

Consider the evolution of programming practice. Back in the bad old days, we wrote spaghetti code because we had GOTO statements that made it easy to jump all over the program. In the early 70s, computer scientists had figured out that the GOTO statement was the cause of much programming anguish and began urging programmers to write "GOTO-less" code. And programmers did restrain themselves, but the temptation to use that handy-dandy GOTO statement was too great, and the use of that statement continued.

Then came the second generation of high-level languages, such as C, Forth, and Pascal, that simply excluded GOTO. At first, programmers were a little put off by this strange new style of programming, but after using it for a while, they realized that everything they could do with a GOTO statement could be done just as well in the new languages, and the resulting programs were much easier to understand and debug. They knew that GOTO-less programming was superior, but they really couldn't absorb the message until the mind-biasing tool was taken away from them.

Storyboards do to game design what GOTO statements did to programming: They encourage a way of thinking that's just wrong for the task. At their most fundamental, games are interactive, and a storyboard is an anti-interactive construct.

Over-Reliance on Tools

Tools are great; tools are wonderful. Some of my best friends are tools. The gargantuan effort required to create a modern game would be impossible to complete without an extensive library of tools. Hurrah for tools!

That said, let me now point out the dark side of tools, for those who are seduced by the dark side become the Darth Vaders of game design more machine than man.

There are four fundamental properties of all tools:

• Capital cost: It takes time to build a tool, time that is not itself productive.

• Greater efficiency: A tool permits a task to be completed in less time.

• Narrower application: A tool is designed for one specific task.

• Learning time: Every tool requires some time to learn to use it properly.

Consider, for example, the simple task of digging a deep, narrow hole for setting a post into the ground. At the simplest and quickest level, you could claw at the soil with your bare hands, moving it out a handful at a time. There's no time wasted on building a tool, but your work proceeds slowly. You could, of course, (1) take the time to build a shovel and (2) enjoy the greater efficiency that this would confer upon your efforts, but (3) unlike your hands, which can be used for a great many tasks, the shovel is good for little more than digging dirt. And of course, (4) it takes a few minutes to get the hang of using a shovel to greatest effect.

Now let's move up a notch. You build a double shovel, a device with two narrow shovel blades, two shovel handles, and a swivel connection. This hand tool (1) costs a little more to make, because it has two shovel blades and some extra mechanical connections, but (2) it is definitely more efficient at digging post holes, so the work goes faster. Of course, (3) this specialized shovel can't be used for general dirt-digging purposes; it can be used only for the narrower task of digging post holes, and (4) this shovel is trickier to use and takes some time to master.

Okay, let's go big time. You're gonna get yourself a post hole auger for your tractor. This baby (1) costs hundreds of dollars, but it (2) wowie zowie it can punch a post hole into the ground in seconds. Unfortunately, (3) it couldn't possibly be used for anything other than digging post holes, and (4) you better take some time learning how to use this monster or you're gonna punch a hole through your foot.

Now, the greater capital cost of a tool can be offset by the increased efficiency of the work it does but only if the tool is applied so many times that its cost is offset by the multiple small savings of using it. For any one-shot task, handwork is always faster than using a tool. A shovel is more efficient than using your hands only because, to dig a hole, you must claw at the ground many times. If you wanted to dig a divot-sized hole just once, you couldn't justify the purchase of a shovel for the task; it would be easier, cheaper, and quicker to just claw the divot out of the ground with your hands.

Thus, tool use in game design is only effective when the tool is used many times for a repetitive task.

NOTE

A quick terminological digression: There are cases where you might profitably purchase a special-purpose chunk of software that you integrate into your own code. For example, you might wish to purchase a library of 3D graphics routines for inclusion in your game. You might object that, in this case, the library is used just once, for a single application, and so refutes my claims about tool use requiring multiple applications to be cost-effective. The trick here lies in the fact that you are purchasing a library, not a tool. You don't use a library in the same manner that you use a tool; it's a different beast and obeys different laws of utilization. None of my comments in this section apply to software libraries.

The dark side of tool use is that, in your eagerness to make the tool cost-effective, you start to distort your approach to design problems to make them fit the special capabilities of the tool. The old saw that beautifully expresses this idea is, "When you've got a big enough hammer, everything starts to look like a nail." A big, expensive, powerful tool warps all of its users to thinking in the same way, engendering a homogeneity of thought into an entire community. If this homogeneity of thought clarifies thinking on a complex problem, then it is useful, but we must always be vigilant against the subtle influence that a tool exerts on our thinking.

Every tool is like a road: It takes you somewhere quickly and easily. A truly fine tool is like a freeway: It gets you there especially quickly. Of course, like a freeway, a fine tool attracts a great many users, all of whom end up going to the same place, and if you take the freeway, you end up at a crowded beach. It's a big world out there; if all you ever do is stay on the freeways, you won't see much of it. Sure, it's good to take the freeway to the general area, but few roads or freeways lead to mountaintops; ultimately, the good designer does not shirk from the effort of getting out of the car, donning hiking boots, and setting off across rough ground to reach that special place that nobody has ever visited before.

A prime example of this problem is the "level editor": a tool used to lay out the levels in games such as first-person shooters. They're certainly a good idea; laying out levels without a level editor is a tedious and boring task. Indeed, I wrote a little map editor for my first big hit, Eastern Front (1941) that was functionally the same as a level editor. However, look how the existence of level editors has distorted the evolution of first-person shooters. By making it easy to build big complex levels, designers started providing their games with lots and lots of big complex levels. By itself, that's not a bad thing, but the ease of providing value through level creation distracted designers from other, possibly more interesting directions of development.

Take weapons, for example. There are all sorts of possibilities for wild and crazy weapons in first-person shooters. How about a weapon that shoots both forward and backward simultaneously? Wouldn't that be handy when you're surrounded? Or a weapon whose impact increases with range, encouraging long-range fire? Or a weapon that requires time to build up to full strength? I used both of these ideas in an early game design howcum nobody has tried something like this in modern first-person shooters? The problem is, it's so easy to offer value by providing lots of different levels that it's not cost-effective to offer value by providing lots of different weapons.

LESSON 22

The tool has a strong influence on the weak-minded; we must be wary.

Or how about monsters? I can imagine a hundred different monsters to put into a first-person shooter. A monster that slimes you so that you move more slowly for a few minutes, bogged down with monster slime. A monster that bounces up and down three times, then explodes, forcing you to time your exposure but duck at the right instant. A barrel-shaped monster that's indestructible and rolls about, crushing the unwary easy to avoid but impossible to kill. These are all simple, almost obvious ideas, but they and hundreds of other ideas have not been explored in first-person shooters because it's too easy to use a level editor instead of thinking up something really new.

What's especially interesting about these examples of mine is that I haven't played a first-person shooter since Doom II (although I did look at Half-Life). There must be scores of first-person shooters that I've never seen, and here I am shooting off my mouth about ideas that have "never" been implemented. For all I know, every single one of my ideas could have been done already. But such is my confidence in my theoretical analysis that I can make such extreme statements with serene confidence. Either somebody will make me eat crow by pointing out my error, or I will appear to be blessed with godlike omniscience. It's all done with theory, my boy.