Interactive Storytelling Tools for Writers

The explanation of Balance of Power presented in this book has a neat and tidy appearance. One might easily get the impression that the creation of the game was a straight-forward exercise, a simple matter of sitting down in front of the computer and transferring the information presented in these pages to the computer. The true situation is more like that of the diver who, when asked by the sportswriter, “How did you manage to execute a double Fournier backtwister coming out of a swan dive?”, answers, “I don’t remember anything after my foot slipped on the edge of the board”.

The process of creating Balance of Power was likewise a series of midair thrashings whose outcome has a deceptive elegance. I had, of course, a guiding sense throughout the process, but a great many of the most important decisions were made for the most unlikely reasons. Now that it is all over, I would like to be able to say I planned it that way, but that is not true. In this chapter, I hope to present a chronological explanation of how Balance of Power came to be. This might instill a greater sense of sympathy in the reader for the travails of game design, as well as some insight into the design process itself.

One last prefatory comment: The concepts behind the game evolved with time. That is, I did not start out with a fixed set of notions and then express those notions directly through the computer. Instead, the attempt to express my thoughts on the problems of geopolitics helped refine and correct them. One of my English teachers used to badger me with the slogan, “If you cant say it, you dont know it!” His slogan is also applicable to a programmer. As long as you are basically literate in programming, you should be able to express in code any logical relationship you understand. It therefore follows that any logical relationship you cannot express, you do not understand. I have found that this principle can be turned around: If you don’t understand a logical relationship, you can use the attempt to program it as a means to learn about it. So it was with Balance of Power. As I worked on the game, my understanding of geopolitics improved and my improved understanding was incorporated into the game.

Prehistory
The seeds that would lead to Balance of Power were planted in 1966 and 1968. The first was planted by a high school friend who introduced me to commercial wargames. I took a liking to the games, but they remained a minor interest for seven years. The second seed was planted when my father let me play with the computer at his job; I had a lot of fun but, again, did not devote myself to the study of this strange machine. During my undergraduate years I dabbled occasionally in both wargames and computers, the first for fun, the second for schoolwork in physics.

It was at graduate school that two chance events rekindled the flames. I happened to run across a copy of Strategy & Tactics, a magazine that discussed the history behind the wargames. I was fascinated - the wargames I had played suddenly took on a new meaning to me. I resumed playing them, and began studying the history of war with renewed energy.

The second event came just a few months later. I ran into a fellow at the university computer center who was writing a program that would play a wargame. The very notion flabbergasted me: How could anybody hope to write a program to handle the myriad problems of wargame play? I could not take the fellow seriously.

By the time I received my masters degree in physics, I had a consuming passion for computers, wargames, and the history of war. I took a job teaching physics and pursued all three interests. I tackled the problem of programming a computer to play a wargame, and surprised myself by getting a working game running on the school’s tiny IBM 1130 computer after only six months’ effort. I first showed it to other wargamers in December, 1976. It was, to my knowledge, the first recreational computer wargame.

It was also at this time that I first became aware of microcomputers. I was immediately obsessed by the notion of owning my very own computer, and in January of 1977 I realized my dream with the purchase of a KIM-1 single-board computer with a 6502 processor and 1K of RAM. I taught myself machine language and had my first game running in a month. Over the next twenty months I expanded my system and developed a wargame for the machine.

Then in September, 1978, I purchased a Commodore PET computer and began redesigning my wargame to run on the PET. I sold my first copy of the game, called Tanktics, on December 31, 1978. I developed another wargame, called Legionnaire, in early 1979. But I was already beginning to tire of simple wargames; I wanted to design a game about the larger problems of war and peace, not just the mechanics of warfare.

Early attempts
My first attempt at a game modeling geopolitics was made in July, 1979. The game was called Policy. What I had in mind was a strategic wargame in which wars were meant to be minor. There would be a number of combatants, and no one would have the resources to fight a total war. Instead, wars would be small, localized affairs aimed at weakening an opponent or seizing some territory. The target machine was a Commodore PET with 8K of RAM, and most of the program would be written in BASIC. I worked on the game for only a month and got a portion of it running. Then I realized that it was fundamentally flawed: It had evolved into a strategic resource-management game. You spent most of your time in the game just shuffling around your resources. The games architecture didn’t support its point. I set it aside while I handled the problems of moving to Silicon Valley for my wifes new job. The next thing I knew, I was working at Atari, and Policy was shelved for good.

