Sunday, December 21, 2008

Learning about production in pre-production

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.


Chris said...

Great article!

For a graduate project I have begun evaluating whether the earliest stages of concept design would benefit from a structured divergent/convergent thinking process in an effort to further develop ideas that shouldn’t be changed in pre-production/production. What if any formal processes are used in early game design conception?

Many games seem to come along ok in terms of pre-production/development time; yet so many are released lacking a combination of elements that result in a quality and fun experience.

As a non-industry professional it seems the overall package of what a game can be is often missing. When all pieces are in place it seems like the games do well. With popular games like Halo for example, the aesthetics are visually satisfying, the speed of character movements “feel” right, the guns “feel” right, etc. Do these elements not get the attention they need in many games? It seems many of the smaller issues could be attended to during iteration, such as how guns sound or animation/movement speeds. But to develop these smaller elements successfully requires perhaps better development of the fundamental vision for the product? The most successful games make evident a very strong vision for Story and Gameplay or even Gameplay alone. It is apparent that most or all possible elements the user will experience have been given the amount of attention necessary to ensure the appeal of each element. How is this supported? Has it been your experience that while development is iterative the vision is still managed in a waterfall or top-down manner?


Anonymous said...

This would be the ideal way to handle pre-production, but I find that most people have trouble iterating the design and "finding the fun" unless they are presented with polished assets.

For instance, when you're trying to find your alphabet, you present the first pass on an enemy encounter and the feedback you get is typically "it's not polished". Maybe the animation is rough, or the character model is a placeholder, or FX are missing. But you already knew that.

Then once you polish it, they start really looking at it, and you start paying the debt of redoing the work, as you said.

Have you had this experience? Is there any way around it?

Clinton Keith said...

Hi Chris,

Great comments and questions.

>What if any formal processes are used in early game design conception?

These vary widely. It varies between full planning (concept art and documentation) and full prototype/proof-of-concept and everything in between.

>Has it been your experience that while development is iterative the vision is still managed in a waterfall or top-down manner?

That's an interesting way of putting it. Yes, vision can still be largely plan driven in an iterative environment. The main symptom of this is when you see a game in development that has lots of "parts lying around on the garage floor" that will someday come together in the post-alpha vision (they hope). I call these projects "iterative and incremental death marches", not agile.

Another source of the problem you describe in games is a lack of cross-discipline vision in the game. The programmers, level designers, artists, etc, etc have slightly different goals for the game and don't collaborate as much as they should pre-alpha. It leads to a fragmented experience.


Clinton Keith said...

Hi "Anonymous",

>"I find that most people have trouble iterating the design and "finding the fun" unless they are presented with polished assets"

I completely agree and I did a poor job on touching on that in the last paragraph of my post. In level production, in addition to building vocabulary from small to large, you still need to take a stab at a full unpolished level AND a small section of the level that has all the graphic bells and whistles your graphics and pipeline can muster.

Both of these experiments I call "tracer bullets". They are meant to learn more about what the whole will be like when your vocabulary is built up enough.

However, you shouldn't be pressured into firing too broad tracer bullets (e.g. a full level with all possible graphics) unless the cost (including waste) is going to create beneficial knowledge. Most of the time it's not justified unless you are nearing the production date.

I may just revise my post to reflect that. Thanks for pointing that out.