Chris Crawford on Game Design, Chapter 21: Balance of Power
Chapter 21: Balance of Power
by Chris Crawford

This excerpt has been taken from Chris Crawford on Game Design, 2003, New Riders Press.

In March of 1984, Atari was in its death throes and I, along with almost everybody else, was laid off. The severance package I received was more than generous; it gave us so much money that I wouldn't need any income for nine months. That would be plenty of time to develop a new game; I set to work considering my options.

It was tempting to do yet another Atari game; I had mastered the platform, my name alone would sell games, and I had a number of good ideas. I built two prototypes, one that I called Western Front (1944), a simple translation of Eastern Front (1941) to France. The other I called The Last of the Incas, covering the struggle of the last Inca emperor to raise a revolt against the Spanish. I quickly rejected the first option as too derivative. Besides, I was finished doing wargames; they no longer held any creative attraction for me. This decision was, in financial terms, imbecilic. I had a big hit in Eastern Front (1941); a second game in the genre would surely make a bundle of money. Artistically, it was a sound decision: If you've mastered a problem, it's time to move on. This provides us with a useful criterion for establishing motivation (Lesson 47).

The Inca game struck my fancy, but I decided that it was time for me to make a break with the past, to look forward rather than backward. It was time to make the jump to a new machine.

Three options lay before me: the IBM PC, the Macintosh, or the soon-to-be-released Amiga. I quickly rejected the first option—nobody played games on the IBM PC in those days. Besides, it was a horror to program and supported only text displays. I interviewed at Amiga, and they offered me a job, but I decided that the Macintosh would do to Amiga what the Apple II did to Atari. Although the Amiga had superior hardware, the Mac's overall design impressed me. I was especially impressed by its emphasis on user interface. Here, I decided, lay the future. Choosing between the Mac and the Amiga was one of the more momentous decisions I ever made, and I made the right call.

---

Sequels are for entertainment; they have no artistic content.

---

So I signed up for the Apple Developer program and ordered a development system consisting of a Lisa computer and a Macintosh. It was very expensive; worse, I had to wait for two months to get my Lisa. I used the time to think long and hard about my design. I also collected and read a great many books on geopolitical conflict. The most influential of these were Henry Kissinger's two books on his years in power: White House Years and Years of Upheaval. You are welcome to think ill of the man's politics, but I must insist that his books are illuminating and well written. They certainly had a large influence on my design.

The UnWar Game

I was, and remain, a child of the 60's. Although I never marched in a demonstration, smoked dope, or took any kind of mind-altering drug, I embraced the core values of the 60's counterculture, the most prominent of which was pacifism. War, in that view, was the greatest evil mankind had ever created, and was to be avoided at all costs. As the 1984 electoral campaigns heated up, there was plenty of belligerent talk from the right wing, and a series of alarming events boded ill for the future of peace. And here I was, profiting from the sale of wargames, and contemplating designing even more. It was wrong, and I knew it. But what could I do?

---

Don't struggle to find the answer, struggle to find the right question; the answer will then be obvious.

---

As soon as I had phrased the problem in that form, the answer was obvious: I would design an unwar game, a game about the prevention of war, a game about peace. After weeks of feckless hand-wringing, it all became perfectly obvious once I had phrased the question in the right terms.

Now, there have been plenty of "nice guy" games in which players are encouraged to love each other, be nice to the little bunnies, and throw away their weapons. Unfortunately, these "cooperation" games all share one crucial problem: They were boring! Recall Lesson 10: A game, like a story, must have a conflict.

The taxonomy of play in Chapter 1, "Definitions, Definitions," shows that games are a form of organized conflict. So my task was to design a game that was full of conflict, but lacked war. This is not so difficult a challenge as it might seem at first. As von Clausewitz noted in On War, "War is the extension of policy to other means." In other words, it is an extension of geopolitical conflict, not the first manifestation of it. War arises when conflicts between nations cross the line from peaceful into violent expression. Hence, there can be plenty of conflict in an unwar game—it's just not violent conflict.