While at Atari I worked on a variety of simple games. The marketing experts were confident that no game so complex as a wargame, much less anything like Policy, could ever attract much of a market. For two years I worked on a variety of other projects. Then in December, 1981, Dr. Alan Kay hired me into his Corporate Research Group at Atari with a mission of creating original new games. I set to work on a grand game based on the Arthurian legends; that effort consumed eighteen months of my time and resulted in Excalibur.

One year later I was able to hire a new programmer to work on a new game, and I was determined to return to the geopolitical theme that I had attempted with Policy. However, this time I had much grander goals. In the first place, I set as the target machine an Atari 800 with 48K of RAM and a disk drive, programmed in assembly language. This was a machine with considerably more horsepower than the first, and my plans were suitably grander. In the interim, I had read Henry Kissinger’s White House Years and was impressed with the complexity of modern diplomacy. My goal with this game was (to quote a design document prepared during planning) to ‘teach people about the intricacies of the arms race’. The emphasis on this game was weapons development and deployment. The options available to the player included such complex things as ABM systems, Civil Defense programs, ICBMS, cruise missiles, satellite weapons, and so forth. You could also sign treaties to prevent deployment of such systems, or dismantle existing ones. Initially, the basic idea of the game was to come up with a mix of weapons systems good enough to deter a Soviet attack yet somehow pursue an arms control strategy that would keep your country from going bankrupt. We spent a great deal of time trying to work out the details, but could not seem to come up with a balanced design. Later on, we decided to make the game more theoretical in style, with only seven nations, and four dimensions of interplay between them: trade, weapons sales, treaties, and public relations. The game was beginning to take form when the programmer lost interest in the project, and I eventually assigned her to another project.

As luck would have it, barely six months passed before I had another opportunity to try again with my peacegame. Another group at Atari was developing a bulletin board system and wanted a game for the system. A deal was made: They would supply the programmer if I would supply the design expertise. As it happened, the person assigned was a good friend of mine who was also knowledgeable about games. So I set to work on designing a multi-player game of international conflict. We agreed that this would not be a conquer the world game, as some telecommunications games had become. Instead, we imagined a game of geopolitical conflict, with a great deal of negotiation going on between the parties and a very small amount of military conflict. Unfortunately, the collapse of Atari led to the programmer’s being laid off before serious work could commence.

The genesis of Arms Race
Three times I had begun work on my game of geopolitical interaction; three times the project had fallen apart. On March 16, 1984, I was laid off from Atari. It was time to define a new project. I had followed the introduction of Apple’s Macintosh computer with great interest and quickly resolved that my next game would be designed for this machine, which I viewed as a game designer’s dream - lots of horsepower and a well-defined and expressive user interface. On April 6, 1984, I sent a letter to a software publishing house presenting a list of games for discussion. Among the games on the list was one called Arms Race. The one-paragraph description said:

Here is Balance of Power for the first time. In the three previous versions I had struggled with a variety of ideas, among them resource management, weapons development, and multi-player concerns - but this was the first statement that captured the essence of what was to become the final game. Note the reference to new technologies of mass destruction, as well as the title itself. I couldn’t quite shake free from weapons development as a subject for a game.

Only three weeks later, the idea had developed considerably. In a letter to my agent, Steve Axelrod, I described the game as follows:

In just three weeks, the game had come a long way. There were still some misconceptions in this description, the most notable being the idea that confrontations would be caused by wars between minor countries. (What I had in mind was the Yom Kippur War of 1973.) This feature played a large role in my thinking until very late in the development of the game.

In early May, 1984, I decided that Arms Race was my next project and set to work gathering references and organizing my thoughts. Realizing the difficulty of the task before me, I wrote down my thoughts as I developed them. Now that the game is complete, these notes give testimony to the many dead ends and blind spots that arise during the course of the design process. Thus, on May 14, I wrote:

As it happens, only one of these variables (trustworthiness, which became Integrity) eventually made it into the game; oddly enough, the very next sentence captures the scheme that I eventually hit upon:

Later on, I added a question that players of Balance of Power will instantly recognize:

On the other hand, there were plenty of blind alleys. One idea I wanted was an endgame analysis that would critique the player’s performance, suggesting things such as, “Your weakness in the face of Russian aggression encouraged further adventures and disheartened your allies”. I had no idea how I would implement this feature, but it sure sounded nice.

