2. Pre-production time.

Armed with our demo, we set about trying to plan the game. It was the beginning of 2006, and we had 10 months to get ourselves ready for production, which would begin in earnest when Resistance shipped and the full team joined us.

We still had a lot of unanswered questions; What would Ratchet look like on PS3? How would we animate characters that were four to 10 times more complex than the previous generation? What constituted a "level?" How big was the game going to be, and how would we make it all work?

To start, we established the overarching goal of creating one fully-realized and playable level. Hopefully, this would give us two valuable pieces of information; first, an understanding of everything needed to get our game up and running, and second, a set of benchmarks to plan the content for the rest of the game.

We also had three distinct production paths that we needed to keep aligned -- asset creation, gameplay prototyping and implementation, and game design. To keep things organized, we set a series of escalating milestones. These included first prototype, first functional, and first playable builds that would eventually lead to a completed level.

Our milestones were shared across the entire team so that we maintained unified production goals. In between, we divided specific assignments into one- to three-week blocks to keep the workload comprehensible to the members of our team. We met our goals, but wound up overshooting in terms of our design scope. See "what went wrong" for more on this.

3. Balancing creativity and deadlines.

After our PS3 launch title Resistance had successfully shipped, our 15-person preproduction team began to swell to more than 100 people (70 full time and numerous "shared" resources). To carry out our game design, we needed to keep the entire team productive from day one.

As much as possible, we needed a stable production environment with a constant flow of game code and game assets ready for whoever needed it next. Time was our biggest enemy and we needed to do whatever possible to use it wisely.

We attempted to establish a production structure that rationalized the complexity and scope of our game but also gave everybody working on the project flexibility. One of the tenets of Insomniac's culture is to allow creative contribution and control at all levels, and we had to balance this with another Insomniac truth -- we never miss a deadline.

Within our major milestones we established production cycles, eight-week blocks of time where our various teams created components of the game. At the end of each cycle, these pieces were brought together, often resulting in a play test, media presentation, or both. During the project, we were able to establish and track progress according to these recurring cycles while individuals or teams could fit their unique workflows into a cycle.

At the same time we learned that creating functional gameplay rather than finished components not only accelerated progress but embraced iteration and change along the way. On past Insomniac productions we often tried to take features to completion before moving on, which complicated the inevitable changes and added unnecessary work.

As production intensified, we adopted additional strategies to keep up our momentum. Early on we instituted "Friday walkarounds." This was where the creative director and project manager would visit each production department (art, animation, design, gameplay, etc.) to see work in progress or evaluate completed assignments.

We tried to keep this casual -- usually we would view work at its creator's desk. However, by sticking to a regularly-scheduled routine we built a formal evaluation structure that focused the team on weekly, self-determined progress. Later, as the game was taking shape, we held Monday morning "war room" sessions where our designers and programmers would report the status of the game and what lay ahead for the coming week.

Again, this took place in an informal setting, but ended up being the other bookend to our Friday walkarounds that organized RCF production into discreet one-week segments. Still later, we added a "Daily Load Test" report that our Q/A team sent out to everybody working on the project. This was a simple test that reported if a level would load, if it could be completed, and what issues stood in the way.

It came at the time during the project where maintaining stability on a daily, or even hourly basis was essential, and gave everybody an accurate way to understand the most critical issues.