I found my theme song for the project in Peter, Paul, and Mary's rendition of Bob Dylan's "Blowin' in the Wind." The killer line was this:

How many deaths will it take 'til he knows that too many people have died?

This project pushed me to my emotional limits; listening to that song gave me the strength to carry on.

Early Efforts

My first written reference to this design comes from April 1984, just after I was laid off by Atari. I called the game Arms Race, and here is the complete description:

This is...the game I have been wanting to do for a long time. I propose a game that shows why the US and the Soviet Union are locked into a dangerous balance of terror. You are the President during the entire 40-year span of the game (1960–2000). All you have to do is get to the turn of the century without igniting Armageddon. It's not easy. The game is actually about geopolitics, not the arms race per se. You are tied into numerous alliances with small countries the world over. The complex web of obligations is constantly being strained by the petty disputes of the small countries. The small squabbles can erupt into war at any time, and the danger always exists that events could suck you into a major confrontation with the Soviet Union. The central question of the game, then, is to ask whether the US and the USSR can carry on a global rivalry without eventually getting themselves into a nuclear war. The answer, of course, is that they can do so only by rigorously constraining and reducing the scope of that conflict.

The game would use a smart map that presents a great deal of information about nations and their relationships in graphical format. Icons would show treaty obligations, military status, bases, and so forth. Animation would be used in much the same way as other Macintosh software uses animation: to show relationships.

This game would be serious, it would be very educational, and I think it would grab a great deal of attention. It would not be action-packed, but I think that the launching of Armageddon would be far more wrenching in this game than Missile Command ever was.

As I set to work designing the game, I took some time to study the Macintosh and develop an appreciation of its strengths and weaknesses. I laid these down in a long letter to a publisher. I concluded that the black-and-white display would have less sensory "heat" than the color display of the Commodore 64, the dominant machine at that time, and therefore that Mac games should be more cerebral. Moreover, I suspected that the market of Macintosh owners would be a more serious, more adult group demanding a more mature style of game. I also felt that the mouse, a new input device at that time, was not ideally suited for fast action games; it was better suited to discrete choices than continuous input.

---

Know thy platform intimately. Understand its strengths and weaknesses.

---

There was more in the letter, but the key point here is important: I took the time to consider the precise strengths and weaknesses of the platform on which I proposed to work. These careful considerations paid off; later, after Balance of Power was published, several reviewers complimented the game for its deep "Mac-ishness."

By May I was deeply caught up in design details. I toyed around with a number of possible titles: Arms Race, Annihilation of Mankind, Stopping the Madness, Thwarting Armageddon, Man's Last Decade, The Extension of Policy, Words vs. Bombs, and Policy. Plainly, these are all lame titles compared with the final title, Balance of Power. So where did that great title come from? The CEO of Mindscape during my first meeting with him. He just pulled it out of a hat.

In accordance with my most sacred rule of software design ("What does the user do?"), I set down my verb list at the outset:

• Arm insurgents.

• Provide shelter to insurgents.

• Give economic aid.

• Give military aid.

• Sell weapons.

• Apply trade sanctions.

• Intervene militarily.

• Sign mutual defense treaty.

• Hold summit meeting.

• Set military spending level.

• Carry out a military demonstration of strength.

• Declare war.

• Blockade.

• Establish/break diplomatic relations.

• Set rhetoric level.

---

Game designers have no talent for marketing. Let the pros cook up the title.

---

The correspondence between this list and the final list of verbs is striking. Seven of these verbs did not make it into the final verb list—but some of them did make it in altered form. The primary difference between this list and the final list is that the final verb list segregated the verbs into groups organized by degree. The basic verb groups in the final version related to insurgency, government stability, and treaty relationships, with a special group of verbs related to the state of alertness of your own military.

The primary area that I cut from this list was trade. The problem with trade is that it's slow and undramatic. Trade sanctions slowly strangle an enemy's economy. A python may be just as successful a predator as a lion, but we don't see many football teams named after pythons. I reluctantly decided to strike trade considerations from the design.

