What's a postmortem?

Why, I'm glad you asked! A postmortem, for our purposes, is an article by the developers of a game, usually written by a tech or design lead, in which the development process is chronicled. In brief, the article should showcase five things that went right with development, and five things that went wrong, along with a data box. The articles tend to be about 3,500 words in length, with art to supplement it. Art should include preproduction assets, concept art, screenshots, a photo of the development team (if possible), and high-res images for potential spread and cover use. A postmortem should be structured like this:

Introduction - Briefly discuss the game's initial spark and final result, and company origins if necessary.

5 "Rights" - Five things that went right with development, supported by concrete examples. Sections should be numbered (not ranked) and titled.

5 "Wrongs" - Five things that could've gone better with development, supported by concrete examples, and perhaps potential solutions for the future. Sections should be numbered (not ranked) and titled.

Conclusion - Sum up the experience of making the game, and perhaps give an indication of where the team is going from here. Also remember to include a two-sentence bio for the author, written in third person, saying what he or she did on the project, and some related info.

Data Box:

The Data Box should include the following info:

Developer
Publisher
Release Date
Platforms
Number of Developers (can split this into full-time and contractors)
Length of Development
Budget
Lines of Code
Development Tools
Any other interesting information (pizzas consumed, hours crunched, project restarts, softball matches won, etc)

What we want in postmortems:

Details - The more detail, the better. It is much better to say "we had trouble nailing down our art pipeline, and here's what we did to fix it" than it is to say "our art team really pulled together for us." Better to say "our scripting system integration caused headaches for designers, but we decided it was better to educate them than lose the potential wins they could bring," than "various factors led to our level designs being later than desired." This may sound obvious, but lots of people make the mistake!

A good perspective - Postmortems should either be written by someone who can speak to all aspects of the game, or who has gotten good input from everyone. We've gotten more than a few assistant producer or public relations-written postmortems that were extremely light on detail, and were forced to reject them. It saddens us as much as it saddens you.

What we don't want in postmortems:

Self-promotion - Unless otherwise specified, people will assume the team did a superhuman job-after all, who doesn't in this industry? Phrases that are considered too promotional will be cut. This benefits you as well as it does us, as your article appears to be very level-headed and sensible. Of course, some back-patting is acceptable, after all if we want to feature your game, you surely made something rather nice. But the conclusion is the best place for that.

Generic statements - This has been covered to some degree, but postmortems with specific information are much more successful than those that lack anything to grab hold of.

Postmortem examples:

For your reading pleasure, here are a examples of postmortems we've enjoyed in the past, in PDF format.

Secret Level's Golden Axe: Beast Rider

Sucker Punch's inFAMOUS

Thanks for reading, and happy writing!

Interested? Email Us.

If you're interested in writing a postmortem, email us at editors@gdmag.com, or contact editor-in-chief Brandon Sheffield. Additionally, our editorial calendar can be found here.

 


Home | About | Subscribe | Write | Advertise | Resources | Subscription Questions?



Copyright © UBM TechWeb
Privacy Policy | Terms of Service