|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: Ion Storm's Deus Ex
What Went Right 1. A clear high-level vision. It's pretty self-evident that you can't achieve goals if you're not clear about what they are. We knew with a high degree of confidence what kind of game we wanted to make. This was possible for two reasons. First, Deus Ex is a natural outgrowth of work done by and in some cases with the late, lamented Looking Glass Technologies. We were inspired as well by games made at Valve, Origin, and a host of other places. Many of the things we wanted to do were a reaction to things they (or we) didn't do, didn't do well or couldn't do at all in earlier games. We weren't building from scratch, but rather building on a foundation already laid for us. Second, and on a personal level, Deus Ex is a game I've been thinking about since right around the time Underworld 2 shipped. I've tried to get a game like this started several times (as Troubleshooter at Origin; in some respects, as Junction Point, for Looking Glass). Those games didn't happen for a variety of reasons:
Still, I never stopped thinking about these games and, despite their failure to reach production, they laid much of the conceptual groundwork for Deus Ex. The lesson here is that if there's a game you really want to make, don't give up on it. Someone will be foolish enough to give you the money eventually. As an interesting (I hope!) historical footnote, I include here for the first time publicly, complete with typos and misspellings, the very first proposal I ever submitted for the old Troubleshooter concept back at Origin. Note the budget and projected release date and, oh, those system requirements! Note also the similarities (and differences) between Troubleshooter and what eventually became Deus Ex. [Troubleshooter Proposal] Several years passed. Lots of games somewhat like Troubleshooter came and went. Game budgets went up dramatically -- $500,000 indeed! I left Origin and go to work for Looking Glass. Troubleshooter stayed on my mind. In the fall of 1997, before Ion Storm entered the Deus Ex picture, I drafted a manifesto -- a description of an ideal game -- and also a set of "Rules of Role-Playing." Much of that material ended up in an article published in Game Developer ("Remodeling RPGs for the New Millennium". Here (for more of those historical reasons mentioned above) is the original draft of my Rules of Role-Playing, circa 1997: The Rules of Role-Playing
A year or so later, Deus Ex lead designer Harvey Smith clarified and extended the original rules as follows: The
DEUS EX Rules Amendments & Addenda
The details of Deus Ex -- plot, character, game system design -- all changed radically since the days of Troubleshooter and manifestos and rules and rules addenda, but conceptually the game still follows most of the rules and meets the ideals outlined in the Game Developer article. With these conceptual tools in mind, the Deus Ex team was able to assess design decisions and game system specifications, in light of what we wanted players to experience during the game and in light of our ultimate design goals. So What Were Our Goals (In the Beginning)? How did we intend to move from abstract ideas to game design specifics? We had to take our thinking to a deeper level. We had to start thinking about what we wanted players to be doing and thinking about as they played the game, rather than what we would be thinking about as we developed it. This led to some critical concepts, outlined here:
To recap: Know what your gameplay goals are and what kind of experience you want players to have before you spend ten seconds thinking about anything specific. Nice talk, but what did clear goals, manifestos, and commandments buy us? 2. We didn't skimp on preproduction. We spent the first six months of I (before we licensed a game engine), with a team of about six, just thinking about how we could turn our high-level goals into a game. We hammered on the setting and decided to move the game into the near future to buy ourselves some room to play around -- the real world, as we quickly discovered, was very limiting. Ultimately, we settled on a conspiracy-oriented background. Here's what we had when we started: the very first design proposal (again, as is) for Shooter, our ironic working title for a game we never intended to be "just" a first-person shooter. [Shooter Proposal]
First of all, ignore the projected ship date of Christmas 1998. That was never possible, not for an instant. I don't know what I was thinking. Anyway, other than that (ahem) little misstep, the original Shooter doc does a pretty good job of describing the game that eventually became Deus Ex. Details changed. System specs definitely changed, but overall I don't think anyone can say we didn't deliver the game we said we would. But how did we get from Shooter to Deus Ex? What were our first steps? We worked on back-story stuff so we'd know what was going on in the world, even in places the player never got to visit. Some of this stuff may come to the forefront in Deus Ex 2 but, for Deus Ex, it was just a way of making sure we knew enough to include the kinds of small details that make a fictional world convincing. We did a vast amount of research into "real" conspiracies -- the Kennedy assassination, Area 51, the CIA pushing crack in East L.A., Dwight Eisenhower's UFO connection, and of course Freemasons tunneling below the Denver airport and building abducted-baby cafeterias for alien invaders at George Bush's direction. Only a fraction of this stuff ended up in the game, but it gave us a peek into the minds of conspiracy buffs that was both scary and useful. We also created a cast of more than 200 characters, many of whom didn't yet have specific roles in the game. Ultimately, this list proved to be both a help and a hindrance to designers as they fleshed out the missions. Characters sometimes suggested missions or subquests, but just as often ended up being filler we were reluctant to cut, even though their missions or story purposes changed during our storyline-focusing passes.
We worked out a bunch of missions -- more than 25 of them, taking the player from New York to London to Paris to San Antonio, to Austin to Siberia to Washington, D.C., to NORAD to Sunken L.A. (post-earthquake) to the Moon. We had wars in Texas, raids on concentration camps to free 2,000 prisoners from UN troops under FEMA control. Those of you who think the Deus Ex story line includes everything plus the kitchen sink now should have seen what we started with! We hammered on game systems. We conceived a skill system that didn't depend on die-rolls or tracking skills at a fine level of granularity. We came up with a system of "special powers" (nanotech augmentations) that differentiated the player character from ordinary humans. We designed a conversation system with some cinematic elements and some elements borrowed from console RPGs. We mocked up 2D inventory, skill, and augmentation upgrade screens, map screens, even a text editor so players could take notes. We conceived several player reward systems, including skill point awards, augmentation upgrades, weapon availability timelines and tool/object availability timelines. By March 1998, we had 300 pages of documentation and thought we knew everything we'd needed to know to make a game. Were we ever wrong. In the time between March 1998 and our Alpha 1 deadline of April 1999, that 300-page document mushroomed into more than 500 pages, much of it radically different from what we thought of and wrote initially. Clear goals and a detailed script are all well and good, but goals change, thinking changes, and game designs have to change, too. Which leads nicely into the next thing that went right. 3. Recognizing that game design is an organic process. Why did our thinking and goals change? There were lots of reasons. NEW PEOPLE = NEW IDEAS First, new people joined the team, with new ideas. Our staff grew from six people to roughly 20. I hired a bunch of people, of course, but we had the added excitement of integrating an entire art team assigned to us, in Austin, by an art director a coupleof hundred miles away in Ion Storm's Dallas office. Despite all the preproduction work, despite all the rules and manifestos, Deus Ex was, like all projects, going to be created by a group of people, each with his or her own agenda, many of whom hadn't been involved in the preproduction process. In other words, like all projects, Deus Ex was a living, evolving, growing thing. And there were some amazing growing pains associated with its development. Getting everyone on the same page wasn't always easy. (O.K., sometimes it was a nightmare!)
As we brought on new people, we found ourselves to be a team of hardcore Ultima geeks, hardcore shooter fans, hardcore immersive sim fans, strategy game nuts and console gamers. Some of our new team members proved to be "maximalists" -- wanting to do everything, special-case lots of stuff, and stick as close to reality as possible. Other team members proved to be minimalists -- wanting to include fewer game elements but implementing them exceptionally well, in ways that could be universally applied rather than special-cased. Also, we made a point of letting select friends and colleagues play the game at various points along the way. We were interested in well-reasoned opinions from folks who understood the kind of game we were making intimately and who had a handle on the development process that was at least as good as our own. With all the new folks contributing and all the feedback from our chosen critics, well, let's just say we had some interesting debates at Ion Storm, Austin. Out of those debates new ideas arose, and the game changed as a result. TECHNOLOGY IMPOSES LIMITS Technology forced design changes, too. It took time to become familiar with the Unreal engine. I wish I could say we uncovered all its potentials and limitations quickly, but we didn't. Months of experimentation were necessary to reveal how best to do things in Unreal and what things not to do at all. When we stopped playing with Unreal andactually started working with it (roughly six to nine months after we got our hands on it), lots of ideas we'd come up with in the abstract didn't work quite as well in reality. Multiple solutions falling out of our simulation didn't happen as often as we'd hoped. We just didn't have a deep enough simulation nor did we have the time or personnel to create one. We found ourselves in the position of having to brute-force the multiple-path idea, as developers on Ultima games, for example, have done for years -- though I think we do more of it, more consciously and more effectively, than anyone else has to date. Designers have had to plan a "skill" path past problems, an "action" path and a "character interaction" path. It works, but it's not what we originally intended. Our original plan to build large, outdoor areas -- whole sections of New York, Area 51, lovingly recreated in excruciating detail gleaned from maps and satellite photos and, most notably, my dream of allowing players to explore the entire White House -- just proved to be unfeasible. There was no way any then-current renderer was going to allow us to do all that. The design had to change. GAME SYSTEMS DIDN'T WORK AS INTENDED A third area that influenced the changing nature of the game's design was when the game systems didn't work as we intended them to. High-level concepts imply gameplay but don't -- and can't -- define it. We quickly found that descriptions of game systems are no substitute for prototypes and actual implementation. We prototyped every game system, as documented, relatively early on. We built some test missions, not quite early-on-enough but still early. These test systems and missions revealed gaping holes in our thinking or things that we thought would be true that turned out not to be true at all. For instance, our augmentation and skill systems proved dry and rather dull, once implemented, despite looking really good on paper. Those systems were designed around the totally valid idea that the computer would resolve actions without any secret (or even non-so-secret) die rolls required. Players would always know, with absolute certainty, based on their character development choices, whether they could accomplish something or not. The trick would be whether they wanted to do something or not, based on an assessment of the likely outcome and the likely consequences (for example, blowing down a door and setting off alarms versus the risk of picking a lock and being caught while doing it). In addition, I thought the tension of standing outside a locked door, not knowing if a guard was going to show up while you picked the lock would provide sufficient excitement. I thought knowing you could leap across a chasm because you had the Jump augmentation at Tech Level 3, opening up new paths through maps that were inaccessible to players without that augmentation, would be good enough to keep players interested. When Gabe Newell from Valve came down and played our prototype missions, he correctly identified the utter lack of tension in our skill and augmentation use, as written up in the design doc and ably implemented by the coders. The worst was confirmed when Marc LeBlanc, Doug Church, Rob Fermier, and other friends from Looking Glass Studios and Irrational Games played the proto-missions and came to the same conclusions. Actually using skills and augmentations revealed things that merely thinking about them could never have revealed. We took the criticism, and with it in mind, lead designer Harvey Smith revised the skill and augmentation systems pretty thoroughly, proposing an elegant system of consumable resources and time passage, all tied to skill level. This increased the tension level, provided new rewards, and allowed players to think and make informed decisions. Harvey also proposed a revision to the augmentation system, introducing an energy cost for their use (something I had foolishly rejected earlier on). Again, this gave us the opportunity to hand out items that would replenish energy -- in other words, we instantly had more things to hand out to players as rewards. It also introduced a level of tactical thinking to augmentation use that makes the system work. None of this would have happened without prototype missions and some harsh (but fair) criticism they allowed. HOW FUN IS THE REAL WORLD, REALLY? Another big reason for changes from our original design doc was our realization that the idea of a real-world RPG with real-world locations and real-world weapons was better in some ways than it turned out to be on the screen. Not to put too fine a point on it, Deus Ex became a lot less realistic as time went on. When we started building places such as the Statue of Liberty, a couple of square blocks of New York City, the White House, Parisian streets, and so on, we found ourselves constantly asking several questions:
How do you know which of your core game goals are valid and which need rethinking? How do you know which game systems work and which don't? When is it possible to know what your game is really about? These questions are all answered by the "proto-mission." This is the first implemented mission, playable start to finish, the one that captures everything you want your game to be. Get this mission working as early as possible, so you can see all the things you thought would work that didn't. Then fix them
4. Scheduling around successively more refined "proto-missions" It's a truism that milestones should be testable, showing visible progress, whenever possible, and we lived up to that standard. We could always pull a version together, always show off for press or our publisher. Most importantly, we always knew where we were (even if that knowledge was sometimes painful). But the proto-mission idea is something beyond simply visible, testable milestones. The proto-mission is critical in the process of design, as well as in milestone and schedule setting. One example of where our proto-mission idea was successful was in May 1998, when our milestone was to have prototypes of critical game systems in place and two test maps running, in this case the White House and part of Hong Kong. The maps were crude, the conversations raw, and the game systems hacked, but we could see -- and show -- the potential. To our advantage, we resisted the temptation to do just the stuff we knew would work and the stuff that would look the prettiest, and prototyped new, risky stuff first. Conversation, interface, inventory, skills, and augmentations were all at least hacked in so we could see them in action. The White House was likely to prove our toughest map challenge, so we built it first. (Almost unbelievably, I missed what may have been the riskiest, most critical game system in all of our early prototyping, NPC AI. I should have insisted on early prototyping of our AI but I didn't.) With the proto-mission system, we could immediately see some of the limitations of our technology. For example, we had some serious speed problems with areas as big as the White House and Hong Kong. After this, we knew we'd have to break maps up into small pieces. And we began to suspect, though I couldn't quite embrace the idea, that we'd eventually have to cut maps and missions from the game -- most notably the White House.
In May 1999, we had a milestone calling for the delivery of the first two missions of the game, playable start to finish. All of our game systems were implemented (not hacked) as originally documented. You could start a game, create a character, upgrade skills, solve problems in a variety of ways, manipulate inventory, acquire augmentations, talk to NPCs, get and accomplish goals, save your game, and so on. To the team's chagrin, I had a tendency to call this the "Wow, these missions suck" milestone. It was around this time when Gabe Newell came for a visit and gave us our wake-up call, and where we all went, "Ulp! We have a lot of work to do." Our earlier demos had shown the potential of what we were doing. This demo showed us how far we had to go before we reached that potential. This milestone also benefited us in that it showed us all the steps necessary to create a mission, and revealed the elements that really made the game work. That knowledge allowed us to go through our 500-page design document and cut everything that was extraneous, winnowing it down to a svelte 270 pages. Less game? Not at all. What was left was the best 270 pages -- the stuff that worked. "Less is more" was something Harvey Smith had said over and over, from the day he signed on as lead designer. While some team members resisted this notion outright, I took a middle road, which just frustrated everyone. In the end, we cut a lot, left a lot, and made a game that everyone on the team was happy with (I think). This milestone made it clear that the time had come to make cuts, while giving us enough knowledge to cut intelligently. If we had waited until beta to make cuts, with just a few months to go before our ship date (as many developers do), it would have been a disaster.
5. Licensing technology. We went into Deus Ex hoping that licensing an engine would allow us to focus on content generation and gameplay. For the most part, that proved to be the case. The Unreal Tournament code we ended up going with provided a solid foundation upon which we were able to build relatively easily. Dropping in a conversation system, skill and augmentation systems, our inventory and other 2D interface screens, major AI changes, and so on could have been far more difficult. UnrealEd, the main tool our designers used to generate our maps, was superior to anything else available. UnrealScript was very powerful and allowed programmers to do lots of interesting things quickly and easily. The dollars and cents of the deal were right, and I didn't have to hire an army of programmers to create an engine, 80 percent of whose functions already existed in Unreal Tournament. We were able to make what I hope is a state-of-the-art RPG-action-adventure-sim with only three slightly overworked programmers, which allowed us to carry larger design and art staffs than usual. However, to my surprise, licensing technology didn't save us all the time I'd hoped it would. You'd think cutting a year or more of engine-creation off a schedule would result in an earlier release date. On Deus Ex, that didn't prove to be the case. Time that would have been lost creating tools was lost instead to learning the limitations and capabilities of "foreign" technology. Time that would have gone into making an engine went into focusing more on gameplay systems and tuning than normal. Unreal certainly allowed us to focus on content generation over everything else, but we spent more time doing it.
The biggest downside to licensing was that we were just never going to understand the code as well as we would have if we'd created it ourselves. That led to two distinct kinds of problems. First, there were areas where we ended up treating the engine as a black box. I think it's pretty well documented by now that we shipped Deus Ex with some Direct3D performance issues. Honestly, that didn't show up in any significant way during our QA process -- a slight problem here or there, but none of the dramatic slowdowns some players reported in the early days following our ship date. Once players started reporting troubles, we were kind of in a lurch -- we couldn't very well go in there and mess with the Unreal engine -- we just didn't understand it well enough to do that safely. We had built around the edges of Unreal without ever getting too deeply into the nuts and bolts of it. Second, because we didn't know the code inside out, and because we'd shelled out a fair amount of money for it, we tended to be conservative in our approach to modifying it. There were times when we should have ripped out certain parts of the Unreal Tournament code and started from scratch (AI, pathfinding, and sound propagation, for example). Instead, we built on the existing systems, on a base that was designed for an entirely different kind of game from what we were making. It's not that Unreal had bad AI or pathfinding or sound propagation, but those systems were designed for a straightforward shooter, which was not what we were making. Technology licensing bought us a lot and cost us somewhat less. I guess the fact that we'll be licensing technology for our next round of projects, Deus Ex 2 and Thief 3, says the price was right. But it remains an interesting dilemma, and we will be able to approach our next licensed engine with the wisdom gleaned from using Unreal for this project. ________________________________________________________ |
|
|
Features
