384 THE GAME PRODUCTION HANDBOOK, 2/E
on the production process—scheduling, planning, implementing features, and
so on—instead of on the actual design features of the game. Although successes
and failures in the game are discussed in postmortems, they are usually tied to
something that was done correctly or incorrectly in the production process. For
example, if the game is not play-balanced correctly, it could be that time was not
scheduled to do this, or if the character models are getting rave reviews, it could
be that the production process included some validation steps that allowed the
character artists to get the most out of the tools and technology when creating
assets. Also, a postmortem is different from the project reviews and critical stage
analysis discussed in Chapter 18, “Production Techniques,” because they are
focused on how the game development process operated, rather than the actual
content of the game.
Postmortems tend to be overlooked in the development process for a variety
of reasons, such as there is not enough time; it’s not a high priority; or people are
not interested in improving the process (after all, the game got done didn’t it?).
However, postmortems are a vital way to learn from mistakes and validate new
ideas that improve the process. By not doing one, developers are overlooking
the greatest source of concrete information they have on making things more
efficient, less costly, and better on future projects.
In order to extract this knowledge from the team, postmortems should focus
on answering these questions:
Did we achieve the goals of the game? In order to document the an-
swers to this question, you will need to prepare a project overview of what
the original goals were and the goals the game actually fulfilled. For example,
the original goals might have included four character classes for the player
to choose from, and the game actually only has three. The purpose of this
question is not to highlight where the team fell short of the goal, but rather
to evaluate why the goal wasn’t achieved, such as changing scope, shifting
priorities, or limited time. Solutions to these impediments can be examined
and implemented to prevent this on the next game.
Were the project’s schedule, resources, feature set, and quality ex-
pectations realistic for achieving the set goals? When discussing this
question, you will want to bring up concrete examples of where these areas
were properly planned for and areas where they weren’t. This is not an op-
portunity for the team to personally attack others about their shortcomings.
Instead, this question should focus on the facts of what happened to im-
pede to goals of the project. For example, people could say something like
the schedule did not account for bug-fixing the levels, therefore three levels
were cut from the game in order to get the rest of the levels finished, or the
approval process took too long and impacted the amount of time available to
implement a feature.