4. Acts of God
This is the category that some postmortems title "Too Many Demos" or some other problem that comes at a team from the outside. We certainly had the problem of too many demos, but those were only one entry in a class of problems that dropped on us unprepared.
Demos were particularly aggravating because we specifically set out to avoid this issue from the start. We demanded long term demo schedules, and we received them. We refused to bow to some requests for demos that weren't on the schedule, and this was honored by the publisher. But there was also a slippery slope, where some unscheduled demos were accommodated because of various circumstances.
We sometimes faced a dilemma where marketing gave us a choice in which a particular demo, at the expense of two weeks of production time, seemed like the better long term choice for the success of the product. There are too many stories of great games disappearing into the noisy marketplace to ignore the importance of demos and good PR.
Yes, these demos often result in a reduction of product quality, and yes they distract from team focus, but in the end, as painful as it feels, it's sometimes best to do the demo. This is a clear example of walking into a trap with eyes wide open-making a mistake that you know about in advance-but it happens repeatedly because the answer isn't to refuse demos, or to plan for them better. The answer is to make a game that doesn't come together only at the end.
We also had an unusual number of weddings, honeymoons, production babies, and untimely departures on this project throughout the team, but most painfully among the discipline leads. We lost our art director midway through production; not to another company, but to another industry, so there wasn't much we could have done about that.
We lost our lead designer toward the end of production when she had a baby; also something we couldn't have done much about (nor would we have wanted to, as the baby is beautiful!). And most tragically, our lead level designer died suddenly during the first half of production.
These key figures in our effort were extremely valuable not only because they were smart and capable, but also because they were a part of the success of Tomb Raider: Legend, and therefore knew intimately how to make this kind of game. People like that are rare, because Tomb Raider games are hard to make for many reasons, and in the timeline we were under, they were irreplaceable.
We compensated for these losses with people on the team assuming new responsibilities to fill in the gaps, and some of these team members did amazing work and really saved us, but there's no denying that we would have had a much smoother production and a better end product without these losses.
Yes, we tried to do too much. It's human nature to reach as far as you can, and to think your arm is longer than it really is, but some games are more sensitive to scale than others. If you make a sudoku game, you can keep making grids until time runs out and you're done, but with games that have interlocking feature sets, plus a beginning, a middle, and an end, it's much harder to scale properly, and harder still to change scale during production.
There were success stories with respect to our scope, and with reductions we made all the way to Beta, but in the final analysis we tried to do too much, got locked into needing to do it, and scrambled to get it all done to the quality standard we hold ourselves to.
The reason why scale kept outdistancing our deadlines is mostly because we underestimated the complexity of next-gen development and did not spend enough time in preproduction smoking out all the issues.
The biggest casualty of making too much game wasn't the crunch time-we had less crunch than on past games-and it wasn't that we left parts of the game undone, since there are no holes in the experience. The most damage was to an element that was very important to us: polish. We padded our schedules an unprecedented amount, and then some, in order to have sufficient time to polish.
Unexpected complexities in next-generation development, along with communication throughout a team larger than the studio had ever seen, consumed our polish time and more. This makes the mistake of underestimating our polish time more understandable, even though this is also one of those repeated "what went wrong" scenarios, because we were dealing with a whole new class of unknowns. This won't be the case going forward, however, so the team should be equipped next time to avoid the usual mistake of not scheduling enough polish time.
Our game was intended to be a strong sequel that drafted heavily off the successes of Tomb Raider: Legend, but turned into a major product in its own right; bigger and more lush than anyone could have reasonably expected at the outset, because of the hard work, talent, flexibility, commitment, and level heads of the many team members who created it. It's very gratifying that some reviews have hailed Tomb Raider: Underworld as the best Tomb Raider game since the first one, and the fan response has been phenomenal.
So why did so many things that we guarded against go wrong anyway? The categories described here are only five of many more. (Broken builds and long build times get honorable mentions, and the added distinction of raising blood pressures more than probably all other issues combined.) Doesn't the foreknowledge of pitfalls make possible the absolute avoidance of them?
No, it doesn't. Creative endeavor by its very nature is chaotic, and where creative chaos, ambition, and dedication collide with production concerns and the hard walls of a publisher's deadlines and goals, you're going to fall into many of the same holes, or worse, get steered into them. The answer isn't to do everything possible to avoid all known traps, because doing so would kill innovation and creativity; the trick is to be aware of potential pitfalls, and to be prepared to quickly and nimbly mitigate the negative impact of stepping into one.
Developer: Crystal Dynamics
Number of Developers: 84 internal staff, 15 contractors, not including shared technology staff
Length of Development: 2.5 years
Release Dates: November 18th USA, November 21st EU
Hardware: Quadcore PCs with 64-bit OS, 4 GB RAM, 500 GB RAID 1
Software: Turtle rendering package, Bableflux, Perforce, MotionBuilder, Maya 8.0, Zbrush, Photoshop, Bink, FMOD, Test Track Pro, and proprietary graphics and physics engines
Platform: Xbox 360, PS3, PC (also Wii, PS2, and Nintendo DS)