Oct 9, 2018

The case for robust pre-production

Game development is always a time consuming and expensive endeavor – even if you are a scrappy indie you are losing a ton of money in terms of opportunity cost: you could be working a steady day job for a salary. It is common for Indies and AAA game studios to embark into a long 24+ month development cycle and realize midway that something doesn’t feel right.  Maybe the initial concept is just not that fun, maybe management realized that the target market is too narrow to make economic sense to continue development, or maybe the team is not well matched to the scope of the game. Regardless of the cause, producers have a responsibility to their team and backers to pull the plug early.

The AAA studio case: [Insert big name publisher here] greenlights your project based on a new pitch and funds your development team. The small core team triples in size with tons of specialized art, engineers and designers. Some of them move across the country with their families. However, midway through production, it’s evident something it’s not working. The publisher and the production lead meet and a decision is made to terminate the project. Now, it’s your job, as lead producer, to fire dozens of hard-working individuals you recently hired, at worst you might also need to close down the studio.

The Indie developer case: You finally decide to plunge into game development and have prudently set aside a year of savings to dedicate to build THE GAME of your dreams. You create your Game Development Document (GDD), as everyone says you should, and keep adding to it while you code more and more features to realize your vision. After one year it’s obvious the game still feels incomplete, many features are only half implemented and you know that you would need several more years to get it to a shippable state. Now, without any savings left, you have to search for a day job while feeling depressed that you could not bring your vision to the market

Both of the above cases would have benefited from more pre-production work to refine the concept and set up a flexible and achievable production plan. Why? Pre-production costs are cheaper, and its less painful to iterate or pivot.

• The team during pre-production its much smaller: this dramatically reduces the cash burn rate (time until the cash runs out), thus increasing the time available to iterate on design and concept when the stakes are low, which in turns means that any game that its greenlighted is more likely to be fun and commercially viable. As an example, Blizzard’s Hearthstone team was only 15 members until the end of closed beta, but at a certain point, it was only two designers iterating and playing around. Blizzard’s executives credit much of the final game to a flash prototype created by the designers during this phase. The core team started meeting around June 2008, the game started production in spring 2012 and was released in March 2014, four years of pre-production!
• The team has time to refine the project plan and understand “production debt”: By the end of pre-production, the team should have a good grasp on what are the core mechanics and what it takes to implement it. Past knowledge allows the team to do a realistic estimate of how much effort will be needed to realize every feature and X hours of gameplay, and thus adjust scope accordingly.

Revisiting the previous examples:

The AAA studio case: the game studio can afford several small pre-production teams that are working on parallel in new game ideas. Pre-production is time-boxed to a fixed number of sprints, and every team is reviewed regularly by upper management. The review board can decide to pull the plug, give more time in pre-production, or green light production. Depending on the studio business model, production resources can join as they wind up production of another game or be contracted for a fixed amount of time. Production is time-boxed, and the lead producer makes sure to adjust the scope so by the end of production the game feels complete. This system allows the teams to fail early without much impact on the studio and increases the likelihood of success for titles that emerge from pre-production.

The Indie developer case: before quitting work you spend a month looking at different ideas of what you want to make, evaluate the potential market for each game idea and prototype some game mechanics. You select one of the ideas, create a list of cool features and do a rough estimate on how much it should take. You can then take leave to build a first playable prototype with a few key features that you can show around. Based on the feedback and your backlog estimates you can decide whether to pursue this idea further (go full indie) or just archive the prototype in your portfolio and try again later.

If pre-production time is so good why most developers cut it short?

Two reasons mostly:

• How can a studio handle the downtime between a project finishing production and another starting?
• How can any developer, indie or studios, make sure pre-production time is well employed?

The first problem is the focus of a great video by the Extra Credits crew: The Pre-Production Problem – How to Improve the Planning Process in Game Design (https://www.youtube.com/watch?v=ukADFPuscG8). In this video, the extra credits team argues that pre-production has the unfortunate side effect of hurting programmers and killing productivity and makes a case for the game industry to adopt the Pixar’s model of having several concurrent pre-production teams, ready to ramp into production as soon as production winds down in another project. I would only add to the problem analysis that the pre-production downtime issue not only impacts programmers, (what will the AI expert do while waiting for new production to start?) but artists as well (what will the 3D rigger do while waiting for new production to start?).

The second problem is also briefly touched in the Extra Credits view: for many developers, pre-production feels like it is not real work. Unstructured planning feels like a vacation if not timeboxed and most people have a hard time focusing without any urgent deadline. Such a scenarion can go one of two ways: the pre-production team might not do much or might get into a brainstorming loop whereby they keep adding to the concept way past the point where they should have started prototyping –This last pitfall is common to new developers (students or indies).

The solution to the productivity problem is simple: time box it. Start pre-production by setting deadlines for the concept and prototype, and use them as checkpoints. If you are a solo indie, find a mentor or friend that you can trust to show your concept and commit to moving forward if you receive positive feedback. In the case of a studio, the producer should schedule a meeting with upper management to review progress as soon as the team is established. Set deadlines and commit to them.  Develop using sprints and present your prototype at the deadline you established.

There are no clear-cut solutions to the first problem. However, I favor the idea of rotating teams in large AAA studios (a la Pixar) and following the film industry model of keeping the core team small and contract/outsource some of the work during production in smaller studios. Large studios can easily afford to have several small pre-production teams and at least one big production team going. The economics of smaller studios are very different, and they only have one development team. It doesn’t make sense for non-AAA studios to keep highly specialized programmers and artists in the payroll when outside of production.

Historically, the game industry has preferred to hire outright instead of contracting, as conventional wisdom says that tightly knit groups are better for the chaotic nature of game development. However, the conditions seem ripe for a move to contracting, the industry clustering around certain cities seems to favor the formation of specialized contractor agencies, where a small pool of highly specialized programmers and artists could move from company to company as needed. In that system, AA and smaller developers could hire top talent for a few months, and the experts would be highly rewarded for their particular skills.

Vertical slice prototype as the natural end of pre-production

The best way to evaluate if a game is fun to play it, simple. Therefore, the natural end of pre-production is to produce a first playable that is representative of what the game will be, but with the understanding that it is it not feature complete and will likely change during production.

I would highly recommend that the team follows an agile methodology during pre-production, as it pushes the team to have a “complete” build at the end of each sprint. Therefore, the team is always ready to present a non-buggy playable in case the deadline or scope changes.

As a side note, there is a lot of debate on what constitutes a demo, a first playable, a prototype, and a vertical slice. For our purposes let’s avoid that discussion, and agree that whether you are an Indie or a studio, the final milestone of any pre-production plan is to demonstrate your game and validate if the game “works”.

Conclusion

Pre-production, when well-planned from the outset greatly improves the likelihood of success for your game project, and it is usually the difference between studio bankruptcy and commercial success.

As a game producer, your job in pre-production is to provide direction and make sure the core team it’s motivated and focused. The pre-production plan should be time-boxed, especially the initial concept phase, and form a logical path to the creation of a first prototype. The review of a pre-production prototype is an important milestone for any project, and the feedback received should inform your decision to continue production – and assume all the costs attached – or archive the prototype and move on to a new project. A few months of pre-production can save you much frustration and money in the long run.