The Rubber Map

One idea on which I fixated was the "rubber map." I was inspired by two books, The State of the World Atlas and The War Atlas. These presented world maps showing a great many factors, such as arms sellers, weapons spending, relative wealth, trade power, and so forth. Some of these maps were distorted in such a way as to indicate the relative standings of different countries in various dimensions. For example, the National Income map showed Japan as huge and Greenland as tiny. I thought that this would be an excellent way to graphically present a great many complex relationships. And so for weeks I struggled with algorithms, trying to find a fast scheme for reshaping nations to any desired set of sizes. After six weeks of effort, I gave up; I just couldn't come up with anything fast enough.

---

Know when it's time to throw in the towel on a feature.

---

Thank You, National Enquirer

Some months before, while waiting in a supermarket checkout line, I observed that the headlines in the National Enquirer appeared to be designed by a combinatorial algorithm using standard components such as Elvis, flying saucers, revolutionary new diet plans, freakish babies, secret things, etc. Reflecting further, I realized that indeed a great many headlines have a formulaic quality to them. Perhaps, I mused, someday I would write a headline generator program for harried editors.

Now that fantasy came back to me, and I realized that I could put that crazy idea to work in my design. I could have a headline generator that would present events to the player in terms of news stories generated by combinatorial algorithms. The basic form of my sentence template looked like this:

Subject Verb Direct Object Degree

Here, Subject referred to the country that was taking the action, Verb was the nature of the action taken, Direct Object was the country upon whom the action was being performed, and Degree was the intensity of the action. Thus,

USA offers $100 million in economic aid to Panama.

would have USA as the subject, Panama as the direct object, "offer economic aid" as the verb, and "$100 million" as the degree. Of course, internally these were represented by simple numbers: index values for the countries, verbs, and degrees.

Over the course of time, I embellished the headline generator. First came embellishments to the presentation of the subject. There were two of these: leader name and capital name. The code could substitute "Washington" or "President Reagan" for "USA." Naturally, I made these substitutions available for the direct object. Extending the idea, I added the name of the insurgencies of every country.

Representing degrees of action was easy in most cases: I needed strings for how much money, how many troops, or what kind of treaty was being signed. However, there was one kind of headline that posed more complex problems: the headline describing domestic events. For example, it was important to provide information on the progress of the insurgency. For such headlines, the basic template was this:

{Insurgency of country X} {is in this state of development}

In other words, it was just a subject and a statement of degree. This, I found, could quickly become boring. "Panamanian insurgency grows more powerful" just doesn't make for exciting reading. So I developed a scheme for providing some variety and color. Here's an example:

0*Anti-government guerrillas*Forces opposed to the government*% fighters*Members of the %*

0* launch a series of attacks on* fight with government troops in* carry out attacks on* take control of*

1* isolated villages* several remote towns* two provincial capitals* the outskirts of @*

3*. *

Here's how the system works:

• The first character, a numeral, denotes the method by which one of the succeeding text segments is to be selected.

• A value of 0 says that the segment is to be chosen randomly.

• A value of 1 indicates that the segment is to be chosen based on the rank index passed to the headline routine.

• A value of 3 indicates that there is no choice to make, and that the first and only segment is to be used.

• Segments, it should be obvious, are delimited by asterisks.

---

Fantasize. Play what-if games. Ask silly questions. Why aren't cows green like grass?

---

There are also text variables that are replaced by strings specific to the country. For example, the percent sign (%) indicates that name of the insurgency, while the ampersand (@) indicates the name of the capital. Thus, if we use Peru as our example, then we might get any of the following headlines:

Members of the Sendero Luminoso fight with government troops in several remote towns.

Anti-government guerrillas carry out attacks on the outskirts of Lima.

Sendero Luminoso fighters launch a series of attacks on two provincial capitals.

Pretty cute, huh? But even this became tiresome after a while, so I added a provision for multiple templates for each situation. This did the job; the headlines had enough freshness and color to achieve the needed sense of realism.

