Stage 2: Pre-Production

Stage 2: Pre-Production

With a clear, high-level set of ideas in hand, you're ready to expand the team and start putting meat on the conceptual bones for the game. During pre-production you'll take the overall game concept, iterate on it in more detail to create the design, create an actual playable demo of the game, and prepare for full-scale production in the next stage. The ultimate goal of this stage is twofold: first, to produce a small but playable version of the game that demonstrates the eventual game experience; and second, to provide enough design, art, and technical detail that no huge questions are left hanging at the start of production. Be careful to give this stage the time it deserves. As shown in Figure 4.1.1 you can expect that an effective pre-production stage will take up to 25 to 30% of the overall time allotted for the project, or up to about six or seven months on a two-year project.

Figure 4.1.1: The stages of game development and the approximate duration of each.

Participants

This stage of development is led primarily by the game designer and producer. However, during pre-production you should start adding to the leadership of the team and begin getting contributions from the technical lead, art lead, quality assurance, and in some cases specialized leadership for areas such as sound and music, 3D, database, or server technology. You might also want to add some assistants in areas such as production or design, but be careful to build the team from the top down (or center outward)—you want to encourage bonds between those who will lead the effort for the rest of the development process, and to make sure they understand the game's focus and progress better than anyone else. It's probably going to take time for you to find the right people to add as leaders on the project and for them to come up to speed, but in the meantime, the designer and producer should be working on their pre-production deliverables.

Process

The main point of pre-production is to take the initial concept and build it up. You and your team need to understand what is going to be needed to implement the game, and those outside your team need to understand (and believe in) what you're developing. The first and main part of this is what [Cerny02] calls "macro design." This involves fleshing out the original idea, focusing first on the game systems that will be required, and eventually working down to the details ("micro design") of individual characters, opponents, objects, levels, and player actions. Macro design also includes creating fast, non-functional mockups and working prototypes to demonstrate gameplay, camera, and user interface designs, as well as setting the art and sound style direction. These mockups and prototypes are a great way to try out ideas quickly within the team, report progress to management or publisher, and to get early player feedback (looking for comprehension and interest).

Creating the design, mockups, prototypes, and early art begins a process of convergent iteration that lasts throughout pre-production and production. Convergent iteration is based on the spiral model of software development [Boehm88] and a number of different rapid development models [McConnell96]. As shown in Figure 4.1.2, you're going to iterate on the main ideas in your game during pre-production, defining them, designing them, implementing prototypes, and evaluating them (and having a few players do so). You will start over this time using what you've learned to converge on your goal. The idea in game development is to start with a general concept and hone in on an optimal mix of fun and feasibility. By taking the time to do up-front conceptual and pre-production design work, you cover a lot of ground quickly and cheaply, and spend the rest of the project fine-tuning your solution rather than casting about late in development, hoping to find something in it that's fun.

Figure 4.1.2: The process of convergent iteration shown over the stages of game development. Note that the upward strokes are define—design—implement, while the downward strokes are evaluation phases. The number of phases shown will vary by project, and is not meant to be taken literally.

Convergent iteration also makes it easier to spot design, technology, and process risks. For example, as shown in Figure 4.1.3, without a clear game concept, or with churning external requirements, you can find your project stuck iterating in a cycle, covering the same ground over and over again instead of converging on an optimal gameplay solution. Alternatively, you might rush into production too quickly, and end up exploring the gameplay space later in the process when it is much more expensive and you are already beholden to early ideas that might hobble your game (Figure 4.1.4, page 250).

Figure 4.1.3: In some cases you might find that your project is not converging on a single game. This can happen if you did not start with a clear concept, or if external requirements change throughout the life of the project.

Figure 4.1.4: If you race into production too quickly, you might find your project wandering through the conceptual space in the late (and expensive) stages.

Many projects never leave the concept or pre-production stages—these are a lot of fun, and moving on requires commitment and making difficult decisions. Alternatively, some projects barely touch on the conceptualization and ramp up fast to production. This inevitably leads to having a lot of assets (art, code, sound) on hand that might get used somehow, and bits and pieces that hopefully will fit together to make a fun game. In either case, it's easy to find yourself late in the schedule with all the ingredients of an actual game, but for some reason it isn't coming together.

The best way to avoid this is to be rigorous about these first two stages of development, and avoid the illusion that being "in production" means you know what you're doing. The gate from pre-production to production should be the most stringent of all. If the game isn't going to be fun, you should know it—and admit it—by the end of pre-production, rather than hoping that your earlier vague idea will somehow turn into something worthwhile.

