game design memoir by Danielle “Dani” Bunten

The following is my obviously biased view of my career in the computer games business presented around the games I designed and built over a period of 14 years. Besides offering what I hope are some interesting bits of history I hope it can help any would-be designers with insights and tips. As we say it in this business – if the shoe fits, steal it.

“Wheeler Dealers” published in ’78 by Speakeasy Software in Canada was my first game. It was also the first game to come out in a box when all others were published with the cassette (16K) and mimeographed rules in a zip-lock bag. Also included in the box was a custom input device that consisted of 4 push-buttons connected to the Apple II’s gameport. This allowed the 4 players to compete in real-time auctions for stock in companies which the players managed via those same buttons. It was a great challenge to work out how to input data with nothing but a push button but it taught me that interface is less important than play value and that auctions are a compelling way to interact. While attempting to write the manual for “Wheelers” I ended up writing a word processor that came within a hair’s breadth of being chosen as “Apple Writer”. Instead it was published as “Scribe” and sold a handful compared to the hundreds of thousands for “Apple Writer”. (Being rich was never my goal but it would have been nice<grin>).

“Computer Quarterback” was published in ’79 by Strategic Software. It was based on a game I had written in FORTRAN on a Varian minicomputer when I worked for the National Science Foundation. It was the most thoroughly mathematically modeled game I ever did. I collected and analyzed tons of data to come up with statistical distributions to represent the expected outcomes for 36 offensive plays against 21 defenses. I was at the time planning to use the project as my master’s thesis in systems simulation but then I got involved in the games biz and dropped out of graduate school. “Quarterback” was one of SSI best sellers for several months after it came out despite the fact that the solo play option was pretty lame. (It was really designed to be played by two humans).

“Cartels and Cutthroats” was a business strategy game published in ’81 by SSI. It was built to provide an easy input for cyclic business management. Only 6 decisions were required by players (up to 6 of them as well) to allow them to compete. The would set their price, advertising, R&D (which created opportunities to automate), build more production, etc. I used humor to increase it’s appeal and naïve as I was then, I was amazed when it didn’t sell as well as “Quarterback”. In retrospect, it didn’t do all that bad considering that all subsequent attempts by others to do business games (with far larger development and marketing budgets) didn’t do much better. Evidently folks interested in playing with the stock market or business, do it in real-life instead.

“Cytron Masters” was my first attempt at combining strategy and action elements in a single game. It was also my first fully graphical game (all previous ones were text based), my first machine language game (basic was sufficient before then) and the first game for the Atari 800 (Apple II was my platform before). “Cytrons” was published by SSI in ’82. It was a very simple abstract wargame. I learned a lot about programming multi-thread software (all when it was necessary to write all your own interrupt handlers). I also discovered both how compelling real-time strategy gaming could be and how easy it was to loose your market. Rather than appealing to both action gamers and strategy gamers it seemed to fall in the crack between them.

“M.U.L.E.” was part of the group of games that launched Electronic Arts in ’83. It won numerous awards (including Computer Gaming World’s Hall of Fame) and sold reasonably well (despite being the “most pirated game” at the time according to the publisher of CGW). Curiously, it happened as a result of the fact that Trip Hawkins (the founder of EA) couldn’t get SSI to sell him “Cartels and Cutthroats”. I convinced him we (at that point I had formed Ozark Softscape and had 5 employees) could do it better. I took the auction from “Wheelers”, the graphic real-time aspects from “Cytrons”, some of the production ideas from “Cartels” and let it evolve where it needed to. This was the game that taught me the value of play-testing where you watch and talk to real people about the game while it’s under development. After all, games are a form of communication that can only be confirmed by checking whether it works against an audience.
     A couple of design pieces really pleased me about this game. I think the auction with the sellers on top and the buyers on the bottom of the screen and a timer was particularly cool. Sellers would walk down the screen thereby lowering the price they were offering to sell at and buyers would walk up the screen raising their bid. When the two met, units of commodity would zip from the seller to the buyer. This led to a lot of dickering and cajoling by the players trying to get each other to move closer using all types of justifications to support their inability to move themselves. When the timer started running down, this could lead to a lot of frantic maneuvering.
     Another neat thing was the invention of the MULE itself. In order to make the auctions interesting, there had to be commodities that players needed and also made (so some became sellers and others buyers). From a strategic game model what was needed was some way for players to say “I want to produce commodity ‘A’ on plot ‘X'” but text entry or even menu selection seemed uninteresting. What if your picked up a machine somewhere and dragged it to your property to produce what you wanted. This “machine” eventually became a “Multiple Use Labor Element” that you got from the coral in the town, dragged into an outfitter shop of the right kind for the commodity you wanted and took out to your land and deposited there. Voila we had the info the model needed and with the addition of a timer, we had an interesting play element.
     My only disappointment with the game is that it only exists on long defunct hardware and it looks awful (since those machines only offered 48K of memory and I used it mostly for program rather than graphics). I almost got a Sega Genesis version through EA in ’93 but at the Alpha phase they insisted on adding guns and bombs (or something similar) to “bring it up to date”. I was unable to comply. I’m still amazed at how well loved it is (there are a number of web sites devoted to it) and I’m hopeful I can find a way to bring it to life again – possibly on the internet.