The sentence generator proved to be one of the most important ideas to emerge from the Balance of Power project. In particular, the text variables concept proved amenable to considerable elaboration. I developed and refined this technology through many of my projects, especially for Siboot. It later became the basis for the concept of substories that I developed for my work in interactive storytelling. It also set me thinking about the nature and role of language, which has been a fruitful line of inquiry for my research. And it all started from a whimsical fantasy in a supermarket checkout line.

---

Read! Read! Read!

---

Research

Meanwhile, I was reading everything I could lay my hands on. In all, I acquired and read about 15 books as part of my research, and consulted another 12 that I had already acquired and read. These books addressed many elements that I put into the game: the mechanics of insurgency and coups d'etat, global power structures, and so forth.

Among these were The War Trap by Bruce Bueno de Mesquita, which presented a mathematical analysis of how countries get themselves sucked into wars. The ideas in this book suggested a great many algorithms, but in the end, I didn't use them. Nevertheless, reading the book proved beneficial to the project, as it clarified my thinking on a number of issues.

Also useful was Essence of Decision: Explaining the Cuban Missile Crisis, by Graham T. Allison. This book brought home to me the dramatic nature of superpower confrontation, and was the inspiration for what eventually became the Crisis feature in the game.

Not all of the books were directly useful to the creation of the game; indeed, there was very little that I found that I could simply lift out of the book and insert into the game. But all that reading stimulated my thinking on the problems of the design; ultimately, I think that it was an important factor in the overall success of the game.

Building the Map

While I was doing all this reading, I kept myself busy with a simple project that consumed plenty of time. I needed a map of the world that I could fit into the Mac's 512x342 screen. Nowadays we'd just scan something in, doctor it a bit, and voila!—there's our map! Unfortunately, we didn't have scanners back then, nor did we have photo manipulation programs. Besides, I needed more than just an image; I needed a digitized map with individually addressable countries. In other words, I needed a data structure for each country that defined its boundaries. I had to have graphics of each and every country in the game.

My solution was simple and straightforward. I placed a wall map of the world onto the floor and taped semi-transparent graph paper over it. I then traced the borders of the countries onto the graph paper, conforming my tracing lines to the gridwork of the graph paper. Then I pulled out my tape recorder and set to work. "Germany," I would announce. "Starting coordinates 189 X and 118 Y." Then I would launch into a long monologue tracing the border in directional steps: "One north, two west, one north, three west, two north, one west, four north..." and so on until my tracing of the border had completed the circuit of the country. Then I would move to the next country.

When I had finished all the countries, I sat down at the computer and entered the data as strings. I'd type in the name of the country and the coordinates of the point of origin. Then I'd listen to the tape recording, typing in the steps: N2WN3W2NW4N.... As you might imagine, it was a slow and tedious process. This became the source data for my country images. During program initialization, the code read in all that data and converted it into manipulatable graphics objects. All in all, it took me about a week to create the map this way.

---

In each project, do at least one special task by hand.

---

I'm sure this primitive technique leaves you agog, half-expecting me to follow up with tales of walking five miles through the snow each day to get to school. But there's an important lesson here. The tool shapes the hand of the user; or, to use the more common expression, "If you've got a big enough hammer, everything starts to look like a nail." Nowadays we've got tools up the wazoo, tools to handle every aspect of game development. Many times, when a team starts working on a completely new project, the first thing they do is set to work building tools for the project. This is good, but it is possible to go too far with tools, as I pointed out in Chapter 8, "Common Mistakes."

Memory Headaches

In 1984, when I was working on Balance of Power, the Macintosh had just been released and was equipped with 128KB of RAM. This was twice what most computers had in those days, but I couldn't seem to fit the game into the available space. The graphics weren't the primary factor: they cost only about 15K. Part of the problem lay in the number of countries and the vast amounts of information I maintained about each country: the text strings for the country name, capital, leader, insurgency, and so forth. The code itself was also sizable, and of course, some of the RAM was taken up by the operating system.