Then there were problems of scale. I initially decided to have each turn of the game represent one month of time. This, coupled with the 10-year game span that I had by now settled on, implied a game with 120 turns to it! I did not realize at the time how long each turn would take, so I pressed ahead. This turned out to be one of the most bedeviling problems in the game design process. As I realized that the game took too long to play, I kept chopping down on the number of turns, first going to turns that were one year long, then going to games that were fifteen years, then ten years, and finally eight years.

Two other documents from the first month illustrate two of the problems of game design. The first and more trivial concerned the working title of the game. Consumers may not realize that very few games actually reach the market with the title that was originally chosen by the author. For some reason game designers make lousy title-pickers. Of my seven published games, only two were published under the original working title. All of the others were given new titles just before shipment. For example, Ourrah Pobieda was retitled Eastern Front (1941) and Three Mile Island became Scram. In May, 1984, I considered a number of possible titles: Annihilation of Mankind, The Extension of Policy, and Thwarting Armageddon. I finally settled on Arms Race. The game was designed with this title in mind. (Resourceful players who rummage around with the files on the disk can find a number of vestiges of this old title.) The final title, Balance of Power, was suggested by Roger Buoy of Mindscape (along with such alternatives as That’s the Way the Planet Crumbles) and it immediately stuck. It is, after all, a better title.

The more substantive issue was the nature of the verbs that would be provided in the game. Verbs are all-important in game design. They are the allowed actions, the permissible commands that are available to the player. A good set of verbs allows players to do everything they would need or want to do. A poor set of verbs will either confuse them with its arbitrariness, or lock them in a frustrating strait-jacket. The game designer spends a great deal of design effort worrying about the verbs to provide in the game. Thus, on May 11, I wrote down my list of intended verbs. It is longer than the eight verbs allowed in the final version of the game, yet not as clean or understandable. The verbs in the final version of the game fit together well, covering all the bases very simply and powerfully. One would not have believed that such a clean set of verbs could have evolved from the almost random list I first threw up. Here is that list:

Provide arms to insurgents
Provide shelter to insurgents
Give economic aid
Give military aid
Allow weapons sales
Apply trade embargo
Intervene
Offer mutual defense treaty
Go to summit meeting
Make military demonstration (attempt to intimidate)
Declare war
Blockade
Establish or break diplomatic relations
Set level of rhetoric

The italicized entries were the only ones that made it into the final game. All the others fell by the wayside during the course of development. It is a sad truth that most game designers aim high and always hit a little lower than they had intended.

Another effort during those early days was research. I collected every book on world affairs that I could find. The fascinating maps in The War Atlas (Kidron and Smith 1983) inspired me to emphasize a graphics-intensive display. I thought I had struck gold when I found a book entitled The War Trap (Bueno de Mesquita 1981). Here was a complete, mathematically expressed theory for the genesis of wars. It seemed that all I needed to do was program in the professor’s formulas, plug in some data, and I would have my game. Further study, though, disabused me of that idea. His work was very interesting but not quite germane to the goals of my game. It was reassuring, though, to know that somebody else had seriously attempted to express geopolitical interactions in mathematical terms. At least I wasn’t alone in the effort.

In June, I started writing little essays to myself on various aspects of the game. The purpose of these essays was to help me organize my thoughts on the game. In some of them I cut loose and dreamed grand things; in others I carefully plotted the details of bits and bytes that would be necessary to make the program run. It was during this time that I hit upon the central scheme that every government in the world would have its very own insurgency to bedevil it. However, I got a little carried away with this idea. First, I intended to have insurgency measured in terms of its military strength (this showed up in the final game) and also its popular support (this didn’t). Moreover, the government would be rated for its oppressiveness as well as its own popular support.

These essays helped me define many of the internal details of the game. Concepts such as diplomatic affinity, commitment, and credibility first appeared in these essays. More important, the essays helped me clarify my own thinking on the central problems of the design. Because of them, I was able to make tough design decisions with a clearer understanding of my priorities.

Based on all these considerations, I put together a proposal in early July. My agent was attempting to sell the game to publishers, who need a detailed proposal on which to base their considerations. The proposal was some fourteen single-spaced pages long, and describes the final product fairly well. One idea included in the proposal that failed to make it into the final product was the rubber map graphic. My intention here was to allow a player to select some variable, such as GNP, and watch the map distort so that the area of each country would be proportional to its GNP. Unfortunately, I was unable to derive an algorithm that would execute the rubber map graphic quickly enough, so I had to settle for the shading system used in the final product. Many people do not realize how many ideas must be tried, worked on, and discarded before the final product is defined.

