Postmortem: Crystal Dynamics' Tomb Raider: Underworld
September 2, 2009 Page 3 of 4
One of the earliest engineering tasks involved refactoring the player code to make it more robust and more able to accept new functionality. This effort was important to be able to efficiently expand our feature set, but it wasn't understood at the time that this refactoring meant taking apart the engine and putting it back together in such a way that it became unplayable for the duration.
The design team had been anticipating a comfortable period of working on layouts, experimenting with interactions, creating more evolved setups, and otherwise engaging in exploratory and iterative design that wasn't possible on Tomb Raider: Legend. But our preproduction hopes disappeared as much of the player functionality went offline.
The usual delays and schedule slips prolonged this dark period, during which the engine parts were scattered across the lawn. The problem was compounded when we had to move into production and deeper into Alpha without many core player functions working. This had a big chilling effect on early design and layout efforts, and the effects of this lasted all the way to the final product.
Fundamentally this was an issue of miscommunication, which is a traditional gremlin lurking on every project. We fought this gremlin from the start, and given the size of our production did a fair job of it, but this particular mishap was unique in how irreversible it was. Improving communication is about better information trafficking up front, but just as importantly, quickly addressing miscommunication when it arises, so we don't consider this one of those traditional mistakes that we repeated.
You can't catch everything, and the effects of refactoring slipped through the net, and once started, there was no going back. It was a particularly bad piece of miscommunication to have, and we just had to ride it out. In the end, a lot of valuable hands-on design time was lost at the start, and we would have had a significantly better layout in the shipped game had we caught the issue earlier.
Our preproduction got rocked by the previous two issues-the shared technology effort and how refactoring rendered previously playable mechanics unplayable-but we didn't have the option at the time of moving our ship date. This meant getting much less out of preproduction than we hoped for in two major areas.
First, it put us in a position similar to our time with Tomb Raider: Legend, with designers creating layouts based on paper metrics, where the mechanics would not be playable until later. Though this is a clear violation of good design practice, we felt that the damage could be contained because the design team had just finished making a Tomb Raider game with many of these same mechanics, so we could get by for longer without them. But the situation was far from optimal.
Second, aside from porting Tomb Raider: Underworld to the Xbox 360, this was our first project made for what were then next-generation consoles. It turned out to be far more complex and content-intensive than we anticipated, and because our capacity to create layouts was so compromised in preproduction, we couldn't adequately test, measure, or scope the art side of the production equation.
Because we needed to enter production by a certain date to have a reasonable chance at shipping on time, we ended preproduction before we had an adequate understanding of our art production needs and processes, and just as critically, before we had developed the pipeline and support structure we would need later for outsourcing art.
We were also understaffed in certain areas due to slots on our team being held for team members who were still finishing up Tomb Raider: Anniversary. In the end it was as though we planned to have a concept phase, a prototyping phase, and a preproduction phase, but in practice only did some concept, some prototyping, and then jumped straight into production before finishing preproduction.
Much of this pressure came from the collision between ambition and capacity, made worse by the cognitive dissonance between seeing a game on paper that you want to have, and knowing that the production data indicates you can't have it by the prescribed date, but being unwilling to change either one.
At the time, and indeed throughout the project, we knew it was risky to move on to the next phase of production before the previous one had completely finished, yet we did so anyway. This is one of those repeated mistakes, so why did we do it? Cognitive dissonance is part of the answer. Wishful thinking is another part. But mostly, in an imperfect world, every risk you take is a gamble that may fail, and at the end of the endeavor, you end up needing to explain only the risks you took that didn't pan out, like this one.
Page 3 of 4