The end of production is often not as clear as its beginning. The team has worked hard for months, perhaps more than a year, and sometimes it seems the end will never come. But at some point, the project either grinds to a halt under its own weight—not the end you want to see—or it reaches that point when the tasks of producing the necessary software, art, and sound can be called complete—which is not the same as saying the game is finished.
The post-production stage consists of two main milestones that focus on evaluating, fixing, and polishing the game prior to release. This stage can take up to 20 to 30% of the overall project duration, depending on the complexity of the project and on how effective the concept and pre-production stages were. In general, complex multiplayer games need to plan on spending more time in this stage than do more linear single-player games.
As development proceeds, the number of unimplemented systems and game features diminishes. There is a milestone, often both loved and feared by the development team, when all the initial features for the game have been created; no art or sounds are missing; and the user interface functionality is complete. This point is sometimes referred to as "feature complete" and is often called the alpha milestone. On a well-designed, well-run project, this point is loved because it means the game is there—even though significant work remains to be done. At the same time, it's feared because inevitably cuts have been made to the original concept (primarily during pre-production) and everyone has a pet feature they would love to see put into the game before it is considered complete. On a poorly conceived, crisis-ridden project, the alpha milestone is dreaded because it often represents a point of maximum anxiety and even denial: the game isn't done because the design has been implemented, it's considered complete because there is no more time in the schedule or money in the budget to actually make the game as originally planned.
While the game might be "feature complete," the team's work is far from over. The gameplay is there, but it is hampered by bugs both serious and superficial, and by a variety of balance issues between in-game units or objects. It is important, however, that after the alpha milestone, during all the testing and bug-fixing to come, that no new features are implemented without significant oversight from the entire team leadership, and often from management outside the team. The temptation to add a new feature can be strong, but this presents a high risk of delaying the game's eventual release. It can also be tempting to only sketch out the functionality required by a feature or software system earlier in the project, and to call the missing functionality a "bug" to be finished after alpha. This type of dissembling action might save the schedule in the short-term, allowing the team to appear to be on schedule at an earlier milestone, but only at the cost of requiring more time and increased risk later in the project, when the costs of failure are higher.
After the alpha milestone, the team should regroup and then begin fixing bugs in order of priority as established by the QA team and their test plans. The design team should focus on gameplay pacing and balance issues, and if necessary on creating additional levels or environments using the existing feature set. This will involve playing the game over and over again, looking for rough spots to be smoothed over via technical, artistic, or design balancing means.
It is during this time that gameplay testing and evaluation using regular players (not team members or members of other teams) should begin in earnest. During pre-production, early mockups and prototypes should have been given exposure to players to look for interest and comprehension—is the game going to be fun and will players understand it? During production, gameplay testing of individual levels, modules, or systems also helps hone the design and keep implementation on track. Now, with the entire game in place, full gameplay testing begins in earnest. This is the best way there is to find surprising bugs, gameplay flaws, obscure in-game goals, misleading art, and so forth. All of the findings from this gameplay testing are fed back into the plan for fixing bugs, art, and design issues.
Once the alpha version of the game has been created, the team will need sufficient time to create and polish any remaining levels or environments out of existing assets, fix up these assets, and fix bugs found during testing. This is typically on the order of half as long as the entire pre-production stage, or about 10 to 15% of the total time needed to complete the project.
Once all the objects, environments, gameplay systems, and user interface have been completed, evaluated by players, and any problems fixed, the game is finally nearing completion. This is often called "going into beta" or hitting the beta release. During this time, the game is opened up to more players for testing, finding bugs, and game-play evaluation. The entire team should be hunting down and selectively fixing or documenting any bugs found. As time goes on and the game nears its final release, changing any aspect of the code, art, or sound should require increasing oversight to prevent the last-minute creation of a devastating new bug. The design team should be listening to player evaluations and making final tweaks to the gameplay pacing and balance based on their comments.
In addition, the producer and other staff need to be making final preparations for manufacturing, packaging, distribution, and marketing. These activities are typically outside the scope of the game development process itself, but are nonetheless extremely important and time consuming.
In games with a significant online presence, such as massively multiplayer online games, all the aspects of the service side of the game—in many respects as large and complex as the initial game development process—need to be brought up to speed. Typically, there is a "live" team that will maintain and extend the design and game systems once it is up and running. During the alpha and beta periods, this team should be assembled to provide continuity with those members of the original team who are moving on to other projects. There are also significant activities surrounding billing, customer service, in-game help, and other parts of the on-going online service. Each of these presents new challenges that differ from anything seen thus far in the development process.
The time required for an effective beta period will differ from project to project, but it is typically about as long as the alpha period. At a minimum, the beta period needs to be long enough to have players evaluate the game on their own, report back problems, have the team make the necessary fixes, and have the game evaluated again. This is rarely shorter than six to eight weeks, and might last several months.
Finally, the day arrives when all the aspects of the game have been balanced, all the necessary bugs have been fixed, the animations and sounds are timed perfectly—the game is ready to be frozen in the form of a "gold master" CD-ROM for shipment. Alternatively, this day arrives because of the lead time necessary to get the game to magazines for review and through manufacturing, packaging, and distribution in time for the holiday sales rush. Ready or not, the game goes to gold master.
As you can imagine this can be both thrilling and frightening, depending on how many and how severe the known bugs are that remain unfixed. In many cases, the team steams right on past the gold master date, with any additional fixes or changes being put into a post-release patch available from the company's Web site. This, however, is an implicit admission that the project got away from the team, and that what is shipped is not as polished and playable as it should be. Your goal should instead be to be able to have a release party (the true end to the development process) without any overshadowing issues or anxieties about whether the game is complete.