O'Reilly logo

The Game Production Handbook, 2nd Edition by Heather Maxwell Chandler

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

In This Chapter
Purpose of a Postmortem
Conducting a Postmortem
Lessons Learned Document
24.1 I
NTRODUCTION
U
sually, postmortems are conducted at the end of the game development
cycle, because they provide closure to the entire development cycle.
They are an opportunity for you and your team to discuss the ups and
downs of the project and how this knowledge can be applied to improving future
projects. It’s also an opportunity to celebrate the game’s completion with each
other. The postmortem must involve feedback from the entire team in order to
be useful. After the actual postmortem meetings are completed, the information
from these discussions is distilled into a Lessons Learned document that outlines
a plan for implementing some changes in the process for the next round of games.
This chapter provides information on why a postmortem is important and how to
successfully conduct one, write up an action plan, and implement changes.
24.2 PURPOSE OF A POSTMORTEM
The main purpose of a postmortem is to learn what methods worked and what
didn’t work during game development. These items are usually focused more
POSTMORTEMS
Chapter 24
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.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required