I spent a good deal of space in that proposal attempting to address the problems of political bias and my own political goals in the game. The most important statements in this section were:  “This game will reject the notion that war is the product of evil men with hearts of hate....It will instead attempt to demonstrate that good men with good intentions can trap themselves in a situation from which war is inescapable”. This was a fundamental goal of the game, one to which I adhered throughout the long development cycle. I very much wanted to make people question their sense of moral superiority over leaders who get into wars. Maintaining peace takes foresight and wisdom, not merely good intentions.

On the all-important question of verbs, this proposal had whittled the verb count down to ten:

Set military spending
Set consumer spending
Set trade access of another country
Provide arms to insurgents
Offer economic aid
Offer military aid
Intervene
Offer mutual defense treaty
Declare war
Declare diplomatic warmth

Again, italics indicate verbs that made it into the final game. As you can see, I was zeroing in on the final verb set.

The last interesting item in this proposal, written in July, 1984, was the schedule. I projected a working version of the game by January 1, 1985, with final, tested, polished code ready on May 1, 1985. As is common with software proposals, this projection turned out to be optimistic.

Programming begins
During this time I had been designing without programming. I had a Macintosh but no development system for the Mac. In those days, the only way to develop serious Macintosh programs was on a Lisa computer. I had ordered a Lisa from Apple in May, 1984, but I did not receive the machine until August 1. So I spent the first three months of the project doing paper design. Without a development system, all I could do was read the manuals, study my references, and write proposals. As it happens, this can be a good thing...If it does not go on for too long. Too many games are hacked together at the keyboard rather than designed from the ground up. In this case, however, three months of paper design was too long because during the process I needed to test some ideas on the computer before I could proceed with other aspects of the design. It was with great relief that I took delivery of my Lisa and set to work on learning the system.

Many observers have commented on the difficulty that programmers seem to have learning how to make the most of the Mac. A common excuse for the dearth of software early in the machine’s life is the difficulty that programmers experienced in coming up to speed on the Mac. I did not experience such difficulties. True, I was intimidated by the complexity of the machine, but I was programming comfortably within a month. I suspect that the main reason for the delays so many programmers experienced with the Mac was the desire of the typical programmer to understand all aspects of the machine before undertaking a project. I was not so fastidious. My heavy use of MacWrite and MacPaint had given me a feeling for the machine’s capabilities - that was enough to get started. I plunged into the programming effort with wild abandon, learning only those features that I needed to know to solve a particular problem. This approach gets the job at hand done, but it can leave gaping holes in a programmer’s repertoire. Even today, two years after I started working with the Mac, I buttonhole other programmers with stupid questions about fundamentals of Macintosh programming. I am fortunate that other programmers took the time to learn all the tiresome details that I rushed past in my hurry to get the game done, and were then patient enough to explain their hard-won understanding to me.

Because so much of the game revolves around it, my first task was the creation of the map:

My solution to this problem is an object case in design philosophy. You can see that it is indeed an intricate representation of the world. How, people ask me, did I digitize it? My answer drops jaws: I did it by hand. I started with a map of the world, which I traced freehand onto graph paper. I then redrew the lines to conform to the rectangular grid of graph paper. I then scaled up the map to be more appropriate to the Mac’s screen. This rescaling was non-integral, so I did it by hand again, estimating rescaling values for each line segment. Some fudging here and there gave me the final map, represented on some two dozen sheets of graph paper. The only task remaining was to get it into the computer. I sat down with a tape recorder and started reading coordinates from the graph paper: “Nigeria. Origin at X = 138, Y = 227. One step north, 1 east, 2 north, 3 east …”  Then I sat at the computer and replayed the tape, typing in the values as they came tumbling off the tape. The string of directional steps marking the course of the border was translated into a compact sequence of numerals and single letters, like so: NE2N3E. I then wrote routines that converted these strings into the graphic representations of the countries.

