Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Crystal Dynamics' Tomb Raider: Underworld
View All     RSS
October 24, 2014
arrowPress Releases
October 24, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Postmortem: Crystal Dynamics' Tomb Raider: Underworld

September 2, 2009 Article Start Page 1 of 4 Next

[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.

Article Start Page 1 of 4 Next

Related Jobs

Activision Publishing
Activision Publishing — Santa Monica, California, United States

Tools Programmer-Central Team
Crystal Dynamics
Crystal Dynamics — Redwood City, California, United States

Senior/Lead VFX Artist
Magic Leap, Inc.
Magic Leap, Inc. — Wellington, New Zealand

Level Designer
Magic Leap, Inc.
Magic Leap, Inc. — Wellington, New Zealand

Lead Game Designer


Timothy Dempsey
profile image
I don't get it - wasn't this game a commercial flop that resulted in layoffs?

John Woznack
profile image
Re: Shared Technology.

This is a concept that every VG development shop I've worked at (and many I've read about) try, with the sad result of painful failure. Failure, not because the idea is bad - far from it - but because the organization and execution is usually wrong.

For a "Tech Team" concept to succeed, the development shop's Technology Director needs to understand three things:

1) For any technology to be shared/reused between Production Teams, it must first be _designed_ to be shared. This means the Tech Team must plan ahead and make it as easy as possible for Production Teams to modify/adjust the technology to fit their game. Production Teams need to be able to "specialize" the technology for their game/platforms.

2) Tech Teams must be somewhat insulated from Production Teams. You can't expect the Tech Team to be 100% responsive to multiple Production Teams. As pointed out in this article, Production Teams often times have conflicting needs.

3) Production Teams need to be somewhat insulated from the Tech Team. The worst thing for a Production Team is to have technology changes forced upon them when what they've got is working for them already - especially as the team creeps closer to Alpha.

Here's the best plan I've come up with so far for running a Tech Team and multiple Production Teams.

1) The Tech Team:

a) Responsible for the overall technology of the development shop. This includes VG engine, development tools, art tools, asset repositories, and 3rd Party tools/middle-ware.

b) Can't develop in a vacuum. Their "customers" are the Production Teams.

c) Can _occasionally_ take time out to adjust the technology for a given Production Team's game, but need to concentrate on improving/maintaining the technology for all Production Teams, not just one.

d) Responsible for teaching the Production Teams how the technology works, what the limits are, and why.

2) The Production Team:

a) Responsible for producing a product (video game).

b) Must provide technology requirements/features to the Tech Team for their game development in the pre-production phase.

c) Have at least one software engineer and one technical artist acting as liaisons to the Tech Team.

i) These two control the flow of technology between their Production Team and the Tech Team.

ii) These two will begin the Production Team's development cycle with the Tech Team's current technologies.

iii) When the Tech Team releases updates, these two will determine if/how those updates can be easily (and, ideally, seamlessly) integrated into their Production Team's pipeline. Note that as the Production Team's game development matures, they should start rejecting new updates, opting instead to stabilize the technology base of the Production Team so as not to introduce any new bugs, headaches, etc.

iv) During development, these two will also be responsible for making any technology changes necessary for their Production Team's benefit. There are three types of technology changes: Mutation, Evolution, Revolution. Mutations are to be discarded at the end of the development cycle. Evolutions and Revolutions are to be handed back to the Tech Team for evaluation and possible re-factoring back into the technology base.

This is just a quick summary. There's obviously a lot more to running a VG development shop with a dedicated Tech Team. But perhaps these few ideas here will spawn some better ideas in the minds of those working in this industry.


John Woznack
profile image
Note for Gamasutra: I officially loath the comment engine's ability to strip out leading indentations...grrrr

Curt Perry
profile image

It sold over 2 million units across all platforms. I would hardly call that a flop. Layoffs aren't always correlated with sales performance.