“Seven Cities of Gold” was my best selling game. It garnered a SPA Gold Disk and a number of minor awards. It was also my first game that didn’t allow for more than one player. It was planned to be multi-player but during during development it lost that aspect, along with colonists and development. To keep it’s focus (and allow for a really large world) it ended up just covering the early exploration and conquest of the new world. It was published in ’84 by Electronic Arts and it was the game Trip Hawkins (founder of EA) coined the term “edu-tainment” to describe on the press tour introducing it. (Back then the term wasn’t the kiss of death it is now).
     There are several things I’m proud of about that game. Unlike most strategy-adventure games then (and now as well) which load the player with numerous economic and logistical decisions, it only used four commodities to model the constraints and opportunities facing the Conquistadors (men, food, [trade] goods and gold). I also like the way I was able to reflect the unique interactions between natives and Conquistadors when they shared neither a language nor cultural values in common. I came up with a simple arcade element which also included a number of subtle “secret” opportunities that I was quite gratified to learn that folks found on their own. Finally, the fact that our “New World” was randomly generated (and so large it required disk caching and overlays) made exploring a challenge fraught with peril and surprises. It sufficiently captured the sense of panic that comes from being lost in the wilderness and running out of supplies as well as the joy of rescue (which was something I experienced once backpacking and wanted to make a touchstone of this design).
     Our biggest frustration with this product was that it was developed in the days when you had to write a number of different versions since no platform was pre-eminent. There were Atari 800, C64, Apple, Mac and IBM PC versions of the game put out but the only “full” version was on the Atari. On the others we did the best we could with what we had.

“Heart of Africa” was the only true sequel I ever did and it was done to please EA (and get the $5K bonus they offered). It ended up as a C64 game only but on that platform it sold almost as well as “7Cities”. It was published in ’85 by EA and it was my last solo only game. I was never a fan of the adventure game genre which always seemed too much like guessing games where the player’s job was to read the mind of the designer. However, this was my only published attempt at that genre. (A detective game that I also worked on got canceled at the prototype phase).
      I like a couple of things I invented for this product in particular. The player had a journal into which the game automatically entered events such as “Giant Python attacked and I lost my compass but got away with only minor scratches. These took the place of difficult to render graphic events and were almost as satisfying to the player. I also like the idea of messing with the player’s interface to reflect ways in which their character was being effected. Two of the best were if you stayed in the desert too long you began to go sun blind which resulted in increasingly more pixels of the screen taking on the yellow terrain background color (and hence obscuring any features there) until the whole screen was yellow. Your only hope at that point was to stumble into a village or town where the natives would cure you. The other was that if you went too long without water you would become delirious and we would “mess with” your joystick inputs such that they would wander away from the direction you were pushing. However, if you held to a consistent direction long enough (and resisted your instinct to compensate for the wander) you would make better progress. It was really fun to watch play-testers as they stumbled into these effects and not only figured out what they meant but how to deal with them by bringing some vague “real-world” intuition into the game. One other thing I thought was a cool feature from this game was the way I “saved” beginners from their frustration of not making any progress. The essence of the game was exploring Africa to find locations that weren’t visible per se but using clues and landmarks could be found. If I noticed that a player was struggling too long trying to find one, I would “move” it to where they were. This only happened the first game played and only early in the quest because adventures after all are about meeting a challenge but I thought it was an elegant solution to keep people feeling like they were doing OK which is really important in the early stages of play.
      What this game suffered most from was that the attempt to make a replayable adventure game made for a shallow product (which seems true in every other case designers have tried it as well). I guess that if elements are such that they can be randomly shifted then they are substantive enough to make for a compelling game. So, even though I don’t like linear games, they seem necessary to have the depth a good story needs.

