I've collected strategy guides since I was a kid. In fact, my collection got me into trouble more than once. I'd slip a guide between the folders of my Trapper Keeper and smuggle them into class, where I'd absorb pro tips and expert strats behind a wall of textbooks. Yes, I was that weirdo who read strategy guides like novels. I admired the artistry that went into their layouts and text, and was agog at the info organized so colorfully on their glossy pages.
That's what made talking with David Ellis, strategy guide author for many games, Sid Meier's Civilization II and UFO: Enemy Unknown among them, such a pleasure. He also authored the Civilopedia, Civ II's massive in-game encyclopedia—and a game construct that made a huge impact on the development of X-COM.
[Author's Note: Monsters in the Dark: The Making of X-COM: UFO Defense tells the story of the early years of legendary strategy game designer Julian Gollop and the making of the original X-COM, and is funding now on Kickstarter. This excerpt comes from the book's special edition, available exclusively on Kickstarter.]
David L. Craddock: What led to your interest in computer games?
David Ellis: I played my first coin-op video game when I was nine, Atari's Breakout, at a bowling alley where I bowled in a league. That would have been about 1974. I was instantly fascinated by video games, and I eventually got myself an Atari 2600 by saving up paper route money. I was hooked from that point on.
Craddock: Did you always want to be a designer, or were you happy working in any position in the industry?
Ellis: When the video game craze took hold in the late '70s and early '80s, I saw a 60 Minutes segment about Atari. One of the things they talked about was testing video games. I was a full-on video game junkie at that point, and I told my parents that the job that I wanted was testing video games. Not particularly realistic at the time.
I actually eventually wanted a career in film or television production. I really never thought seriously about a career in games until I was actually working at MicroProse.
Craddock: How did you come to work at MicroProse?
Ellis: While I was in college, I had a job selling computers at a small retail store. I got to play a lot of games on a bunch of different computers—we sold Commodore, Atari, and IBM compatible machines and software. After I left retail, I got a job working for the government in DC as a "telecommunications specialist," which amounted to a glorified telephone operator that also sent occasional telexes. Remember those? The money was better than retail, but I hated the commute and the job was boring. I started browsing the help-wanted ads in the paper every Monday morning.
One day, I saw an ad for a customer service rep at MicroProse. I loved MicroProse games and knew a lot about them, and I had a lot of practical experience in computer customer service, so I applied. I figured it was something I could do that was closer to home and more fun until I figured out what I wanted to do long term. That job turned into a career.
Craddock: What was the culture and atmosphere like at MicroProse?
Ellis: Second to none. If you ask pretty much anyone who worked at MicroProse, they'll tell you it was the best job they ever had. I've never worked in a more creative and fun environment. We worked hard, and we sometimes worked long hours—but, mostly, we did it because we absolutely loved what we did and we were proud to be a part of creating great games. We did things together as a studio all the time—from paintball to RC monster truck rallies to putting together an impromptu band to play at the company Christmas party.
We also got to do a lot of cool things that were directly related to work—like visit and tour the Oceana Naval Air Station while working on Fleet Defender Gold.
Like I said, we worked hard—but we had fun doing it. That's an important part of game development that is often lost in today's crunch time all the time game development studios.
Craddock: Your first job was in customer service, I believe. What did the job entail?
Ellis: Answering phones and mail (actual mail—we didn't have e-mail at that point, although we had a BBS which was run separately from customer service). People would call or write in with problems and we'd either talk them through the problem or send them a patch disk to fix known problems. There were three to four of us in customer service. We were always pretty busy.
Craddock: Can you share any anecdotes from your customer service days? Any flavor: bizarre, humorous, frustrating, etc.
Ellis: Windows was the bane of our existence. It was pretty new then—all of MicroProse's games were DOS games until around 1995, if I remember correctly, but machines were shipping with Windows 3.1 pre-installed. The problem was that DOS games required a certain amount of base memory to be free—up to 600K (out of 640K—that's a lot if you don't remember how it was back then), and the games would not run if Windows was running. Half of the problems we had with people not being able to run a game were solved by having them boot into DOS rather than booting into Windows.
Compatibility was also an issue. There were so many IBM-compatible computers out there, that it was difficult to know which combinations of hardware would and wouldn't work with our games. There were also Tandy computers, which were NOT particularly IBM compatible. It was a really confusing time for consumers, and their frustration was understandable.
My best customer service story, though, was the one that prompted me to get a job in QA. I was the only one on the phones one day, and I got a call from an African-American gentleman who was very upset about F-117A [Nighthawk]—specifically, he said that the game was racist. I calmly asked how a flight sim could be racist, and he said that there were only two times that you saw an African-American pilot in the game. When you failed a mission, an African-American pilot was seen writing "I will not crash my F-117" on a chalkboard.
When you won, there was a celebration picture where the African-American pilot was in the background celebrating a white pilot's victory. I was calm and collected and tried to be as sympathetic as I could. The call went on for 45 minutes and, when the rest of the department got back—they were at a company meeting and I drew the short straw on manning the phones alone while they were gone—I had to take about half an hour away from the phones to regain my sanity. That night, I talked to the QA manager about moving from customer service to QA.
Craddock: Everyone I've spoken to who worked in the industry in the '80s and '90s spoke of wearing many hats. Was this the case for you during your time in customer service?
Ellis: Not at all. I started in 1992, and MicroProse was really big by then—about 120 people in Hunt Valley, and offices in Japan and the UK. MicroProse was everything under one roof—development, marketing, sales, QA, customer service, even the warehouse was on-site. The only people who wore multiple hats, really, were the developers who had been there for a long time—like Sid Meier, Scott Spanburg, and Andy Hollis—who were both programmers and designers. Most everyone stuck to their own thing.
Craddock: How did you move to QA?
Ellis: Darklands. It was MicroProse's first (and only) RPG, and it was huge. I started working extra hours part time in QA after work to help test the game. That's how I heard there were going to be some full-time openings in QA. I had already proven I could test by the time I asked for a full-time position, so I could make the move pretty smoothly.
Craddock: How do you remember the QA work environment at MicroProse?
Ellis: QA was, mostly, a lot of fun. We were all crammed together at tables in what was actually supposed to be a hallway. Well, it was a hallway and it was used as such. We just happened to work there. Eventually, we expanded to take over the back half of the employee break room; there was a dividing wall that could be closed. It was close quarters, and that meant there was lots of camaraderie. It also meant that, if one person got sick, everybody got sick. Most of the department was down with mono one time. We shared a phone. It was a regular germ-fest.
As for hours, it varied from project to project. As I said, Darklands was a huge game, so a lot of overtime was worked on that game. It was still being tested a year after I started in QA! On some games, there was always a push from some management, especially marketing, for us to stay late testing—even if there wasn't a new build available for testing.
When I got to be a lead tester, I always resisted this tendency—I wouldn't let my team work what I liked to call "political overtime": Working late just for appearances. But sometimes you didn't have a choice. One of our testers—now the sound designer at Vicious Cycle Software, where I currently work—likes to brag that he once worked a 25-hour day in QA—it was the day the clocks changed in the fall.
The awesome thing about QA at MicroProse was that, for the most part, the development teams worked closely with us and respected our opinions and ideas as well as our bug reports. We got to learn a lot about the development process in MicroProse QA. Many of the QA guys I worked with became designers.
Craddock: What was the first game you tested?
Ellis: Darklands version 3.0, the original release. My first big game as a lead tester, almost a year later, was also Darklands version 7.0, the final release.
Craddock: What are some of differences testing games from different genres?
Ellis: There's a big difference. Understand, there were no automated testing systems back then. Everything was actually playing parts of a game over and over and over and over to find bugs.
The easiest games to test were the animated graphic adventures. I worked on all three—Rex Nebular, Return of the Phantom, and Dragonsphere. They were long games in terms of gameplay time, but they had the advantage of being divided up into discrete rooms, and there were a finite number of actions you could perform. So, a systematic test of the game systems could be done by making a checklist of all the rooms and all the actions, and then having testers go room to room pushing, pulling, talking to, etc. every object with which the player could interact. That made it easy to test the functionality of the game. (The flow and the connective elements of the game still had to be tested, of course, but the controls and functionality were straightforward.)
Sims were a lot harder to deal with. I only tested one or two sims, but those typically saw the team split up into those who were testing the simulated vehicle's performance while others tested mission flow, individual missions, and scenarios. Testing a scenario in a sim could be among the most tedious types of testing. You played the same scenario again and again, trying to come up with different ways to stress test (aka: break) it. After about 20 hours on the same scenario, you could come up with really creative things to do just out of sheer boredom.
Strategy games were the most difficult to test. Games like Civ generally had their systems tested and perfected during development, both by the developers themselves and QA testers, so when the game got to QA, most of the testing was about making sure the systems all worked together properly.
When Civ II was being developed, Bryan Reynolds sent builds every few days to several people who were good at Civ to get feedback on new units, new systems, and so on. By the time the game got to QA, a lot of the balance was already done—that makes it easier to deal with in terms of testing.
Craddock: How would you define the goal of QA? Is it more about tracking bugs, or is play balance an equally or more important issue?
Ellis: When I was in QA, the two were equally important. Since we were under the same roof as the developers, we could talk directly to the programmers and designers. Most of the designers and programmers took QA's balance and gameplay suggestions very seriously. We were all invested in making the game as good as it could be.
Today, it's a lot different. We typically use either publisher QA departments or external groups, and they stick pretty much entirely to bug tracking for the most part.
Craddock: Was there much structure in the QA department in those days? For example, did you have bug lists and a procedure for how to root out bugs? Or was it more about putting a to-do list together and going through each item?
Ellis: There weren't really specific test plans in those days, but each game had a lead tester who coordinated the testing, laid out tasks for everyone each day, and controlled the bug list. Bugs were hand-written back then. There was a master bug list program, but the lead tester was the one who entered all the bugs into it and printed out the bug list every day. Times have changed.
Craddock: According to Mobygames.com, you wrote the "Windows help file" for Civ 1. How did you get that opportunity?
Ellis: One of the ways that I moved from QA to design was by grabbing every opportunity that came along. When we converted Civ to Windows 95, I suggested that, like other Windows programs, we should have a Windows help file for the game. Nobody had time to write it, so I volunteered.
I was the lead tester on Civ Mac, and assistant lead on Civ Windows. I was still pretty new to being a lead tester at that point, and these were smaller projects (simple conversions to Mac and Windows), so there were only a few testers on them. It was pretty typical for testers who were new to lead positions to be given smaller projects at first.
I loved Civ, and I still do. Civ II was my favorite of the series, and I really enjoyed Civ Revolutions.
Craddock: You wrote the Civilopedia for Civ II. What did that process entail? I can only imagine how long it must have taken to track down all the information players might need for a game that involved.
Ellis: That was a pretty big project. Research was a little harder in 1995 than it is now (no Wikipedia) so a lot of it was book research and coordinating with the design lead, Brian Reynolds, on the things that he was trying to convey with some [in-game] Advances. (I remember "Machine Tools" being a hard concept to write about.) Then, we had to track down and get rights to the images we used in the Civilopedia. "Multimedia" was a buzzword in the industry at that point, so the Civilopedia had to be a "multimedia Civilopedia." Hence, photos instead of art.
I also programmed the Civilopedia using Macromedia Authorware, the scripting tool we used to add multimedia content to Fleet Defender Gold, which I also worked on. The programmers on the project had to do some pretty nifty programming tricks to get the Authorware executable to run seamlessly with the game itself.
Craddock: On the one hand, many players love Civ because they can read volumes and volumes of fascinating history. On the other hand, some players just want to find the info they need and get back to playing. In writing the Civilopedia, what was your goal in terms of the style and presentation of information?
Ellis: I took an encyclopedic approach that I probably wouldn't take today. Back then, there were players who liked to read. Now, most of them can't be bothered. At any rate, the player could click past the Civilopedia without reading it. I suspect the most useful part of the Civilopedia was the interactive tech tree, which I thought was pretty neat. You could click through Advances and see where they'd take you. Each was hyper-linked to the Civilopedia entries for their associated Advance, Units, Buildings, and Wonders. I'm guessing that at least some of that was interesting/useful to the player. I hope so, anyway.
Craddock: What did you enjoy most about testing Civ II?
Ellis: Even though I was a designer by the time Civ II went into development, I got to be one of Brian Reynolds' test subjects when he was in early development on the game. I was one of the "Civ experts" who gave him feedback on the units, Advances, etc. that he was adding to the game.
Craddock: Jumping ahead a bit, how did you receive the opportunity to design Civ II: Multiplayer Gold Edition?
Ellis: By that time, I was a lead designer at the MicroProse studio in Chapel Hill, North Carolina. Chapel Hill had done CivNet, the multiplayer version of the original Civ, for which I wrote and programmed the interactive tutorial, so they got the nod to do multiplayer Civ II. As the designer at the studio—and as someone who was very familiar with Civ II—I got to be the designer. It was an awesome opportunity.
Craddock: Civ 1 and II were games that had been designed for single-player experiences. What sort of design changes were made to make Civ II fun and interesting as a multiplayer experience?
Ellis: The main thing that had to be changed was the early part of the game. Until you get your cities going and get some units out there, you do little in the first few centuries other than press the spacebar to go to the next turn. This is fine in single player, but in multiplayer, you have 7 people just pressing space and waiting for a pretty long while before things really get going. Then, it takes a long time (especially on a larger world) to expand far enough to meet another player.
My solution to this was coming up with the idea of the Double Production option. When you selected this, every terrain square produced twice as much of what it normally produced, effectively doubling the speed of everything in the game—research, unit production, building construction, and so on. This made the earlier portion of the game (and the entire game) go a lot faster. The only negative side effect was that players often ended up producing pollution before they had the means to deal with it. Even so, this was a minor consideration that was far outweighed by the benefits.
The one other thing I did was move the Civilopedia text to a non-multimedia version of the Civilopedia. The multimedia version was too clunky and slow for network games.
Craddock: How did you receive the opportunity to write the X-COM strategy guide?
Ellis: This was another one of those opportunities that I grabbed when it became available. At that point, there was actually a writer at MicroProse whose primary job was to write strategy guides. When the time came to write the X-COM: UFO Defense guide, he was swamped with other work. He knew I could write because of the Civ Windows help file and a couple of other smaller things I had written at that point, so he asked if I'd be interested.
Craddock: What was your familiarity with X-COM's development before starting on the guide?
Ellis: I was pretty familiar with the game by then. The UFO Defense strategy guide actually wasn't even started until the game was finished, and it wasn't released until six months after the game came out, so the game had already been through QA at that point.
Interesting side story: X-COM UFO Defense almost didn't get released in the US. Games developed in the UK were almost always run through Hunt Valley QA before they were given the nod for US release. This was a basic gameplay evaluation rather than a complete test—basically, "Is this game something the US audience will like?" The reaction by QA management at the time was skeptical—they thought the graphics were primitive (I distinctly remember someone saying, "Not nearly as good as Darklands"), and that the gameplay didn't look like it would be fun. The testers who evaluated it, however, were wildly enthusiastic about it. As a result, the game was green-lit for US release.
Craddock: I didn't realize that developers and designers sometimes wrote strategy guides on the games their companies developed/published. What was the relationship between MicroProse and Prima for the strategy guide?
Ellis: I don't know if it was the same with all companies, but Prima and MicroProse had a pretty much exclusive deal. I don't know exactly when it changed but, by the time I wrote the Civ II strategy guide, I was dealing with Prima directly. While I worked at MicroProse, however, I was still contractually only able to do guides for MicroProse games.
Craddock: Can you give us a broad overview of what putting together a strategy guide for a game as complex and intricate as X-COM entails?
Ellis: Looking back at it now, the UFO Defense strategy guide is half manual, half strategy guide. I remember taking the approach of teaching the basics of the game and expanding on the manual because I thought the manual wasn't nearly clear enough to teach the game properly. For the actual strategy portion, I heavily relied on talking to the Gollops, who made themselves available to me for any questions, and getting raw game data from them. I also talked to the US testers who played the game the most to compile their strategies. Finally, I played a lot and wrote my own strategies.
My approach to strategy guides changed a lot after the first couple. More strategy, less instruction. But I always relied a lot on input from the designers of the games when available, and on personal experience playing the game.
Craddock: Since there are so many ways players can approach X-COM, how did you go about documenting strategies for winning the many types of ground missions; what to research first, second, and twelfth; etc.?
Ellis: I don't actually think I did a very good job of that in UFO Defense guide. I went more with a raw data approach—give the players a view of how everything works under the hood and let them decide how to best craft their research to get the stuff they want the fastest.
Craddock: The guide includes lots of charts, tables, and other graphics. How did you go about compiling that data and organizing it into a format players would find useful?
For UFO Defense, it was as easy as asking Julian and Nick Gollop for the data. They sent me a disc with everything I needed. I then put it into tables in a way that I found useful and hoped that other players would find it useful as well.
Craddock: What did you find most challenging about writing a strategy guide?
Ellis: Like testing games, the type of game you're dealing with determines the difficulty of writing the guide. Real-time strategy games and shooters make for the easiest strategy guides in my experience—when you can map out levels for the player and point out the locations and compositions of encounters, that's half your guide right there. Strategy games like Civ II are a lot tougher because there are so many potential play styles and paths to victory. That means a lot more in the way of viable strategies and potential approaches to the game.
The most challenging thing by the time I stopped writing strategy guides was the deadline. On the first few guides I wrote, I had several months to research and write them. Eventually, though, the deadlines got tighter and tighter. I wrote the X-COM Interceptor strategy guide in 28 days, which wasn't too bad, since I was the game designer; I knew all the strategies. But some later guides I did had to be researched and written in three weeks.
That's just not enough time to play the game and develop any meaningful strategies. That's why I stopped writing strategy guides. Too hectic and stressful.
Craddock: What did you enjoy most about writing the guide?
Ellis: Getting a behind the scenes look at the stats that went into the game. It was really educational in terms of learning game design. And, of course, I got to play a lot of UFO Defense. That's always a good thing.
Craddock: Looking back, what does the seminal game mean to you today?
Ellis: UFO Defense is a good example of how strong gameplay can make a game interesting even two decades after its release. The game isn't much to look at these days, but it's still as fun to play now as it was then. It's a testament to how good the game is that the Firaxis XCOM game is so similar to the original in terms of core mechanics. That's the mark of a good game—it stands the test of time.
David L. Craddock is the author of the bestselling Stay Awhile and Listen trilogy detailing the history of Blizzard Entertainment, Shovel Knight by Boss Fight Books, and over a dozen more books about video game culture. Follow him online @davidlcraddock on Twitter. Monsters in the Dark: The Making of X-COM: UFO Defense is funding now on Kickstarter.
Disclosure: David L. Craddock is the author of Monsters in the Dark: The Making of X-COM: UFO Defense, and the longreads editor at Shacknews.com. This post is not considered an endorsement of his book or its crowdfunding campaign.
-
Shacknews
replyDavid Craddock posted a new article, Pro Strats: X-COM (1994) strategy guide author David Ellis on QA and writing guides
-
-
This is one of my favorite games of all time.
-
This is one of my favorite sub threads.
-
-
-
[deleted]
-
