This lecture looks at trends found in a 2016 paper on game development postmortems and describes how their trends can be helpful to developers.

1. LEARNING FROM POST-MORTEMS

2. TOPICS
• What is a post-mortem and why should I care?
• Post-mortem trends
• Takeaways (part of the trends slides)

3. WHAT IS A POSTMORTEM?
• Post-mortem – a review of a
project after it has been delivered
or completed
• Not a “review” in the scoring,
“7/10 too much water” sense
• “What went right, what went
wrong”
• Delivered as articles or as
conference talks

4. …AND WHY SHOULD I CARE?
• Learning from industry veterans
• Everybody fails at some point,
even your heroes
• Learn about what game
development looks like in
different studios

5. …AND WHY SHOULD I CARE?
• “Game development is different
from traditional software
development in a number of
ways”
• “The requirements are more
subjective.”
• “Maintainability is often sacrificed
for performance.”
• “Testing and quality assurance are
approached differently.”
• “Most games require tools
programmed from scratch.”
• “Deadlines are tight.”

6. POST-MORTEM SOURCES
• “What Went Right and What
Went Wrong”: An Analysis of 155
Postmortems from Game
Development
• By Michael Washburn Jr., Pavithra
Sathiyanarayanan, Meiyappan
Nagappan, Thomas Zimmermann2,
Christian Bird
• “The Cabal: Valve’s process for
creating Half-Life” by Ken Birdwell
https://www.gamasutra.com/view
/feature/131815/the_cabal_valves
_design_process_.php

7. POST-MORTEM TRENDS
• Product
• Art
• Creativity
• Features
• Design
• Gameplay
• Product evolution
• Scope
• Development
• Process
• Documents
• Obstacles
• Team
• Testing
• Tools
• Resources
• Tools
• Hardware
• Publisher relations
• Schedule
• Customer facing
• Community support
• Feedback
• Marketing

8. ART
• What went right
• Artists working together with other
designers
• Cabal – all makers of one “section”
of a game are stationed together
instead of as discipline
“departments”
• “The team making level 3”
instead of “the art department”
• What went wrong
• Reusing assets from previous
projects: hurt review score and
response
• Choosing a style of art that’s “too
big”

9. CREATIVITY AND FEATURES
• What went right
• Open dialog on new ideas
• Frequent design review sessions
• Early open creativity with a cutoff
when development is implemented
• Units focused on creating a single
part of a game
• What went wrong
• Initial release by studio not unique
enough
• Allowing open creativity for too long
• “scope creep”
• Allowing creators to make random
features that are never implemented

10. DESIGN AND GAMEPLAY
• What went right
• Unique designs keep the team
motivated
• People get excited about working
on cool features/design elements
• Using playtests to determine
tutorial content and intensity
• What went wrong
• Design enough depth for players to
get into your game
• Never assume players will just “get”
your game
• Calibrating gameplay based on
developer skill

11. PRODUCT EVOLUTION
• What went right
• Paying attention to public response
or awareness of the game
• Evolving based on feedback and
observation of user response
• LISTENING
• What went wrong
• Designing in secret/isolation

12. SCOPE/BUDGET/SCHEDULE
• What went right
• Not overscoping
• Does your game reaaaaaaally
need…
• Multiplayer?
• Crafting?
• 100 characters?
• 2 big cities?
• What went wrong
• Thinking that your game needed all
of those things up there.
• Estimating scope/features
incorrectly compared to

13. DEVELOPMENT
PROCESS/DOCUMENTS/PUBLISHER
RELATIONS
• What went right
• Don’t start your game over because
you received some negative
feedback
• Projects where the developer
listens to feedback but applies it
based on their project goals
• Taking time for pure
design/documentation
• What went wrong
• Not doing any of the above
• Starting development right away
without establishing design and
project goals beforehand (no paper
design)

14. OBSTACLES
• What went right
• Establishing or improving on
communication
• Establishing a set pipeline of how
work gets done
• Reviewing features or scope
frequently
• What went wrong
• Not giving set tasks
• Not documenting code or naming
files in a communicative fashion so
others can “plug in” to the project
• When tasks, goals, or expectations
are vague

15. TEAM AND TESTING
• What went right
• Experienced teams find more
success
• Build and maintain mutual respect
• Avoid “Game designer as
architect and asset makers as
contractors” analogy
• Testing early and often
• What went wrong
• Team inexperience
• Not testing enough

16. TOOLS
• What went right
• Using tools you have experience
with
• Using tools with lots of
documentation
• What went wrong
• Using tools with little/no
documentation
• Learning a new tool

17. HARDWARE
• What went right
• Understanding the “verbs” of the
thing you’re making games for
• Experience working with the tech
• What went wrong
• Trying to scale down into tech that
cannot support a game

18. COMMUNITY SUPPORT
• What went right
• Release your early
access/prototypes when it has
enough basics that the community
expects
• Have ongoing dialog with players
• What went wrong
• Promising or even mentioning
things that were not made yet
• Releasing beta/early access TOO
early
• Not sufficiently explaining what
state the game is in to the audience

19. FEEDBACK
• What went right
• Getting feedback early and often
• Allowing for “brutal” feedback
• Asking testers specific questions
based on what you want to know
• What went wrong
• Letting testers tell you EVERYTHING
they think about or want from the
game
• Not asking the question “if this
wasn’t here, would the player miss
it?”

20. MARKETING
• What went right
• Schedule milestones near deadlines
for festivals and major market sales
• Schedule outreach/social media
times
• #Screenshotsaturday
• Participating in other parts of the
game industry beyond game
making (speaking, writing,
podcasts)
• What went wrong
• Not taking time for marketing
• Assuming that online portals are
marketing or will market your game