3. Created reusable Wii technology.

At the beginning of development, we identified the creation of reusable Wii technology as a long-term engineering goal of this project -- but we wanted to do so while still emphasizing the need to deliver a high quality Brothers in Arms experience for the player. Beyond the typical issues that arise from developing for a new platform, early in the development cycle we identified optimization as a major challenge in creating an engine with flexibility enough for a variety of game types.

Our goal was to ensure that not only would Brothers in Arms run well and look good, but any future projects that used our engine would not need to spend significant amounts of time on optimization.

By emphasizing the long-term goal of reusability and the short term goal of shipping a high quality product from the outset, we were able to focus our efforts in the right places. The result was an engine that delivers a visually compelling Wii title with technology flexible enough to be used by Demiurge in future Wii projects.

4. Scrum and constant planning saved time.

During development for Brothers in Arms: Double Time, the project management methodology of Scrum and Agile Development was beginning to take hold of the game industry. After researching it internally, we elected to give it a small trial run.

We began using Scrum toward the end of the project to systematically tackle the close-out of the project rather than solely in the development cycle. Members of the team would take on classes of bugs during a sprint. The goal was to have each system online and bug-free at the end of the sprint. This, coupled with a strong engineering team, allowed us to complete the project without crunching. 

Since working with the Wii involved a lot of new technology challenges, we planned hard from the start of the project through zero-bugs, revising and planning even more aggressively as we entered the bug fixing and optimization periods of the project. At the end of the project, we posted a large bug fix chart that constantly reflected how we were closing down.

This kept everyone on the team aware of how we were tracking toward our goal and instilled some competition for how quickly we could optimize and fix issues. We also began tracking data as to how the team was progressing so that in future projects, the pre-production planning could be robust from the get-go.

We found Scrum to be very successful in allowing us to "plan" initial bug-fixing so that we had achievable goals that were within our timeline and owned by the team. It also allowed us to adequately think out all the problems before digging in and tackling them one by one. We've since used the Scrum methodology for all of our projects with increasing success. 

5. Support and resources from Nintendo of America.

Double Time was the first Wii title to be developed at Demiurge Studios, so there was some ramp up time to get familiar with the platform. We were working on this title long enough and early enough in the platform lifecycle to see an evolution in the SDK, the profiling tools, and the lot check requirements.

In short, the learning never stopped. While Nintendo cannot do the work for you, we found the documentation and web resources very helpful. In particular, the newsgroups are an excellent source of knowledge. Someone somewhere has had the same problem you're having and they've asked about it on the newsgroup.

The response time to questions from Nintendo of America was usually within an hour or so. It seemed as though the family friendliness of the Wii console also existed in the developer support arena.