“Robot Rascals” was my most experimental game and as far as I know is still the only computer game published by a major publisher that had no solo-play option. Admittedly, the solo opponent built into my games was never very good but Electronic Arts in ’86 was a lot more willing to take risks than they were since. What I tried to do with “Rascals” was find the minimum set of elements that would still make a multi-player game that was fun. It had some similarities to “M.U.L.E.” but I tried to get rid of anything that made “M.U.L.E.” initially a bit daunting and hard to learn. In “Rascals” there were no prices, no money, no commodities. What it became during development was a scavenger hunt for items buried in the playing area. Your avatar (a robot that your frat house or sorority entered into the contest) could “scan” for items like the “binary boot”, the “digital donut”, etc. It was terminally “cute”. It used subtle but simple elements that players could learn easily and master as time went on. For instance, when asked to scan for an item, the robot spun around twice pointing until it pointed in one of the 4 main directions. It turns out the faster the robot turned was a cue as to how far the item was which the player could use to decide if it was better to go to a teleport station or to walk that direction immediately.
      I’ve always enjoyed inventing these type of subtle visual and audio cues for players and have been impressed repeatedly at how satisfying it is to players to “learn” them and leverage them in their performance in the game. Not to beat this idea to death but in that same visual effect (the spinning and pointing), the fact that the robot pointed only in the four ordinal directions also offered the player another opportunity to exercise their “insight”. A player as they gained experience would walk their robot in the direction pointed for a while and then scan again. If this resulted in point in a direction perpendicular to the original direction then the player knew the item they were looking for was diagonal from them and they could cut their search time significantly. Now, from a design point of view this wasn’t a major breakthrough but I was amazed at how this little “skill” gave play-testers from grade-school age on up to adult a certain satisfaction when they mastered it. It told me that a good game is as much about making the “process” of play interesting as making the “goal” of winning meaningful.
     There were a couple of other quirky attempts at making this game accessible. It included two decks of cards. One deck was of the items that were stored in the playfield. This was the way players found out what items they needed to find in order to win the game and it allowed players to keep their list secret from each other. (Hidden information is difficult to accomplish when all players are sharing the same computer without the silly device of hiding their eyes at certain times). The other cards were “luck cards” that had things like “Steal a card from any player” which let you pick a card from them and return one you didn’t want. There was also a “Pass the trash to the right” which allowed all players to mess with each other’s list of items to get to win. Taken together these items made a very simple game become intriguing. I think it was a successful experiment although the sales that EA was able to generate (despite a worthy marketing effort) were disappointing. It didn’t have a solo-play option was everyone’s rationale for the “failure”. I can’t argue with that but I also think the fact that it didn’t have an identifiable “genre” or audience certainly didn’t help. I thought of it as a “Family Game” but that’s evidently not a demographic that turns up at retail outlets.