David Sattar
profile image
Respectful nod to Eric Lindstrom for the brutally honest appraisal of both what went well and what went wrong, but I have to ask about one item in the 'What Went Wrong' category.

Demos - honestly - with a rock solid franchise established, why bother ? With a totally new Intellectual Property, sure, probably do have to have a demo, and as a gamer I've certainly bought several games based on demo versions, so I can testify to the value of demos. But why stress the team getting a demo out during the production phase on an established franchise that everyone already understands ?

'Lara Croft' is a legend in the gaming world and even *non* gamers know who she is. The movie industry did Eidos a huge favour with the Angelina Jolie movie. Heck, my 70 year old Aunt probably knows who Lara Croft is. So if everyone on the planet with a credit card knows who the character is, and everyone who already plays games know the basic mechanic of the Lara Croft game - why stress your team producing multiple demos ? Why not get the game done, and then, in the quiet aftermath of 'going gold', perhaps put a demo together to pick up sales from the 37 hermits living in caves who don't already know what the Lara Croft franchise is all about...

Oh, wait - those hermits - they don't have computers, so they won't be buying the game anyway ! so there's *no* need for a demo.

Stephen Northcott
profile image
I hate to comment negatively, but I am compelled to do so in this case..

The article is much appreciated, and having been there myself, I can sympathize with a lot of the problems you faced.

But, and it's a very big but, they are problems faced by all devs on all products since time immemorial, and I think the sleight of hand with which you try to cover your "problems" by saying you saw them going into situations is disingenuous at best.

It's worth remembering (briefly) some of the "politics" that went on for the early reviews of this game. Whilst it has no bearing on the devs, it does illuminate that most people knew Tomb Raider in this incarnation was not going to be received well from day one.... without some gentle cajoling of various bits of the media that could be bought for ad revenue and exclusives... The figure "8.5" springs to mind for some reason..... Anyway...

What irks me more than anything is a personal issue. My wife is a big big fan of Tomb Raider, and has bought every single one... She loves, and is very good at these kinds of games...

Occasionally, as wives do, she'll get to a bit that is frustrating and a call for some serious control waggling from her lesser half is sent out... Now normally I saunter over to the PS3 and with a few joystick tricks gleaned from a misspent youth *and* 30 years in the industry playing games I'll mash my way past her problem.... Normally in Laura Croft it's to help her out with the horrible aiming system for weapons.

Not in Underworld's case... Although the weapon control system was dire - as usual.

But no, it was to help with the bits she normally likes.. Climbing around and jumping!

If you have to get one thing right in Tomb Raider it's Laura's controls. However, the collision detection in most inside areas is dire on this game. And the ability to make certain jumps in a water filled room I remember relied on almost pixel perfect accuracy, at an angle where the scene doesn't give particularly good depth queues, and the "uncontrolo-cam" refuses to line up at any time behind Laura.

Even this would be fine (it happens in a lot of games) but Laura spends most of her time acting as if she is drunk, and console controllers are not known for their finely tuned controls. So small movements become a drunken lurch forward at precipices.

I think I spent the best part of an hour trying to make one jump, which anywhere else in the game would have resulted in a hard landing and being able to continue, but here resulted in instant death and having to restart from a fixed point several difficult jumps earlier - and at the beginning of a cut scene you could not skip..

The inconstancies in this whole game about how far you can fall in some scenes and how far you can fall in others very well highlights the problem with your location group splits and apparently no cohesive oversight of those groups.

Oh, and the boat scene is so obviously hacked to pieces it's an embarrassment to be frank. For a game where climbing is key... To NOT be able to climb anywhere, except one key container out of about 50 for a key pathway through the level is frustrating to say the least.. incredibly confusing. and to not even guide the player to this one object you *can* climb, out of the other 100 or so you can't, is a crime in game design.

Perhaps I am missing some nuance.. but isn't that your job to get across on a AAA title?

I thought perhaps it was just the PS3 version, but my little sister bought the Wii version, and when I asked her about it the first thing she said was "Make sure you save *everywhere*"....

