The prospect of building new next-generation tech on multiple consoles at the start of the Brütal Legend development cycle was a daunting endeavor for us to consider, and neither the practice of Scrum nor our own ambition would allow us to write every system necessary for the game.
We recognized the advantages of middleware use early in the game's development. Selecting the right middleware to integrate allowed us to get the game off the ground early and facilitated the rapid testing of new ideas.
This advantage allowed us to make strong demos at the start of our development cycle, which helped communicate our game concepts to potential publishers when pitching the game, and also to present strong milestones during pre-production when publisher expectations for deliverables were more forgiving.
Double Fine used middleware for audio (FMOD), physics (Havok), user interface (Scaleform), lip sync (Annosoft -- tools and offline), and video (Bink).
Though there were some false starts with other middleware packages, the decision to distribute the development risk across commercially available software packages was sound, and the call to integrate those packages early in development paid dividends throughout the development life cycle.
As beneficial as it was to rely on commercial software for various systems, Double Fine's batting average for selecting appropriate middleware was .500. We ended up selecting and integrating a number of middleware software packages, and then later discarding them because they no longer served our needs as the project evolved. The middleware with which we ultimately shipped still demanded a tremendous investment in its integration, requiring far more staff than we had to handle the emerging stability and performance issues.
We were informed by multiple middleware companies that we were uncovering bugs and failures in the software that had not been found previously due to our placing new demands on their systems. That news was both flattering and unnerving, and ultimately costly to manage during stressful development periods. It was a tremendous relief to have the kind of tech support that we did from the individual middleware companies -- without their timely attention and desire to collaborate on our title, we would not have shipped the game at all.
While we already know we plan to continue to use certain middleware packages in future projects, we will be committing to the use of others much later on in the development cycle or writing our own software that specifically meets our needs. The wasted time spent integrating inappropriate or unusable middleware into our codebase, then reintegrating others or rolling out our own solutions, absorbed a tremendous amount of engineering time and effort, as did supporting and debugging the middleware we ultimately did elect to use through Brütal Legend's release.
2. 11th Hour Tools
From the start of development, we recognized that good tools needed to be a priority to ensure faster iteration times for our team. A mix of legacy team structure, intrinsic complexity, insufficient input from content creation leadership, poor planning, and bad luck all contributed to a significant delay in the delivery of several critical tools to the team -- delays which jeopardized milestone deliveries, reduced artist productivity, and required unplanned emergency intervention at the expense of other engineering efforts.
Unfortunately, we seriously underestimated what it would take to get from our brightly colored Xbox Psychonauts graphics to the rich, highly-detailed lushness of our Xbox 360 and PlayStation 3 Brütal Legend graphics.
First, in an attempt to address the lack of dedicated tools programmers we experienced on Psychonauts, we created a tools group within Brütal Legend's engineering team, and staffed it with four engineers. While this was an improvement over Psychonauts, the problem with this approach was that it facilitated the separation of tools work from the rest of the engineering effort, isolating the accessibility of the tools to the user from the process of delivering features for the game.
Often, this separation created inefficiencies in implementation, or a mismatch between the tools design and the runtime feature it supported -- in several cases, this disconnect even led to sprints where a runtime team would complete an artist-facing feature without any tools support for it at all, making that feature (often a milestone deliverable to demonstrate) unusable.
A second critical mistake involved effective tools prioritization. Without strong guidance from content creation, the tools team focused initially on back end services such as tools deployment and build infrastructure, with the intent that these services would serve as a productivity multiplier on future tools development. Unfortunately, without any tools to distribute or code to build, these initial investments significantly delayed the development of content/game-facing tools.
Later on, we struggled to find the right balance between meeting short term needs and building tools that could scale to a full production environment. A prime example of the effect of this ineffective prioritization was the one year deployment delay of our MUE (Multi-User-Editor). An MUE would be a massive undertaking under any circumstances, but in our case the effort was made even more difficult by a late start and a rocky path from the quick and dirty short-term to the production-ready real version of the tool.
Then there was some bad luck. We decided to be an early adopter of a COLLADA-based Maya exporter pipeline. Initially, we underestimated how long it would take to implement a COLLADA 1.3-compliant parser. Then, when COLLADA 1.4 required a massive change to our schema, we had to significantly rewrite our parser.
Once it was finally functional, we were faced with ongoing maintenance or unexpected limitations, and ultimately failed to recognize any of the expected upsides, like easy interoperability or enhanced leverage of a tool or pipeline utility. On a lighter note, as a result the word "COLLADA" became a swear word and elicitor of groans at Double Fine Scrum meetings. In retrospect, at least it provided us with humor.
In hindsight, we should have created a programming team structure that enabled the creation of good tools alongside the development of runtime features, perhaps even allocating a larger percentage of the engineering team to tools early in development.
Moving forward, we intend to build our tools starting with the most client-facing work first, then iteratively improve them to meet the needs of the content creators. We also intend to de-emphasize technology investments that promise to yield large theoretical future benefits in favor of investments that speak to present needs.