Experienced programmers will shake their heads in dismay at this method. Surely there is some easier way to have done the work, some tool that would have made the effort go much faster. Undoubtedly there is. Here is where design philosophy comes in. A programming tool is like a freeway: It takes you somewhere in the universe of results. All programming tools are to some extent generalized to handle the needs of a large number of programmers. They are like freeways that take you to the most popular beaches or the most crowded resorts. He who would climb the remote peaks must forsake the comfort of the freeway and make his way by foot. The exertion of a week’s simple sweat can place the programmer on a mountain peak from which are visible new territories of creative opportunity invisible to those who veer away from steep grades.

During October I made one of the first painful deletions in the game: I removed all references to trade between nations. I had originally intended to have trade play a major part in the game. As I saw it, trade would play a large role in determining the rate of growth of each countrys GNP. Thus, each nation would want to maximize its foreign trade. This would make trade embargoes a useful weapon of geopolitical competition. I had therefore carefully researched the amount of trade between all nations of the world. This information was compiled on a huge sheet of graph paper, with the total amount of trade between each of the 3,844 pairs of nations in my game recorded in the appropriate square on the graph paper. I then entered all that data into the program. Unfortunately, a huge array of this nature eats up a lot of RAM; in this case, some 7,688 bytes were necessary to record trade. As early as October I ran out of RAM. Realizing that I would be needing far more RAM, I decided that something had to be eliminated from the program. Trade was the obvious target since its removal would free up a great deal of RAM in a single stroke.

This episode illustrates another murderous problem in game design: the need to balance resources in pursuit of the goal. A game designer has four finite expendable resources to bring to the game: RAM, disk space, the microprocessor’s execution time, and his own time. Almost every game design decision must take into account the impact of the various options on these precious resources. Sad to say, almost every desirable feature eats up large quantities of all resources. The beginning game designer often views game design as a feast at a table heaped with all manner of potential features; the hardened veteran thinks more in terms of a trek across a desert with limited quantities of food, water, and equipment.

All through September, October, and November I ground out the code. Apparently the three months I spent waiting for my development system gave me the opportunity to organize my thoughts so well that I was able to work very quickly once I did have my development system. By mid-November I had a working program that included many of the features of the final Balance of Power, yet remained in a formative stage. It was like a duckling who has the bill, webbed feet, and general conformation of the adult duck but is still far less than an adult duck. So, too, the November version of the game was recognizable but fell short of final product. It couldn’t even waddle.

Marketing problems
It was about this time that I realized that I was in serious financial trouble. The cataclysmic destruction of the entertainment software industry was just gathering momentum in early 1984, and would not peak until late 1984. Publishers who had seriously intended to do business with me in May were no longer in business in October. My agent and I had been confident that we could sell the Arms Race proposal by August. August came and went with no buyers. Other business proposals were equally fruitless. By November I was running out of money and had no prospective buyers for the game. Facing bankruptcy, I decided to compress the development cycle and wrap up the game in an unpublishable state by January 1. I didn’t know what I would do then, but there seemed little point in continuing a hopeless effort. I was ready to give up.

At this point Jim Warren intervened. Jim had founded the West Coast Computer Faire in the mid-seventies and played a pivotal role in getting the microcomputer revolution off the ground. His technical expertise, easygoing good humor, and sense of community are legendary in the microcomputer world. He had learned through friends that I was working on a grand, idealistic game about peace and war but was in financial trouble. He invited me up to his beautiful house in the Santa Cruz mountains, where we talked about my problems. Jim urged me to stick with the game. His encouragement and optimism inspired me to pick up the gauntlet again. Maybe it was the fresh mountain air, but I left that meeting thinking that I could somehow overcome all problems. Jim Warren saved Balance of Power.

Serendipity
In the midst of all these difficulties I came up with the single grand stroke that transformed the game: the crisis. My written notes from the time are sketchy; I was in the midst of one of those fevered brainstorms that does not admit time for pause. The crisis was initially created as a stopgap measure to solve the following problem: How do we prevent a superpower from pursuing an obviously outrageous policy? For example, what is there to prevent the USA from invading East Germany, or the USSR from invading Mexico? These are ridiculous policy options that no sane superpower would ever pursue, but this is a game, and players will attempt such things. What’s to stop them?

My quick and dirty solution was to allow any country to deplore any other country’s actions. My original intent had been that deploring would be little more than posturing, a way to stimulate international condemnation and consequent loss of prestige for a particularly outrageous action. Somewhere I got the notion that the offending party should have the opportunity to reconsider its action and reverse the policy. From there it was only a short step to the concept of the escalating crisis, with each party alternating in its consideration of whether to escalate or back down. And from there the addition of DefCon 1 and the consequent loss of the game added a tremendous boost to the excitement and intensity of play. Of course, there was still a great deal of work required to make the crisis work neatly. I continued to polish the crisis segment of the game right up to the very end of the development cycle.