As we later found out it chews up saves or forgets about them, or will crash from time to time not having made any autosaves on the PS3 too...

Oh and the fountain thing for a scene finale doesn't work on either the Wii or the PS3.

Another gem my sister mentioned, and we later got bitten by too..

To be honest I have never used such bad language or criticized devs so viciously as when I played this game from time to time over a frustrating week to help my wife get through it.

When compared to previous Laura's, which also had their issues to be fair (that's part of the character of TombRaider games I guess) Underworld is frankly the most disappointing.

Sure it's pretty. But it plays like a dog.

Sorry. But that's the truth. I think you got off lightly! ;)


Jon Alonso
profile image
I bought this game for PC and I really enjoyed it. The graphics were amazing (the Coastal Thailand location is incredible), the gameplay was nice and I did not find major bugs, so I don't understand why this game has come to be considered some kind of failure. I loved Tomb Raider I, Tomb Raider: Legend and Tomb Raider: Underworld. They share the same basic gameplay. Platform jumping and some action through enemy encounters. Maybe it was a good game, but only for Tomb Raider fans.

profile image
I don't remember any pixel perfect jumps, and certainly no 1 hour long of constant trying. There were however some areas where it appeared the way you should go is jump x, but it really is jump y that they intended so I would guess that jump you struggled with wasn't the intended jump even if it was possible to make.

Stephen Northcott
profile image
@FF Although it's not top on my list of "memory moments" I do remember that the place we were trying to get to had a switch that was only accessible that way. We spent a while exploring other options too! I just confirmed that with my wife. :)

Perhaps I am old and crusty... and not as dextrous as I used to be... but my KillZone2 scores don't seem to support that fact! ;)

In any case, as I said in my original reply, it really is the job of the game designers to convey this to the player, not to leave them in such a frustrating quandary. I really am sorry for coming down so hard on this game, but I remember being so frustrated (both for myself and my wife) on so many occasions while this was being played in our home that I made a promise to myself that if ever an opportunity to speak up in a public forum about it came about I would do so - vociferously! I think Eric's ears would burn if he knew some of the convoluted and quite obscene names I came up with for them while I was playing Underworld!

Underworld had great promise and did look great visually. I think it was ruined by the team being over-ambitious perhaps. The later downloadable content, and the overall length (or lack of it) in the original release tends to suggest that a lot more was "cut" than is discussed in this article.

At the end of the day if the core components of a climbing / jumping game are glitchy or hard to control (and there are a wealth of reviews out there that bear that opinion out) then something is wrong. That is something so core to the game that it should be the primary focus of the team until it is perfect.

Compare Underworld to Assasin's Creed or Infamous, or any other game with environment interaction, and it's clear they come from different worlds in terms of usability.

It's a shame, that's all, and I think we've all grown accustomed to higher overall standards from AAA titles.

Ruslan Shestopalyuk
profile image
It's sad to see "refactoring" as one of the negative things here, especially since the described situation ("taking apart the engine and putting it back together in such a way that it became unplayable for the duration") has actually nothing to do with the refactoring in the classical understanding.

The whole point of the refactoring is to keep the useful software properties intact from the end user perspective, while improving the internal code quality. It should be done continuously, and these useful properties should have a regression testing coverage.

What happened in this particular case, sounds rather like certain engineers using "refactoring" as a buzzword to lure management into allowing them rewriting the part of the engine from scratch... which sometimes may be a good idea as well, but again: not in the way that it would stop the production.

Emanuele D'Arrigo
profile image
"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."

Hmmmm.... having in mind the IGDA's quality of life white paper (*) and its findings that many professionals in the game industry see themselves -out- of the industry in 10 years due to its unsustainable working conditions, it kind of makes me wonder if this isn't one of those cases. It makes me wonder if the quoted statement isn't exactly the representation of the industry's attitude: can't do anything about it, it's not our fault, it's not our responsibility.