Postmortem: Crystal Dynamics' Tomb Raider: Underworld

[This in-depth postmortem from the creators of the latest Tomb Raider title, originally printed in Game Developer magazine earlier this year, explains exactly what went right and wrong during the making of the critically acclaimed franchise update.]

The concept phase of Tomb Raider: Underworld began while its predecessor, Tomb Raider: Legend, was in final QA and nearing submission. Previews for Tomb Raider: Legend were very encouraging, and we felt that there was still plenty of unrealized potential to
tap in the existing feature set.

Enough so, the reasoning went, that we could focus on content and leveraging existing functionality to develop
a bigger and better Lara Croft adventure in less time. In many ways this is what the team accomplished, but as is always the case in game
development, reality was more complex than we anticipated.

It is particularly interesting to note that much of what went wrong in development involved pitfalls that we anticipated but still fell into
despite our efforts to avoid them. It's important to note that most postmortems talk about "What Went Wrong" and not just "What We Did
Wrong" because sometimes you make mistakes, but other times you suffer from acts of god and do your best to cope.

A Game Developer
article last year ("What Went Wrong?" December 2008) specifically questioned why game development seems to make the same mistakes
over and over. In light of that, some of the "wrongs" will be discussed in terms of how our methods to avoid known issues fell short.

What Went Right

1. Long Alpha

We scheduled an unusually long Alpha to deal with unresolved pre-production issues and to set ourselves up for a
shorter Beta to make room for more polish time at the end. This paid off handsomely with respect to art production, and it's one of the
reasons the game looks so good. We also recovered from a fair amount of design deficit that had carried over from pre-production, and on the
code side we managed to get most of our core functionality up to scratch.

Another thing we did right during this long Alpha was to have multiple scope reductions. This was our first "next-gen" title, and we
repeatedly underestimated issues of complexity. We would assess and determine that the game was too big, and then cut enough content
to bring it under with margin to spare. Then two months later we would see that we were again coming in too big, necessitating further scope
reductions.

The game was designed to be able to handle this degree of reduction, as seen by the fact that almost all the features and areas
originally planned for the game made it into the final version, only smaller, and connected to each other in fewer ways. We managed to
reduce the scope by trimming branches everywhere without having to uproot any of the trees entirely.

2. Focus

When making a sequel, producing a game
just like the last one with slightly different content
and a few more features is an easy mistake to make.
Despite the fact that we had some significant new goals,
like making the traversal less linear and bringing back
more free exploration, we almost fell into this trap. But
many on the team saw that we needed an additional focal
point to both rally the team around and to use as a unique
selling proposition for the game. The result of this was the
concept of epic exploration puzzles.

Making large-scale in-game devices and areas with
multiple layers of connected puzzles gave the game
an exceptional expression even compared to previous Tomb Raider games, and it also gave us a litmus test for
spending production effort across the game. This led
to the creation of a sub team devoted to these puzzles,
which proved to be complicated constructs.

While we
would have been better off had we foreseen this need
and planned for it properly from the start, the fact that we
saw the growing concern, created this special sub team,
devoted more staff and resources to it, and assigned a
dedicated producer was an example of how well we solved
unforeseen problems in development.

3. Production Flexibility

Even though it was hard
to significantly redirect the juggernaut that was
Tomb Raider: Underworld, we made a lot of successful
changes when confronted with breakdowns of production
processes. We started out thinking that we knew the best
way to design the ruined jungle gyms that form the bulk
of a Tomb Raider playground, based on lessons we had
learned from the previous game, but reality confounded
us again, and we made changes accordingly.

One clear example is related to level design and art.
From the beginning we all agreed that it was critical
to have both disciplines work in tandem from day one
to make environments that were fun, beautiful, and
credible. Prior outings had either started with designgenerated
block mesh, leading to geometry that was
extremely difficult to turn into plausible ruins, or with
beautifully architected tombs that did not provide fun
climbing opportunities or properly authored gameplay.

Our solution was to pair level designers and environment
artists together by location in the world; such as Mexico
or Thailand, and have them work together, iterating
on environment architecture to make it both fun and
aesthetically appropriate.

While this proved to be the right direction, many
of our earlier processes didn't work out. But our
willingness to accept the reality that these initial
attempts were flawed allowed us take the big step
of changing production workflows in progress, often
multiple times.

It sometimes felt chaotic and frustrating
to change process so frequently, but had we stuck
with broken paradigms the situation would have been
far worse. In the end, our production methods weren't
perfect, but they were superior to what we thought
would see us through from the outset.