Before the Macintosh, programmers simply took over the machine and all its RAM. The operating system was really nothing more than a set of utilities. But the Mac changed all that. We cowboy programmers had to learn to live under the operating system, abiding by its rules and using its systems. It was hard on us; the same mentality that enabled us to succeed in the Wild West atmosphere of early personal computers now chafed under the rules and regulations of the Mac operating system. Many of the cowboy hotshots of the 8-bit era couldn't adjust to the new regime and dropped away. Fortunately, I was blessed with the intellectual and psychological agility to adjust to the New Order.

---

Take no pride in facts memorized, but in ideas grasped.

---

An important lesson lies buried in this experience. My advantage lay in an unorthodox approach to technology. Most technical people take a shotgun approach to technology, memorizing mountains of technical details. That huge heap of knowledge constitutes the expertise on which they build their careers. Since that expertise is their basis of competitive advantage, technical people, and especially programmers, take much pride in the size of the pile of facts that they have stuffed into their heads. This has the pernicious effect of rendering programmers insensitive to the demands that technology makes upon its users. Programmers revel in the arcana that torture users. But what goes around comes around; the mind that is stuffed with bucketsful of technological trivia becomes bloated and slow-moving; the inertia created by all that expertise retards further learning. Programmers are mostly young because they reach their mental capacity sometime after their 30th birthday, after which they ossify.

My advantage I owe to my physics professors, who ground into my stubborn skull the single question, "What is the essence of the problem?" Always dive down into a problem and get your hands on the deepest issue behind the problem. All other considerations are to dismissed as "engineering details"; they can be sorted out after the basic problem has been solved. And so I have equipped myself with a bloodthirsty drive to purge all facts from my mind. If it's a principle, I want to understand it; if it's a fact, I want to forget it. Facts clutter the mind; ideas organize it. If I can fit a fact into the larger structure of my understanding, then I can retain it; otherwise, it slips from my mind like water from a steel cage. I can't remember names, faces, or telephone numbers, but I can absorb new ideas even into my fifties (although I'm starting to slip).

Making It a Game

The game took shape during the fall and winter of 1984; by early 1985, it had reached an early alpha stage. All the important features were in place, considerable debugging and polishing remained, and some housekeeping functions still needed work. But one problem towered above all others: The game just wasn't entertaining. It functioned well as a simulation, but it didn't grab the player. I struggled with this problem from January until it was completed in July. The problem broke down into several sub-problems.

First, there was too much information for the player to assimilate, and little of that information was truly significant to the player's decisions. The solution to this problem was to simplify the game by lobotomizing all countries save the two superpowers. My original intent had been that the petty wars between minor countries could drag the two superpowers into a nuclear war, but in practice, I found that minor countries generated lots of petty activity in addition to their minor wars. The only way to clean up the game was to reduce the minor countries to the status of pawns. Note, however, that in the process, I concentrated activity onto the two superpowers. That sharpened the conflict and improved the game.

---

Polish, polish, polish! Take a minimum of six months after alpha for polishing.

---

Another problem was that the critical information wasn't immediately obvious to the player. Fortunately, an easy solution to this problem presented itself: instead of expecting the player to go looking for it, I shoved it into his face. At the beginning of each turn, the news display popped up unsolicited and presented the most important news item. This required that I develop a criterion for the "importance" of each news item. It wasn't difficult; all I had to do was assign a native importance to each verb and then adjust that native importance by the intrinsic importance (power) of the countries affected.

The third sub-problem was the most subtle: The information needed to be organized for the player. Months of effort went into sorting it out, adjusting font sizes, reorganizing screen layouts, and, most importantly, layering the information by priority. My proclivities as a control freak were to give the player as much information as possible, but I failed to realize that too much information can be just as uninformative as too little. And so I struggled through the basic problems of graphic design.

In the end, there was no breakthrough. No single idea or alteration transformed the game into the award-winning design that we shipped. A slow, tedious process of playtesting, polishing, and tuning, spread over six months, was required. For reasons outside of my control, publication of the game was delayed by four months, during which time I continued to polish, polish, polish. I now believe that this extra polishing was the most important factor in the success of the game.

