In-Depth: Inside The Making Of Tomb Raider: Underworld

Author: by Staff

The latest issue of Gamasutra sister publication Game Developer magazine includes a postmortem of Crystal Dynamics' Tomb Raider: Underworld, written by the game's creative director Eric Lindstrom. As custodian of the Tomb Raider series since 2003, Redwood City-based developer Crystal Dynamics initially planned Underworld as "an 'easy' sequel" to Tomb Raider: Legend, but as Lindstrom points out, "it never quite works out that way." The following excerpts from Game Developer magazine's recent postmortem, published in the June/July 2009 issue, illustrate how Crystal Dynamics overcome a number of significant obstacles along the way to realizing the dark adventure. As Lindstrom explained, "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." The Necessity Of Focus It can be all too easy to make a nearly-carbon-copy sequel, but by maintaining a strong sense of focus, Crystal Dynamics managed to avoid that pitfall, as they explain in this extract: "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." Pros, Cons Of Shared Technology Prior to Underworld's completion, publisher and parent company Eidos trumpeted its decision to make use of a shared code base between multiple internal teams. However, as Lindstrom explains, the team responsible for the shared technology wasn't directly accountable to any one team that relied on it: "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." Acts of God Any developer knows that sometimes things go wrong that can't be blamed on anybody's poor decision -- they just happen. As Lindstrom puts it, that's what separates "What We Did Wrong" from "What Went Wrong." Crystal Dynamics faced some of these "What Went Wrong" moments: "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." Additional Info The full postmortem for Tomb Raider: Underworld explores "What Went Right" and "What Went Wrong" during the course of the game's development, and is now available in the June/July 2009 issue of Game Developer magazine. The issue also includes the annual Top 50 Developers ranking; a piece on single-shard MMO games by the team behind EVE Online; a story on how to keep players completing your game by Microsoft's Bruce Phillips; and much more. Worldwide paper-based subscriptions to Game Developer magazine are currently available at the official magazine website, and the Game Developer Digital version of the issue is also now available, with the site offering six months' and a year's subscriptions, alongside access to back issues and PDF downloads of all issues, all for a reduced price. There is now also an opportunity to buy the digital version of June/July 2009's edition as a single issue.