It is my duty to admit that this, the most important single feature of the game, was never mentioned in any of my planning documents. For all my advocacy of careful design and maintenance of purpose, I have to admit that this was just a stroke of luck. These things happen. The seasoned game designer does not embark on a project expecting a brainstorm halfway through to make the game. Careful design and planning make good games; the addition of a lucky stroke of genius, developed masterfully, makes great games.

The Random House interlude
The outlook for the game took a dramatic turn for the better just before Thanksgiving, 1984. Random House expressed interest in publishing the game. Negotiations proceeded during December, with a senior official from Random House visiting me twice to discuss the game and my plans for further enhancements and modifications to it. In January, 1985, we signed a contract calling for a March 1 delivery of the game. It was foolish of me to promise so early a delivery on a game that I had originally scheduled for a May 1 delivery, but I was desperate. I resolved to work long hours and make the deadline. And indeed, my progress during January and February was phenomenal. I put in the title page with its unique dissolving images and a variety of additional features: two-player games, ability to play either as the USA or the USSR, four levels of play, and the ability to save and load the game. I greatly refined the operation of the crisis and put in the first artificial intelligence routines to operate the other countries. I worked killing hours trying to meet that deadline, but by mid-February it was obvious to me that I would not make deadline. I so informed Random House, and they were gracious; their only concern was the quality of the product.

During March, I labored with the artificial intelligence routines. I also added the Background and Closeup features, and nailed down the final set of eight verbs that appears in the published version of the game.

At this time, Random House assigned an editor to the project to take over the final details of the game. This editor studied the game and prepared a list of criticisms and suggestions for the game. For the next few weeks I struggled to implement those features suggested by the new editor as well as those I knew needed inclusion. However, it soon became obvious that we had serious disagreements over the project. I was under the impression that the game was under the final stages before release, and the editor seemed to think that it needed major modifications. Despite our deep differences, we were able to hammer out an agreement specifying a series of changes that I would make to the game. I spent three weeks implementing most of these changes. The two most important of these changes were the History feature and the advisors’ commentary during a crisis. I was very pleased with the result, and thought that I was in a strong position. After all, the game was much better than I had promised it would be, I had worked far longer than I had promised, I had responded positively to almost all of Random Houses demands, and I knew that the game was just plain great. I therefore presented the result to Random House with an ultimatum: Accept this version as the alpha-test version of the game, or drop the contract. Random House opted to drop the contract. Oops!

Mettle-testing
It was now early May, 1985. I was without a contract and in debt to Random House for the money that had already been advanced. Facing bankruptcy, I started looking for what my wife called a “real job”. I was hoping that somehow, some publisher would change his mind and publish the game, but it looked hopeless at this stage. There was no money left to allow me to finish it. I would work on it until I got a job, and then abandon it. Until then, my highest priority had to be finding a job.

My agent raced to sell the game to any publisher who would cover my debt to Random House. But nobody wanted this game. They all admired it, said that it was beautiful, but not worth what we had to ask for in advance money. The rejection notices piled up; it seemed a sad ending to such a noble effort.

The tremendous strain of this period began to take its toll. After a years’ effort and so many rejections, I was just about at the end of my tether.

I continued to polish the game. The greatest change during this period was the final lobotomization of the minor countries. My initial design of Arms Race was completely nonpolar. There was no fundamental difference in the program between the USA and any other country. Every country had the same policy options available to it that were available to the superpowers. But this egalitarian view of the world was slowly transformed during the development process. First came the crisis, which allowed the superpowers (but no other country) to start a crisis and carry it through to a nuclear war. Later, I made some further changes to cut down on the amount of activity that non-superpowers could undertake. By May, there was only one policy option left to the non-superpowers: the right to declare war on another non-superpower.

I had been spreading the game among playtesters and was getting unanimous feedback that the game was too difficult to understand. The major complaint seemed to be that there was too much activity to occupy the attentions of the player. The uncontrollable activities of the non-superpowers seemed to be a big part of the problem. Players felt helpless in a world in which so many things took place outside their control. The game should have felt like high noon on main street of a dusty Western town, with the player squaring off for the final showdown with Gorbachev; instead, the game played like Saturday night at the saloon, with everybody behind tables, shooting it out, and the player standing in the middle shouting, “Whats going on?”

