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: 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.
Civ II's Civilopedia.
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: 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.
X-COM: UFO Defense on PlayStation.
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: 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.
:no_upscale()/cdn.vox-cdn.com/uploads/chorus_asset/file/22349263/Craddock_Monsters_in_the_Dark_special_edition.jpg)
