This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
[Turn 10 Studios development manager Adent tackles the topic of how the team moved to a goal of having an always-working build for Forza Motorsport 3, how that goal was achieved, and what it meant for the development of the game -- and team motivation.]
As programmers in the games industry we are often called upon to develop technology that enables creative experiences and yet we are asked to do it with limited resources and on firm deadlines. At Turn 10, after releasing our award winning Forza Motorsport 2 in 2007, our team set out on a mission to develop an epic AAA title that was characterized by creative iteration, yet do so in such a way that enabled predictable project planning.
How many postmortems have we all read or participated in where good engineering and development practices were abandoned because of an aggressive schedule?
I am not talking about cases where programmers did not have the time to architect their ultimate game subsystem because of schedule pressure -- but rather cases where we dropped fundamental practices of estimation, design, review or validation of work because it was deemed too expensive.
While one might think that the engineering team is unable to maintain these critical practices because of the pressure applied by producers or publishers, the interesting part that I tend to find is that it is often we, the software engineers, who will abandon or refuse to initiate these habits because we are so passionate about delivering the biggest and most feature-rich game possible.
However, in the end, we end up hindering our own development bandwidth and crippling the creative iteration ability of designers and artists because we have not provided a stable or predictable set of technologies.
When undertaking the vision Turn 10 had for Forza Motorsport 3, a vision that included massive expansions in graphics fidelity, content, gameplay and user-generated content (UGC), along with a complete new look and feel, it was critical that we develop our game technologies in such a way that allowed for predictable project planning and still enabled iteration and creative development.
I vividly recall sitting in our programming team postmortem for Forza Motorsport 2. At that time, I committed to myself that we would hold to a set of key pillars, pillars that we would establish and not abandon when the feature cuts came. These pillars would become a part of our software development and studio culture.
Most importantly, these pillars had a goal and that goal was to enable a studio culture of creative iteration. Cultural change is always difficult and takes time, however, we were committed to these pillars and regularly articulated this commitment to the team until it became a part of our DNA.
Fast forward nine months: our pillars were in place and a part of our software development culture, and they were having their intended effect of enabling creative iteration. Additionally, these pillars were having unintended effects of increasing development bandwidth and technology iteration.
In May of 2008, we were conducting our greenlight with Microsoft Game Studios (MGS) executives and committing to a shipping date some 15 months in the future -- a date that we delivered on to the day. In this article, I would like to share with you the pillars that we put in place as a programming team that significantly helped us to deliver Forza Motorsport 3 on time and with a quality of which we are very proud.
Having a build that is always playable may be common sense, but I tend to find that it is not often a common practice. In fact, many projects that I have been a part of will lose the playability of the build soon into production, only to restore it late in the schedule when teams are desperately looking for that spark around the core of the game that builds the excitement and momentum of the team.
Perhaps some of the subtlety here lies in what we defined as a "playable build". At Turn 10, a playable build is one that contains all the necessary core subsystems, functioning together to allow the game to launch, navigate into a race experience, complete the race and return to the out-of-race experience, and being able to do this from the planned distribution media (the DVD).
This is more than the typical vertical slice which will often take shortcuts around systems like memory, streaming from the DVD, resource management, user profiles and so forth. For those developing with a mature game engine, this may not be as significant of an issue; however, for newer projects or when going through a platform migration, this very important step can often be overlooked.
While primarily ensured by the software engineers, maintaining a fully playable build requires the cooperation and coordination of the entire studio. Our test team will validate the playability and functionality in the game each day. Designers, artists, audio designers and programmers must take steps to ensure the continued playability with each feature or piece of content that is placed in the game.
It is amazing how design, art and technology iteration is enabled when there is no question that the game is going to be playable each day and that all content in the game is usable. This also has significant positive impact on the quality of work estimates when the game is fully playable and can be used while developing the estimates for work as well as implementing the features.