Postmortem: Gas Powered Games' Dungeon Siege
December 18, 2002 Page 2 of 4
What Went Right
1.Exceptional team. It's clear to me that the single best thing thing about Dungeon Siege is the team that created it. So many things are right about our team that it's difficult to elaborate on this without sounding as if I'm gushing. From the beginning, Chris Taylor set the tone for the company with strong values and an outrageous personality. Chris might be best described as a force of nature; he can help an old lady cross the street, tell you a joke that will make you seek psychological counseling, make a shrewd business transaction, and convince you that an impossible feature is actually easy, all in the span of about five minutes. He is certainly the hardest-working and most driven person any of us know. He instills the kind of respect that is pivotal in binding a team into a single, coherent unit.
The team itself is consistently calm in the face of pressure, persistent in the face of adversity, and absolutely dedicated to success. I have never worked in a group of so many selfless, dedicated, and positive people. At times we can be so focused and single-minded that by some definitions we might be considered a cult.
Another positive trait that contributed to the team's efficacy was that we shunned any kind of classism. At GPG, we have a culture where everyone is valued. We don't single out contractors or junior people as different, everyone's ideas get heard, and it's implicitly understood that every single person plays an important role in creating the game.
2.Exceptional art. Somewhere between the prototype and our first E3, something magical happened. It may have been when our technology started to hobble along such that people could finally see what the game might look like, or maybe it was when our tools became really usable. For whatever reason, since our first E3 and for about three years thereafter, the game just kept looking better every day. Art director Steve thompson and his team straddled an exponential curve of outdoing themselves and rode it to the very end. Over time the models morphed from "Hey, is that a bear or a giant rat?" to "Wow, let's see that again!"
Similarly, the level designers did a remarkable job. As the editor settled, their productivity skyrocketed. Near the end of production the volume of their output was stupefying. I'm still shocked when I think of our multiplayer world, which is far larger than the already large single-player world, and how it was built in a tenth of the time. Amazingly, as the level design team picked up speed, the quality of the output and attention to detail also improved.
From very early in the project we had a flexible effects system that was only marginally used because we were short of people, so not many assets took advantage of it. Late into the game's development, the art was already quite far along when we had an additional and surprising growth spurt. Eric Tams, our overworked content engineer, went ballistic and added so many special-effects embellishments that we were, quite frankly, astonished. Suddenly, the effects system was working overtime as swords were flaming, staffs were sparking, and so many other things we don't have names for were happening. It was a nice surprise, and one example among many of team members working with inspiration to make a difference. This sort of inspiration really helped the game evolve on all fronts.
3.Extreme flexibility. As a small company our flexibility is a distinctive advantage over a large company. Compared to what I've seen of many large companies, we can make important decisions 100 times faster. If you're trying to innovate, the ability to make decisions quickly is absolutely critical. At a large company, I've seen people discuss a minor issue for days on end. At GPG, if we need a resource, or if we've identified a project course correction, we meet with Chris Taylor and most of the time we will decide upon and commit to a specific course of action in under five minutes - very refreshing.
One of many serene alpine environments.
One of the more extreme examples of this sort of flexibility was our temporary test team. Deep into the debugging stage of the project, we were experiencing increasing frustration with the process. Up to this point, Microsoft, our publisher, was doing most of the testing, and although they were on-site for some time, they had moved back to the mother ship, complicating matters. Try as they might, the scope of the game was simply enormous. We needed more help. We realized this on a Friday, and by next Monday morning we had configured our own test lab. By the end of the week the lab was fully staffed and running double shifts.
We could be this flexible as a company only because our teammates were this flexible. Everyone carried multiple responsibilities, and some of us carried so many it was hard to keep track. As one example, Jacob McMahon wore the hats of VP, designer, producer, HR, accounting, bill paying, payroll, legal, and who knows what else. He also managed to place all the monsters in the game and gameplay-balance the entire thing, while only occasionally speaking in tongues. Such effort is representative of what we had to do in order to succeed.
4.Solid architecture. The engine underwent numerous architectural changes during development, and ultimately we were left with an engine that's both powerful and flexible. Because development included a lot of research, the architecture was forced to evolve through repeated reengineering to support new discoveries as well as new requirements.
Based on our experiences during the development of Total Annihilation, we knew even before we wrote the first line of code that we had to focus on a data-driven design. So although much changed about the architecture over time, the critical concept and goal of a data-driven engine persisted. Today it seems more fashionable to take this approach, but four years ago there didn't seem to be much focus on this issue. At that time, many game engines would inevitably stumble onto being data-driven, but it seems that few game engines were doing this in a premeditated and planned fashion.
Our goal of data-driving the Dungeon Siege engine was to support all the features of an action RPG but not hard-code how these features interact in order to create the look and feel of the game. Aside from the actual art assets, the look and feel of the game is defined by a combination of configuration, text files, and scripts. We used a general-purpose scripting language for AI, animation control, and spells, and a specialized language for scripting special effects.
The scripting system, Skrit, played a key role in the architectural success of Dungeon Siege. Written by Scott Bilas, it is implemented unlike any other scripting system we've seen to date. The language itself is conventional, but extending it by exporting engine functionality is easier than ever. Exporting a function is as simple as adding a single tag in the C++ code. Additionally, because Scott had to create a powerful back end to support Skrit, it became the basis for a remote procedure call (RPC) mechanism that made implementing multiplayer much easier. We leveraged the same technology for save and load and for many other systems.
The Fury uleases its wrath.
Based on another early architecture decision, the editor was essentially built on top of the game. Specifically, it was built on top of what we called the "world" layer of the game. The world contains all of the game mechanics, less the user interface. The world layer has no knowledge of a user interface, or even high-level gameplay goals such as quests. It's simply the game environment containing the map and all its life forms. The actual game executable is built by using the world as a foundation and adding a game component above it. The game component gives you the user interface, creates your hero, and has all the other trappings required to present the gaming experience to the user.
Alternatively, the editor is simply the world layer with an editing component on top instead of a gaming component. The editor component allows you to create and manipulate the world, whereas the gaming component restricts you to a particular experiencing of it. The benefit of this approach was that the editor took advantage of much of the work we did for the game engine. The drawback was that a careless change in the world layer for the sake of the game component could break the editor component. Chad Queen, who built the editor, was relentless in keeping the editor running such that this vulnerability wasn't ever much of a problem.
5.Instant messaging. We faced the typical set of communication challenges that plague most development teams. However, we had at least one success worth mentioning.
Consider the typical means of communication in the office: Normally when you urgently want to speak to someone, you call them. At other times, when you need a more formal and structured medium for communication, you e-mail someone. And sometimes, when you're sitting next to someone and just want to ask a quick informal question, you look over your shoulder to see whether they're in a good place to be interrupted.
In our first year, as a small group of fewer than a dozen people, we worked on the same floor and essentially in the same space. Because of our proximity, all of our informal communication happened in person. (It's amazing how much important work is facilitated through informal communication.) But when we started to grow we found ourselves in a communication conundrum. When engineering moved to a different floor of the building, that informal channel of communication with the other groups in the company was lost.
After a brief period of disorientation we identified the problem and called upon ICQ instant messaging to the rescue. It's a powerful tool and at times can actually be more effective than informally speaking to someone. Because ICQ is so informal, you can be very direct without being perceived as terse. You simply type in your question and you're done. No chitchat or small talk needed, no pressure to introduce yourself or your topic gracefully.
Instant messaging works very well in conjunction with formal e-mails and semiformal phone calls. It allows us to direct without offending anyone and is more efficient than waiting in line to speak to someone. If it's not a good time, the recipient of your message can simply ignore your request until his or her next convenience. Instant messaging had such a positive impact on our work that I can't imagine ever working without it.
Page 2 of 4