Have you every been on a project with a date scheduled that says "Start production"? This is the date when the team transitions from pre-production to production and a ton of people (internal or outsourced) join the team to create the 10+ hours of gameplay to ship? The idea is that the team knows what's fun about the game and can build a ton of assets in parallel.
Did that deadline really work out? Was the team really ready to "go into production"? Most aren't!
The main goal of pre-production is to build knowledge, or learn about the game. We want to know how fun our game is, how we are going to make it and how much it is going to cost. Building this knowledge requires iterating on the areas where we lack knowledge. We choose what to work on based on a priority of the knowledge we want to build. For example, we’ll iterate on the core mechanics first because the provide the greatest knowledge of the value they provide to the game. We’ll also iterate on building characters and levels to learn how much effort and cost is required to make many more of them in production.
We often focus more on learning about the core mechanics, or the fun of the game, and not enough on how we are going to make it. This results in many projects exceeding their production budgets or schedules. What we need to do is to learn the cost of building assets during pre-production as well as learning about how fun the game is going to be. Both of these go hand-in-hand since we can’t determine the cost of production assets until we know what makes levels fun.
Let’s look at level production. Level production can easily require 50%-75% of the production budget. We need to refine our understanding of the effort to build levels during pre-production so that we do not build mechanics which inflate production costs beyond our budget. For example, a fantastic feature for the consumer would be a mechanic that allowed every object in the environment to be destructible. However implementing this may also double the effort to create levels since building destructible geometry everywhere requires far more effort. By knowing these cost implications, the Product Owner (PO) can better judge the value of adding this feature or not.
Learning about production cost is an iterative process. We begin with a range of estimates based on existing knowledge (perhaps from a previous title) and iteratively refine these estimates during pre-production. As we move forward in pre-production, we are building a vocabulary. At first we are establishing the alphabet. This may be the second-to-second game-play experiences such as battling one enemy character. We then start building words from our alphabet. These are the 10-60 second loops of gameplay, perhaps dispatching a wave of AI characters in a room. From here we build sentences, then paragraphs and chapters of larger loops of game-play.
We follow this same pattern in building levels. We don’t start by building an entire level until we build a vocabulary of rooms. We may build several different types of rooms with different experiences (e.g. lots of AI in a plain room followed by a boss in an ornate room). We don’t wait until our room vocabulary is final before we start building our level vocabulary. Building a shippable level before we have a minimum room vocabulary will waste a lot of time. This waste is seen on many milestone driven projects. Teams feel compelled to show a level of polish to their publisher when the gameplay is still undetermined. These polished milestone levels end up as either waste or debt; They are eventually thrown out or require a great deal of rework when the team learns more about the game-play.
Firing tracer rounds
Sometimes it’s valuable to demonstrate a 20 minute experience with a quick and dirty level filled with stand-in assets to build knowledge of our level goals. This in turn may influence the lower levels of our vocabulary. Another valuable test would be to create a single room with as much graphics polish as your engine can muster to help refine our visual DNA and target. Although these assets may be thrown away, their cost is easily worth the knowledge they create for your project and customer. The key is to not waste more effort than the knowledge is worth.
The PO is responsible for ROI
Since the PO owns the return-on-investment for the project, they need to demand that the team demonstrate improved knowledge of production costs refined through pre-production iterations. They do this through separate stories or conditions of satisfaction on existing stories. An example is “demonstrate the cost (in actual hours) to create the X level”.
The last pre-production release should have a level or two which demonstrates the major range of vocabulary at potentially shippable quality. This is the only way the team can demonstrate that the knowledge of production costs have been learned.