4. No long range development plan at the start.

The overall development effort "went right," but from a scheduling and planning perspective, the development production staff got lucky. This project was fueled by excitement about bringing the Brothers in Arms property to the Wii. The pre-production technical due diligence was in the spirit of "relax, everything will be juuuuust fiiiiiine."

There was never an itemized list of the technical hurdles that the team would need to overcome. It's almost as if we were lulled into complacency by the cute white controller and that mustachioed muscleman in yellow at WarioWorld.com.

After a couple of months, when the engineering team was staffed up to full strength, the scope of what was required on the optimization front became clearer. At that point, rescheduling to accommodate optimization is more art than science.

A team can make huge strides in a short amount of time while that last little bit of performance to bring the game up from 27 to 30 FPS could require major changes. We managed to work through a host of platform specific and optimization complications: a byte-swapped platform, slow IO connection between the PC and NDEV, an elf that was 4x too large, excessive (and minor) memory allocations, a new and untested rendering pipeline, slow physics/ragdoll simulation, in-game IO hitches, and a seemingly endless stream of miscellaneous framerate hits.

In the end, the consensus was that we could have done more pre-production planning or risk assessment to better set expectations with our publisher.

5. Made design decisions too late in development.

The Wii controls have such flexibility that you have to be careful not to overdo it. You don't want the players to need to do acrobatics in order to succeed -- unless, of course, you're making an acrobat game. 

From the first day of the project, we were brimming with ideas on how to use controls, the UI, and all the features that separate Wii from other platforms. In fact, we couldn't turn off the ideas. We didn't set a feature lockdown date, and as a result we were still tweaking the control scheme long after we should have. This left a lot of pieces feeling chaotic and unfinished right down to the wire. 

The user tests ultimately helped us finalize; however, we started them too late in development, so all of the best data was arriving late to the party. User testing was not planned from the beginning of the project, but rather was a thankful realization that we needed clean, external input in order to settle on a well-informed decision.

The lesson there was to plan user testing from the start so that there are set periods earlier in the process where the team is prepared to show the game and react to the feedback.

Without setting a firm lockdown date, we allowed the user testing and subsequent tweaks to continue too long. The realization that a variety of play styles would be better captured for players in two separate control schemes was positive, but it came with a cost. We had to scramble at the end to get UI, balance, and all of the other items that hinge on the controls updated and finished.

Had we properly set a feature lockdown date, we would have been forced to conduct user tests earlier, secure the control scheme earlier, and then take the proper amount of time to get the UI and balancing worked out to each control scheme. Once again, we succeed because our talented team pulled through.

Conclusion

We were so excited to work on Brothers in Arms: Double Time that we stepped into the ring on a wing and a prayer. We managed to emerge successful because of a talented team that happened on the right decisions at the right times.

The project brought great things to our studio, like the Scrum development process and tech we can use for all of our future Wii titles. Beyond the studio growth that came with Brothers in Arms: Double Time, it was exciting for Demiurge to land on a new platform when the platform itself was still reasonably new.

Game Data

Developer: Gearbox / Demiurge

Publisher: Ubisoft

Platform: Wii

Release Date: September 2008

Development Time: 13 months

Peak Development Team Size: 15