Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Crystal Dynamics' Tomb Raider: Underworld
View All     RSS
September 20, 2019
arrowPress Releases
September 20, 2019
Games Press
View All     RSS

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 Previous Page 2 of 4 Next

4. Metrics

In a game like Tomb Raider: Underworld, where the player can interact with so many different elements of the environment in so many ways, metrics are hugely important. They form the basis of getting Lara Croft off the grid and eliminating the tractor controls that kept her from evolving into the fluidly moving character we have today.

Tomb Raider: Legend suffered from changes in jump distances, ledge parameters, and other metrics until late in development, resulting in countless hours of rework for both designers and artists (it was the most painful for the latter), and we were determined to avoid this in the sequel.

Our lead level and systems designers collaborated to establish metrics for every aspect of player interaction until a full set was defined early in development. Some changes were made later, and holes were discovered and needed to be filled, but on the whole the degree to which we maintained and enforced metrics without major changes was a huge improvement over past efforts. If not for this success, the amount of game real estate we included in the game would have been significantly reduced.

5. Sanity

Most people working on the game had never been on a project this large, in terms of team size, degree of coordinating efforts, and the amount of game assets we had to fit into the timeline. Add to that how passionate and invested such talented people are in the quality of the final game, and the mixture could have been explosive.

Yes, there were differences of opinion, often strong ones, and certainly there was plenty of stress and the occasional meltdown, but the professionalism rate was extremely high, and this had a large positive impact on the production in ways that went far beyond people getting along.

When scope reductions had to be made, when work had to be redone or discarded, or process changes were needed, maturity was high and ego was low. We had no tantrums over trying to cut someone's favorite elements of the game. Everyone remained rational and evenhanded throughout the length of the project, right into the manic bug-fixing days before submission.

Lesser projects with weaker stresses have broken people and teams, and that is why this deserves to be on this list of what went right-because on a project like this, navigating the many and lengthy trials and tribulations intact contributed as much to its ultimate success as any other element.

What Went Wrong

1. Shared Technology

At the start of Tomb Raider: Underworld, Crystal Dynamics as a studio decided to pursue the Holy Grail of internal development: a robust and powerful shared code base to use as a jumping off point for all future games. This proprietary engine would be augmented and maintained by dedicated engineers who could provide the common functionality our games would need, while team programmers could focus on features specific to their games.

The studio believed that because Tomb Raider: Underworld and the shared code base would both be based on Tomb Raider: Legend code, the efforts could be combined even given our tight production timeline.

A lot of talented and hardworking programmers were put on the shared code team, including many of those who engineered Tomb Raider: Legend, so skill was not an issue. The biggest problem here turned out not to be over-ambition or complicated dependencies (though these were certainly issues).

The problems were much more related to ownership and priorities. Within a team, when schedules begin to slip and need to be put back on track, the entire team can get together, redefine its mission, and make whatever collective changes are needed to bring production back into alignment with the calendar.

But the shared technology group was not on the team. While its charter was to serve the teams, it had to serve multiple teams with conflicting needs. From the point of view of each team, the shared technology group was a cadre of programmers that didn't report to our lead engineer. It was an enormous dependency that we could only influence via petition and persuasion, and frequently could not even schedule around as we had limited visibility into their progress.

We knew from the beginning that basing Tomb Raider: Underworld on a nascent and evolving code base was an enormous risk, a big potential pitfall. So why did we walk into this trap with our eyes wide open? At the time, it seemed that the potential payoff was worth the risk, and that we had the right people working on the problem, so we marched along with the shared technology group and did the best we could knowing that some of the challenges we were facing could ultimately yield more efficiencies down the road.

Ultimately, however, some of our fears were realized as we had indeed overestimated our ability to overcome all the known risks.

Article Start Previous Page 2 of 4 Next

Related Jobs

HB Studios
HB Studios — Lunenburg/Halifax, Nova Scotia, Canada

Experienced Software Engineer
University of Exeter
University of Exeter — Exeter, England, United Kingdom

Serious Games Developer
innogames — Hamburg, Germany

PHP Developer - Tribal Wars
Insomniac Games
Insomniac Games — Burbank, California, United States

Sr. Project Manager

Loading Comments

loader image