What Went Wrong

1. Build turnaround time too long. The number one development mistake we made was to create a build process that took longer than a few hours to complete. The build machines generated custom asset loading lists and memory maps for each level. The level was "played" on the NDEV by a bot while instrumented systems sent profile data back to the PC. The data was then analyzed and used to construct an optimal level package.

This means that customers will experience short load times, dense levels, and smooth gameplay -- but the resulting build time was nearly 16 hours for the game's 37 levels and five languages.

This was acceptable early in the project when we were delivering builds two or three times per week and wanted to focus on gameplay features. However, the turnaround time was a painful delay during the final stretch when we needed to respond quickly to minor requests from Nintendo or Gearbox.

We employed two build machines, but we would have come out ahead had we spent another week upfront to further parallelize and optimize the entire process.

2. Submitted too early.

The last few weeks of any project are difficult. The end is close and everyone wants to see the game on the shelves. We've seen a number of projects try to rush this stage and each one has been kicked to the curb by either the publisher or the console manufacturer. Being "bounced" invariably causes delays for the developers as everyone takes an interest in the issues and is distracted by the result.

It might create ill-will within the lot check trenches too, since receiving anything but someone's finished product is bound to be frustrating. But we ignored what we knew from experience when we heard that test turnaround times at Nintendo were getting longer due to the holiday rush.

So we submitted early and entered the bounce-house for a few cycles. Eventually we emerged on the other side with a stamp of approval. But it was more like the nod of consent you'd get from a border guard than the warm hug from your mom after school.

3. Shifted development team before game approved.

Having small development teams means everyone's time is in high demand. We had managed to keep the team intact up until the end of the project, when we made the mistake of ramping down too quickly. As soon as we submitted to Nintendo, we reduced the team size.

The result was that members of the team ended up bouncing between projects towards the end of Brothers in Arms: Double Time as the game came back from submission and required more work. We had to shift resources to make sure we had the coverage we needed, which added to the distraction of submitting and then regaining the staff to respond to results.

We took the gamble and lost here, and the lesson we learned is to give the project lifetime its proper due in all aspects, including submission and staffing.