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!

Either a failed stealth attempt or a frontal assault -- the choice is up to the players in Deus Ex.

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!)

A Hong Kong temple, modeled from actual photographs.

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 interesting is most of the real world as a gaming environment? The answer was a tough-to-swallow "not very." Hotels and office buildings aren't great game spaces. And we were a bit naïve in thinking we could create a believable environment that didn't include many such locations.
• How do we live up to people's expectations, particularly of places they've actually been? Believable settings raised expectations to unrealistic levels. We started facing comments like, "That's not what the inside of the Statue of Liberty looks like. I've been there. I know."
• How do we force current simulation tools to deal with the object and NPC density and, even more crucial, the level of object and NPC interaction people expect in a "real-world game"? We worked very hard to make sure our world was overflowing with people and objects. But we wanted every person and object in the game to be believable. People had to behave like people. Every last object in the world had to serve some purpose. There would be virtually nothing that was "just" decoration. But that doesn't mean that everything works just the way you'd expect. We started hearing things like, "Hey, why can't I use that telephone to call anyone I want whenever I want?" and thus had to cut some objects whose real-world functionality we couldn't capture in the game.
• Are humans interesting enough to carry an entire game? The answer to this question surprised me more than anything else we encountered during development. We were about year into the game's development when designers and artists started balking at a game that was entirely about human beings. Movies don't need nonhumans to be cool but the same cannot be said, apparently, for games. People seemed to want monsters and nasty bad guys. The feeling was so pervasive that it changed my thinking completely. The original design spec called for a couple of robots, but the team demanded that they be made a more important part of the landscape, so we added several new bot types. We also introduced genetically manipulated animals and even some alien-looking creatures, all of which grew naturally out of our game fiction. The game benefited, but this was a radical change from the original plan.

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

A genetically manipulated creature called a "Greazel" was added to Deus Ex in response to the team's feeling that human interaction might not be enough to carry the entire game.

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.

One of the many weapons which can be chosen by players.

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.

A detailed weapon sketch.

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.

Everything in Deus Ex is about choices -- who you are in the world, how do you interact in the world, what are you carrying, and so on. In this case, the player has clearly decided to go through the game as a heavy weapons specialist, despite the fact that this will leave little room in inventory for anything else. [Expand Image]

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.