Postmortem: Gas Powered Games' Dungeon Siege
December 18, 2002 Page 3 of 4
What Went Wrong
1.Extreme ambition. Extreme ambition can be empowering, but it can also bring much pain. A large portion of Gas Powered Games consists of extraordinarily ambitious people. Every-one has their own reasons, but collectively, we all want to win, and want to win badly. While this drive helped us persevere through some of the challenges we encountered during development, it also created some new ones.
Our ambition translated into a number of painful symptoms such as feature creep, over-optimism, and a project scope that was ultimately larger than our ability. The problem was compounded by the fact that nobody on the team had really worked on an action RPG before. We looked at the "leading brand" RPG and said to ourselves, "Hey, this is a fun genre. Let's make something like this except, much, much bigger, in 3D, without loading screens, and push the technology to its absolute breaking point!"
Clearly we couldn't have imagined the sheer amount of work required to build the kind of RPG that we wanted. And we wanted all kinds of interesting things: lip-synching, cooperative networked level editing, dual monitor support, wavelet terrain compression, deformable terrain, and many other gems. Some of these features ultimately didn't fit into the vision of our game, while others were simply extraneous. To our credit, we killed most of these before even starting development, but we were left with many others to be enthusiastic about for months.
Early explorers Fedwyrr and Klars discovered much of the route traveled in Dungeon Siege
Our ambition when mixed with our pride also set us up for some hard lessons. The first year of Gas Powered Games was the honeymoon period. Everyone was full of ideals and had the boundless energy required to discover their inevitable pitfalls. Many of us were excited to have shed the shackles of Big Brother software companies and finally be in charge of our own destinies. No more lame meetings, no more stupid schedules, no more dog-and-pony shows. We were not going to adopt any of the stale, dated, and oppressive habits of game companies past.
Four years later, we have a deep appreciation for organization. Chain of command, ownership, discipline, and planning are things that we hold in very high regard and are further developing for the future. We still don't like Big Brother, but we realize that Little Cousin may help us get more work done.
2.Aborted efforts. We spent too much time exploring dead ends and implementing unnecessary features. The game's basic gameplay principles and aesthetic goals remained consistent from the beginning of the game to the very end. Unfortunately, although we were clear on how we wanted the game to look and feel, the technical requirements weren't obvious. We were feeling optimistic, and anything and everything sounded like a good idea at the time. Design meetings felt like a shopping spree at the supermarket. We loaded up the cart and set out on a rather long road of trial-and-error punctuated with discovery.
The animation editor we attempted to build is a good example of the trial-and-error approach. At the time we had a developer who was both skilled and extremely passionate about creating our own animation tool. Given our ambitious state of mind, we were easily sold on it, and the developer spent a better part of a year working on the tool. Unfortunately, a year into it his calling took him elsewhere, and the editor work came to a screeching halt. This serious setback forced us to reconsider the necessity of this custom art tool. Almost immediately we reexamined what was possible with 3DS Max as senior programmer Mike Biddlecombe dove in to create a few plug-ins that did the job beautifully. Lesson learned: always use third-party tools when they're available.
Although the aborted editor is our poster child of inconclusive work, there were many other technologies we spent a lot of time on but didn't use. For example, we started on OpenGL but ultimately moved to Direct3D. We also wrote level-of-detail systems and sophisticated collision algorithms that we ultimately scrapped.
3.Complex engine. We have created a powerful but ultimately complex engine. To our credit, the engine is stable, relatively well commented, and the source is consistent in terms of coding standards. However, the engine is sufficiently complex to make debugging and maintenance times often longer than expected. Complexity arose from several factors.
First, the engine is large enough that although in the local sense things are documented, in the global sense there are implicit rules that are not. This unfortunately translated to a larger number of nonobvious bugs. The nonobvious bugs tended to be in the "incorrect result" category rather than in the critical program-failure category, which made them harder to track and slowed debug times. The implicit rules in the system made it more likely that a seemingly simple change might create an unwanted side effect down the road even if we did get correct behavior in the short term. The best examples of this problem were single-player changes that worked absolutely great but broke something in multiplayer or simply failed to work in multiplayer.
Additional complexity can be attributed to a few elements of the engine that should have been abstracted but weren't. One example of this is our node-based coordinate system. The coordinate system reflects the segmented nature of our terrain. Every position primitive includes an ID of a terrain block (node) and a 3D coordinate within that node. Global coordinates aren't valid for more than one simulation, so if you want to work with a point outside of your particular node, you have to do space conversions. This introduced extra steps to every space calculation and increased the risk of human error. We got used to working with this system and shipped the game without abstracting these artifacts away, but we paid a high price in maintenance of affected code. In the future we hope to wrap this up in a cached global coordinate system that would make our vector math look like the math to which everyone else is accustomed.
4.Slipped schedule. When I started this Postmortem, I wanted to avoid talking about the two most common problems faced by development teams, communication and schedule. Every single project seems to have trouble here. I've managed to steer clear of communication rants, but I must mention our schedule, since we made a spectacular game but spectacularly late. Originally we were aiming to finish in just about two years, but ultimately we shipped in almost four.
A panorama of castle Ehb.
During this time, however, we weren't just building a game, we were also building a company. We spent a considerable portion of our time simply learning how to be a company and learning how to make an RPG, something that we had never made before. Learning and ambition aside, our schedule first slipped considerably when three out of the six engineers left the company about a year into the project. They each had their own reasons and they didn't leave in unison, but the blow dealt to our planning put the engineering schedule into a permanent state of shock.
After that first year, the turnover at the company was very low, and it certainly wasn't the only culprit regarding the slipping schedule. In order to make a competitive title that was original, we essentially had to invent new features that we would use to compete with existing games. This goal simply required a lot of research, which is inherently difficult to plan or schedule. It also tends to lead to . . .
5.Epic crunch. Our crunch was not your garden-variety crunch. Our crunch was not measured in months, but in years of long hours and few free weekends. It was a crunch of sheer astronomical proportions. The kind of crunch that will make you weak in the knees to think about and give you a thousand-yard stare when you're done with it. The kind of crunch that bites the top of the beer bottle off and spits it out at you before taking a drink.
This kind of crunch can only take root in fertile soil, so we certainly are responsible for our own discomfort. Being the ambitious bunch that we are, not only did we want to make a great game, we wanted to make the best game we could afford, given the time and resources. This line of reasoning, taken to its limit, translated to most of us simply living for the game.
Our ambition was so strong we neglected our bodies, our relationships, and our spiritual well-being. I know many of us did this past a point that most professionals would consider healthy, sane, or possibly ethical. The level of focus on our work was simply amazing, but the sheer self-neglect this fostered was simply irresponsible. We didn't crunch to make up for lost time, we crunched out of uncertainty. Since this was our first RPG, we crunched to implement all those extra features. And at some point we crunched because we could no longer remember doing anything else.
A wise person once said that your passion can become your prison. We were so passionate about making Dungeon Siege that we completely lost ourselves in its creation. Having a tremendous desire to succeed is a noble trait, but being unable to reconcile that desire with the actual cost of attaining your goal is not. It's difficult to be critical of ourselves when we all cared so deeply about the game and worked so very hard to build it. But we must remember that we make games. We are toy makers, and we have a responsibility to our own humanity as well as to our trade. We must strive to live balanced and enriched lives so that we may always have inspiration from which to draw.
Page 3 of 4