Deliverables

The output of pre-production is a set of documents, prototypes, and in almost all cases a small but working version of the game. This playable demo, often called a "first playable," might present only a sliver of the eventual game, and yet it contains enough to give non-team members (i.e., management, publishers) a solid experience of what the game will be. It should also demonstrate the main aspects of the art style and the UI and interactivity style (that is, whether the game is menu-driven, a click-fest, turn-based, etc.). The ability to produce this working game, and to show that there are no major design, technical, or artistic questions remaining open is a clear signal that the team is ready to move into production.

In addition to producing the pre-production documents and playable game, it's also useful to revisit with the team (by now including more programmers, artists, designers, and others who are ready to dive in) the initial overview statement and high-level product goals. It's crucial that before the team enters the "fog of war" known as production that they all understand clearly what the game is and what it isn't. There should be no misunderstandings, no hidden agendas, and no gaps in the design large enough that there is any difference of opinion as to why the game is fun and for whom. Establishing this early on—and reviewing it periodically during production—will prevent many crises on the team and much lost work in the project.

The pre-production documents are more internally than externally focused, although the producer might need to create a marketing-driven document as well. These documents also act in conjunction with the earlier conceptual documents, which might have to be adjusted to reflect changes that have occurred during pre-production. The main documents describe the game from design, art, and technical perspectives in sufficient detail that they can act as a blueprint for assembling the rest of the team and setting production schedules and milestones. They each also outline any significant risks or unresolved issues that remain when going into production.

The pre-production macro design document treats the game design in more depth than the conceptual overview. It includes the main player interactions and the major gameplay systems (NPC AI, level types, combat, magic, inventory, unit types, etc.), but does not yet dive into the details of the systems that are outlined. While it's likely that you'll have actually done some detail design work within each of the main game systems during pre-production (to prove to yourselves that the systems can work, and to add substance to the "first playable" version), keep these separate from the macro design document. The point here is to answer the question, "what is the game?" or "what are we building and why is it fun?" without getting lost in details.

The technical counterpart to the macro/pre-production design document is written by the lead programmer (or engineering manager, technical director, etc.—the titles vary). This document is often called a "technical design" document, as it mirrors the macro design document for the overall game. It outlines the software architecture that will be built during production, highlights any preexisting software that will be used (homegrown or third-party), and references coding standards and source control standards. Any issues regarding these areas should be worked out during pre-production so that the technical team can start to focus on producing robust code and not on which tools will be used. Like the macro design document, the technical design document does not delve into the minutia of the systems to be implemented; it is enough to understand what pieces are going to be needed, how they need to communicate, and where the major unknowns and risks lie. This is necessarily a technical document, and yet the other project team leaders—the producer, designer, art lead, and so forth—should grasp it at least well enough to understand whether it is going to cause significant problems elsewhere on the project.

The lead artist creates an art design document, and often an audio guidebook that parallels the technical pre-production document. This covers the overall art style for the project, presents both inspirational and technical conceptual art, and discusses issues of color usage, camera use, lighting, the look of the user interface, and so forth. While a full art asset list is not typically possible when entering production, an asset creation, naming, and control policy should be included with the document, along with a list that will grow into the full asset list. This list should include the major environments, characters, objects, opponents, and so forth, based on the macro design document. An on-going task during production will be adding items to this list and maintaining it; keeping this up to date and the art integrated with the code all along the way will avoid many heartaches later in production.

Finally, during pre-production the lead quality assurance (QA) person should create an overall test and integration plan for the project. This is based on the technical and art plans, and will follow them as their schedules become more detailed. It is not a substitute for unit testing by the programmers, but provides a centralized plan for making sure that all bugs are tracked, systems integrated and project builds confirmed, and all art and sound assets are in place. QA plans like this are often one of the first things that project leaders eliminate in a production time crisis, but their absence can become a major source of trouble later on.

Armed with the first-playable version of the game, a clear statement of what the game is, some early player commentary (from both initial mockups and the playable demo), and the design, technical, and art documents, the team is ready to get the final deliverable to move from pre-production to production: the green light from management or the publisher. If any of these items don't stand up, if there are too many issues outstanding, or if the game just doesn't feel fun, then the team should go back and hammer it all out until it does work. Until that happens, sending some part of the team off to start creating art or to start working on the software is more likely to create problems later than anything else—and could just represent expensive, wasted work if the game never quite makes it out of pre-production.