I took much pride in the multipolarity of the game; it is, after all, a very realistic representation of the world. However, one ignores ones playtesters at one’s own peril. so with great reluctance I finally lobotomized the minor countries, reducing them to passive powers to be manipulated by the superpowers. The accessibility of the game took a giant leap.

Another playtester unwittingly contributed one of the nicest touches in the game: the black endgame screen that announces, “You have ignited a thermonuclear war. And no, there is no animated display of a mushroom cloud with parts of bodies flying through the air. We do not reward failure”. The text for this display was my own creation. I had cooked it up sometime in February of 1985 in a disgusted reaction to the question of a friend who wanted to know if I would be putting in some great graphics for the end of the world. However, my original rendition had placed the text in a nondescript Macintosh window that presented its message with all the panache of a bus driver announcing the bus’s arrival at the next stop. I happened to be on hand one day as a playtester explained the game to his friend. In describing the end of the game, he mistakenly claimed that the screen went black before the final message appeared. I started to correct him, then bit my tongue. What a great idea! Four hours later the playtester’s mistake was my newest feature.

One of the oddities of this world is the way in which seemingly insignificant events can lead to major changes. In March, 1985, I had been asked to speak to a local meeting of the Macintosh Special Interest Group of the Software Entrepreneurs Forum about game software. This is a very small group; perhaps thirty people attended the meeting at which I spoke. One of them, however, was Steve Jasik, who suggested to the speaker coordinator of the Berkeley Macintosh Users Group that I might make a good speaker for that group. I ended up showing my game and giving a speech to the group in early May, 1985. Attending that meeting was Tom Maremaa, a reporter for the computer magazine InfoWorld. Tom was impressed with Arms Race and later interviewed me and wrote an article that appeared in the June 10, 1985, issue of InfoWorld. The effect was electric. Software publishers called from all over the country to express interest in the game. One of the publishers who saw the article and approached my agent was Mindscape. After some telephone discussion, the principles for a contract were agreed to.

A few days later I flew out to Chicago to meet with the Mindscape people and discuss final changes in the game. That meeting was a model for the proper relationship between artist and publisher. It was chaired by Sandy Schneider, the most talented editorial worker I have ever encountered. We went over every detail of the game in six hours. The Mindscape people brought in a long list of suggested changes. Each item was read off and discussed by all concerned. There was no idle brainstorming, no random ruminations; Sandy kept the meeting moving. The arguments in favor of, or opposed to, a point were presented concisely and forcefully. A few minutes of discussion sufficed to generate a consensus. Notes were taken and we moved on to the next suggestion.

During July, I made the changes agreed to at the meeting. Most of the changes were minor matters of polishing. For example, I reduced the probability of accidental nuclear war. Other changes made the user interface smoother and simpler. On August 1, 1985, I turned over semi-final code to Mindscape for testing. After seven weeks of testing, about a dozen bugs had been found and corrected. The best bug report was the observation that the capital of Tanzania is spelled Dar es Salaam, not Dar Es Salaam. These testers were thorough. I turned in the final version of the game in late September and Balance of Power was finished. The first production copies were shipped in mid-October.

Afterthoughts
The development of Balance of Power reminds me of the use of paratroops in World War II. After much trial and error, the strategists eventually learned that the real value of paratroops lay in their power to motivate regular troops to fight to rescue the paratroops. It’s difficult to inspire soldiers to risk their lives to win a patch of ground, but when they know their comrades are just ahead, surrounded by the enemy, counting on the regular troops to save them, the regular troops will fight with unparalleled determination. Paratroops, then, allow the commander to set a clear and tough goal for his troops to reach. Using paratroops is like putting yourself in a deep hole to see if you can dig yourself out of it.

I did much the same thing with Balance of Power, setting a goal for myself that I had no reason to believe I could attain. Then I publicly and financially committed myself to attaining that goal. Nobody believed that I could do it, certainly not any publishers. The thought that I could design a game on geopolitics that would be interesting, challenging, understandable, and fun was just not credible to them. Having dug this deep hole for myself, I then started digging myself out. Several times the walls caved in on me, leaving just one free hand groping madly for air. It was a tough, frightening experience. When it was over I was physically and spiritually spent. But what is the point of undertaking anything less than the most demanding of efforts?