“Modem Wars” was one of my favorite games to develop and to play (second only to “M.U.L.E.”). It was the last of my designs published by EA. (Ironically, I quit them because Trip wouldn’t let me do M.U.L.E. for the Nintendo because he said EA wasn’t going to do cartridge games. This is the company that now makes more than half their revenue from cartridges!) “Modem Wars” came out ’88 and was the last C64 title I did and the first PC one (platforms were shifting again). “War” as we wanted it called (or “Sport of War” was our working title) was inspired by playing soldiers in the dirt with my brothers when I was a kid. It didn’t have any of the complicated rules and relationships wargames at the time had and it ran in real-time without turns or pauses. It was just “click” on a unit (or group) to select it and click on it’s destination. The unit would shoot at any enemy it encountered but that was about it. I had the simple infantry, artillery and cavalry mix from the Napoleonic era as well as hills where your guys saw further and forests where they didn’t. It was the first of my online games (if 2 players being connected via modems qualifies) and it was the first time a major publisher published such a product.
      What I though was neat was that players’ each had full time active use of their own machines (all my previous multi-player games included either turns or multiple inputs and shared output on one screen). This kind of play was a real kick for us the first time we tried and as it has turned out now it’s a kick for a lot more folks now that modems and ways to connect are much common. In fact that was “Modem Wars” biggest problem — the lack of modems in ’88. By the time they started showing up en masse in the ’90s, “Modem Wars” was out of the EA catalog and out of date. (It was written when EGA was the new thing and a mouse was very rare on a PC).
      There were several neat things about the game that I carried forward. The interface while exceedingly simple – click to select, click to set destination – also had more advanced options. If you double clicked, you could get a menu that let you do more sophisticated things like create your own groups, tell them to dig-in, etc. In addition, I like the way there were various features that allowed different players to use their own skills to compete. Not since “M.U.L.E.” was I able to build that kind of aspect into a game. In “Modem Wars” there was the battle planning and strategy involved in managing your armies. But there was also eye-hand coordination in the drones (slow flying “buzz bombs”) that players could fly and the missiles (fast rockets) that shot them down. In addition there was a radar-like display that players could pick out hidden units if they were good at pattern and change recognition. And with the spy type unit there was subterfuge and counter-espionage. What all this meant was that various aspects of a player and their unique combination of skills meant that each person had their own specialized style of play. Another thing that I thought was cool came as a consequence of the fact that “Modem Wars” was written to work with 300 baud C64 modems and hence very little data could be sent between the players. Each machine had to run independently and the only info sent between them was what is called the “deltas”. Since the robots all behaved under very strict rules, the deltas in this design were limited to the commands from the players. Nothing about the screen or interface of the other player was shared. If a player for instance gave a unit a destination, nothing about the process of clicking and positioning the cursor was sent, just the result. This took only four bytes – one each for: the move command, the unit ID#, the destination X and the destination Y. This meant that the time thinking about what to do and the time giving the unit it’s new command could be reduced to 4 bytes. This meant that the entire game could be stored in only 4K! And since the game engine had to run on it’s own with only those “deltas” at the right times, you could turn the process into a way to “replay” the game by just running the game out of the stored data rather than the inputs from the players. This “Game Film”, as we called it, turned out to be a really popular feature. It allowed players to look at what happened from any perspective (theirs, their enemy’s or omniscient) and to slow it down or even pause it. Frequently this was the first chance players had to see much of what was going on during the battle since they were only aware of their own robots and the few enemy ones within range. I was amazed how people used this opportunity the game films offered to rationalize their loss and to create stories out the intense and ephemeral experience of the battle. These two things are both things that players need to make their play more meaningful and I hadn’t realized it till the pitiful C64 modem forced me to learn them. Now, when I give talks about designing multi-player games at conference I tell them that if we want to make multi-player games that people can really enjoy, we have give them a way to save face as well as ways to make legends out of their best performances. (I ended up including this feature in both “Command HQ” and “Global Conquest”).
     The most frustrating thing about this game was trying to get the intensity factor just right. In the days before “Doom”, people weren’t accustomed to adrenaline rushes that lasted several minutes. That reminds me of another neat thing about the game – it had a time limit after which a winner was declared (30 minutes was the longest game). This seemed (and still seems) like a good idea. Anyway, back to the intensity issue. I was convinced by several of the reactions from reviewers and play-testers that part of “Modem Wars” problem (you always thinks a game has “problems” when it doesn’t sell as well as expected) was that it was too intense. The next two games where attempts to slow things down to get more market. That seems foolish now but such is life.
      I’m currently working as a consultant for a company who is implementing a new 8 player version of this design for the internet through Mplayer and I’m hoping it’ll be out in late ’97. In the meantime you’re welcome to the old version if you promise not to be too hard on it (it’s almost a decade behind the state of the art) because despite it’s surface it has a good heart.

