Stage 3: Production

In many game projects, being "in production" is considered to be really working—the game is becoming real. While it's true that it's in this stage of development that code, art, and sound are emerging, if you've handled the concept and pre-production stages appropriately, the game should already be feeling real to the team. Production becomes about implementation that stays true to the concept, macro design, and art direction decided on earlier, and on executing minor course corrections as needed.

The production stage typically takes the lion's share of the project's time—50% or more, or a full year out of a two-year project. Nevertheless, if you've prepared well during the pre-production stage, this stage need not turn into a crisis-filled death march toward an ever-receding goal.

Process

During production, the design, technical, art, and sound teams need to work closely together based on their common vision. There will always be some give and take, problems that must be solved, but as long as this happens within the context of the game concept and design already created, the team and the project will stay on track. During this stage, the focus shifts from design to the technical and artistic implementation. That doesn't mean that design is left with nothing to do—they still have a great deal of detail design work and balancing to take care of as the technical and art teams deliver the software infrastructure and game features.

The technical team's first task, working with the producer, is to lay out a high-level schedule for delivery of program components based on the design document that was delivered as part of pre-production. This schedule typically takes the form of high-level milestones that occur once every four to six weeks—shorter than that and there's not enough time for significant progress, and much longer than that and the team's focus can be lost. During each milestone period, the process of detail design, implementation, integration, and evaluation will take place with one or more major systems or gameplay features. In many cases these overlap, so that one system is in final integration and evaluation at the end of a milestone, while another is scheduled to be done with its first pass of implementation, and another is scheduled to have its detail design complete.

However, a detailed schedule cannot with any degree of certainty be created in advance for the entire duration of the project. Instead, it's best to plan in complete detail for the current and next milestone, and to make one of the current milestone's deliverables a similar list of the contents of the next two. Further out than that, the milestones should have high-level goals based on the design, art, and software needs.

The order of implementation is different on each project. This is something best left to the technical lead to decide, working in conjunction with the producer and other team leaders. One important factor is to ensure that the software architecture is as robust as possible, but without leaving the rest of the team unable to proceed or play the developing game. After the first playable version, the game should never "go dark" or become unplayable. Making separate prototypes and code branches helps preserve the programming team's flexibility while enabling others to make progress in their areas.

While the technical team is creating the main software systems for the game, the art and design teams are revisiting in detail their earlier macro designs. Now each monster, vehicle, object, animation, environment, and attribute must be examined and reduced to numbers for the designers, and models and pixels for the artists. Communication and integration are key, so that the designers do not, for example, create 10 types of alien troops while the artists create models for only three. Each type of object that will appear in the game is designed in complete detail, including what makes its contribution to the gameplay different from any others, what animations it has and commands it responds to, and its specific attributes (or range of attributes) relevant to the game. This should all be included in a descriptive single page per object type, and the necessary model entries should be added to the art and sound asset lists.

As each asset type is designed, it should also be prototyped and tested in game, evaluated for its appearance and effect on gameplay, and changed (via iterative design/implementation) as needed. This iteration will go much faster if the game objects are data-driven; that is, they receive their attributes from a text-based data file that is easily changed by the designers. If instead the designers have to pass each change to the programmers, progress will be much slower. Note too that "tweaking" game-object attributes is an on-going process, not a one-time activity. To make sure the game is balanced, various object attributes will have to be changed, tried in-game, and changed again. This process lasts throughout the production stage.

Milestones

Most complex game projects live by development milestones as mentioned earlier. These are typically set up by the producer in conjunction with the technical, design, and art team leaders, and often with significant pressure from external management. If the concept and pre-production stages have gone well, the main point of these milestones will be to show that the game is developing as planned, that the necessary game elements are being implemented in a timely fashion, and that the team is not drifting off target. It's easy to indulge in late-stage design, to want to include a new nifty feature someone thought of, or even to take the game in a new direction. Each of these is extremely risky, however, so realistic milestones based on the pre-production plans help the team stay focused and reduce or eliminate these risks.

Each milestone should demonstrate a visible new capability, preferably in the gameplay. Even when the main progress is technical or graphical, this should be expressed in terms of making the game more fun—if a new particle effect doesn't make the game more fun, you should question why your team is spending time on it. However, sometimes at a milestone the game will seem less fun than before. This is important to evaluate carefully: is it less fun because a new system isn't fully implemented, because there's a missing part of the user interface, or because some new objects have thrown off the game balance? All of those are easily evaluated and fixed. On the other hand, it might be that the game has become less fun because it's grown too large, tedious, or repetitive. If this seems to be the case, you need to quickly consider where the design or implementation went wrong—you might need to add features or objects, or more likely cut some out.