What Went Wrong

1. Slow to get up to speed.

When we first started developing ideas for Uncharted, we explored a lot of different directions. Although we always knew that we wanted to make a third-person character-action game set in a load-free world, the rest of the gameplay, story, and settings changed a lot in our early discussions.

For a variety of reasons, it took us a while to settle on the final concept of the game. And, because we were very focused on creating technology in the early part of the project -- the engine, the rendering pipeline, and tools -- we didn't have the programming support to prototype our gameplay ideas.

This slow start put a dent in the team's morale, but once we focused the design, communicated it to the team, and began implementing against it, everyone's spirits lifted and we began to move forward with great speed.

For our next project we're making sure to keep the team well informed as the game's story ideas firm up, and to get people working on the realization of those ideas as quickly as we can.

2. Tools rethink at the halfway mark.

Partly driven by a desire to share technology, we developed all-new tools for Uncharted, including a new asset-management system, our first GUI build tool, and a shader and material editor. But in June of 2006, about halfway through the game's development cycle, the team faced a big crisis. Creating our first E3 teaser trailer exposed numerous problems with our new tools, and people were very frustrated.

We realized that we'd bitten off too much with our tools approach -- we'd tried to be too clever, coming up with convoluted approaches that were intended to solve every last problem that anyone had ever had with each kind of tool. To make it worse, we'd gotten distracted by our lofty aspirations, and had left it very late to implement a build pipeline that let people actually run and play levels.

To solve these problems we moved back toward our familiar Jak and Daxter method of doing things for many of the tools. From then on things got better and better, and we began to get really good traction on building out the game.

The moral that we took away was that even though it's good to aim high with your tools, you should choose your battles, and shouldn't try to solve every last tools issue that your team faces. In some cases, simple work-arounds are better and free up more time to work on the game itself.

3. Delayed building out the game.

Having held ourselves up by not getting a good build pipeline in place early on, we were then playing catch-up throughout the project. A recurring theme in our postmortem discussions for Uncharted has been that, in many cases, we wished that we'd started building out the game with the simple tools that became available early on, rather than waiting for the technologies or gameplay code we thought we needed to support our sometimes overly complex design or production ideas.

This problem has some similarity to the tools problems we faced -- we set our goals too high, and had to bring ourselves down to earth in order to be able to move forward. For example, we had wanted to use a system of interchangeable body and clothing parts for our enemies in order to get a huge apparent variety of enemies and reinforce the reality of the world. We wanted the player to have the feeling that each enemy character was unique.

The problem was that this held up our whole enemy implementation process. We couldn't start finalizing the enemies until we finally realized we didn't have time to create our parts system, and simply got on with making the enemies that are in the shipped game.

This ties in with one of our prevailing development philosophies at Naughty Dog, which is that getting on with making the game is the best way to make it. It's important to do enough planning, but don't over-plan. You make so many discoveries during implementation that will change the design that it's best to begin implementation as early as possible, to the extent that your tools allow, on any given day.