“Command HQ” was the first game I designed for Microprose and it was published in 1990 and it was my second best seller and won the “Wargame of the Year” award from “Computer Gaming World”. I enjoyed working with Microprose and especially was glad for the opportunity of interacting regularly with one of my favorite game designers in the business – Sid Meir. His games “Pirates” and “Civilization” were both designs I had on the back burner but never got around to. I have total admiration for what he did with those products but if I had done them, they would have both been multi-player games from the start and likely had a whole different feel. (I hope that doesn’t sound like sour grapes. Maybe my admiration is twinged with a bit of envy too. <grin>).
     “Command HQ” was a fairly straight-forward design job of taking aspects of “Modem War’s” (namely the modem connection and real-time play) and adding a highly abstracted World War II wargame model to it. I have to admit to being influenced by the board game “Axis and Allies” which I thought was a very sophisticated piece of design work. Nonetheless, I’m proud of “Command HQ” for a number of reasons.
     This was one of the few games where I fully followed the KISS maxim (“Keep it Simple Stupid”). The world was the Mercator projection of the globe with only polar, plain, mountain, forest, jungle and water terrains (each of which had very obvious and intuitive effects on the units). The units consisted of infantry, tanks, subs, cruisers, carriers and airplanes and how the behaved has nicely stereotyped but also subtle. For instance subs that weren’t moving weren’t visible to the enemy until they shot them which meant that a sub could take out any lone ship most of the time. Several areas of possible complication were avoided in the design. For instance planes could act as transports, paradrop carriers, bombers or fighters depending on what target was selected. Land units that moved to sea became transport ships and to simulate the difficulty of moving them ashore or off without a port, a large time delay was imposed unless they moved through a city before taking to (or returning from) the water. These sort of modest but elegant design elements kept the game very easy to play. The resources involved in the game were limited to money which came from the number of cities you owned and oil which came from the number of oil fields you owned. Despite the simplicity of these features the game was a fairly accurate simulator of WW I, WW II and WW III (the one that never happened but Tom Clancy fantasized in Red Storm Rising but I included nuclear weapons). I threw in two more world wars which varied the capitols as well as the starting conditions.
       Besides the structural elements that kept this game simple it had an extremely clean interface (in my humble opinion). It was the first “PC only” game I did and the first with a mouse interface (which makes strategic gaming much simpler than a joystick). It featured the “click to select” and “click to set destination” of “Modem Wars” but since oceans could intervene between the origin and destination, it required a slick bit of coding to allow ships to navigate the oceans in reasonable patterns. Also, unlike “Modem Wars” there were no additional layers of complexity (eg no “groups” since unit counts were kept low, and no extra menus). In addition, I solved the problem of scale which hounds all “large world” games with a simple mechanic. The basic view of the game showed the whole world at 320×200 (these were the days of EGA and the Tandy graphics system) with units as 3×3 pixel squares. This was great for an overview but you couldn’t tell anything other than whose unit it was. If you clicked the right button an enlarged view exploded at your cursor so you could actually manage your forces. Click again and it went away. This allowed players to easily manage wars that took place all over the globe. The final piece of interface that I liked was the small status window that showed you the detail of the terrain and any unit under your cursor as you just rolled it around.
      One of the weak points of “Command HQ” was that it included no animation. The units were iconic squares that looked like “counters” from old paper wargames. Their only animation was to change position (as a result of moves) and to flash their backgrounds (as a result of being attacked). Microprose artists contributed some short animations that took place in a small window to show significant events which was a nice touch. This game did well enough that there was an upgrade (done by a group of fans with my permission). There was even a plan by Microprose to do a Win95 version but when they were bought out by Mindscape it was canceled.

“Global Conquest” was published by Microprose in ’92. It was the first four player network game by a major publisher. Although this game was a lot of fun to play, especially with 4 players, I think of it as my worst game. The design started out as one further attempt to “slow down” the real-time aspect of “Modem Wars” and “Command HQ”. It was also supposed to include aspects of all my favorite designs. It would have the exploration of a random world of “Seven Cities of Gold”, it would have the clean interface and simple wargame model of “Command HQ”, it would have the random events and humor of “M.U.L.E.”, it would have several of neat features of “Modem Wars” (including the Spy and Comcen) and it would have better graphics (640×400) drawn by contract artists. As it turned out, this game was a hodgepodge rather than an integration. It was just the opposite of the KISS doctrine. It was kitchen sink design. It had everything. It was more “construction set” than game. Build your own game by struggling through several options menus. It was also a case where my play-testers got the better of me.

Leave a Reply

Your email address will not be published. Required fields are marked *