Publisher Woes

I had no publisher when I began work on Balance of Power. 1984 saw the collapse of the videogames business, and publishers were dropping like space invaders. They were too terrified to take a game like Balance of Power. Months dragged by and my agent couldn't find any takers. Our savings were running low and I was beginning to worry about making ends meet. Fortunately, in early January of 1985, Random House agreed to take the game. I met with the publisher and we saw eye to eye. We signed a contract, I got an advance, and my financial troubles were over.

But then the publisher handed the project off to an editor and things started to go downhill fast. That editor and I had been preordained in some distant past to do battle. He was a good person, but his particular weaknesses found perfect syntony with my own, and together our clash reverberated to ever-greater amplitude. At one point, I fixed him with a cold eye and asked: "You don't know anything about games, computers, or geopolitics. Why are you the editor for this project?" My question was right on the mark, but he didn't blink. "Because that's my job," he shot back. We were both right, and in our incompatible correctness, we failed spectacularly. After just three months, Random House pulled out of the deal, and I was suddenly in worse financial straits than before.

That was the second-worst period of my life. We were facing financial ruin. My wife, losing patience after I had played freelance game designer for a year, demanded that I get a "real job." Nobody wanted the game. At this point, any rational person would have coldly calculated the odds and taken my wife's advice. But I was possessed by my noble ideals and absolutely certain of the greatness of the design. I ignored all advice to the contrary and pushed on.

The angel that descended upon me was Scott Mace, a columnist for InfoWorld. Somehow he learned of my predicament and did a two-part story on Balance of Power. That story in turn was read by a junior producer at a new startup in Chicago, Mindscape. That producer knew me from my reputation and forwarded the Infoworld story to his boss with a strong recommendation that Mindscape acquire the game. And they did. I was saved.

I Get by with a Little Help from the Press

Balance of Power was published in September of 1985. It attracted a great deal of press attention. In particular, the New York Times Sunday Magazine assigned David Aaron, Deputy Assistant to the President for National Security Affairs from 1977 to 1981, to write a story about the game. Aaron wrote a long piece that concluded as follows:

...Balance of Power is about as close as one might get to the cut-and-thrust of international politics without going through confirmation by the Senate.

That story was reprinted in newspapers all over the country, and sales started climbing. By the time the IBM PC port was ready in the fall of 1985, publicity had grown and sales really took off. My game became a big hit, generating some $10 million in sales—this at a time when total sales of all video and computer games put together amounted to about $500 million. I earned huge royalties on it and my wife, who had urged me to get a real job, never questioned my career choice again.

The Wheel of Fortune

During my latter years at Atari, I became known as "Mr. Atari" among user groups and developed quite a reputation. I was a big shot and, as befits my youth, it went to my head. I actually started to believe the adulation that splattered all over me. But then Atari collapsed, and overnight I became Mr. Nobody. I couldn't understand why I was so suddenly passé. For two years I labored in solitude, ignored and unadulated. But then Balance of Power became a big hit and I was Mr. Bigshot again. This time I was a little more suspicious of the capriciousness of fame; this round lasted about eight years, largely because I added a number of games and the Computer Game Developers' Conference (CGDC) to my fame portfolio. But once I left the CGDC, the crowd turned its back on me and once again I find myself bereft of the screaming masses of nubile nymphs. Miser me! I suspect, however, that once interactive storytelling gets rolling, I'll be back up there in the spotlight with flashbulbs popping and a starlet on each arm. And if that does happen, I'll remember Lesson 57.

© Copyright Pearson Education. All rights reserved.

Discuss this article in the forums

Date this article was posted to GameDev.net: 6/30/2003
(Note that this date does not necessarily correspond to the date the article was written)

See Also:
Featured Articles
Game Dissection and Analysis
Sample Chapters

© 1999-2011 Gamedev.net. All rights reserved. Terms of Use Privacy Policy
Comments? Questions? Feedback? Click here!