The first time I heard the word “post-mortem” used in a video game context was in 2004. I had a vague idea of what it could be, but I found the use of “post-mortem” very negative. You know… something is dead and you still poke it to be sure that it’s dead cold.
Then I realized post-mortems are a bit more than a zombie thing. They are a great tool for every game developer (whatever branch they’re in) to improve their skills and knowledge of game development.
What is a post-mortem
A post mortem can have very various shapes, but it’s, most of the time, a simple text document. Its main purpose is to keep track of the development of a game. It’s the History of your game. The reality behind the scene.
You should see a post mortem like your very own fortress of solitude where you can always count on Jor-El to help you remember what motivated you and what made the actual shape of your game.
A post-mortem is a tool of the past helping you shaping a better future. Knowing why and how you did things before is a great way to learn from your own mistakes and do better next time.
Remember that it is not a marketing tool. It’s not made to be seen by people not part of the development team. Like personal diaries post-mortems work best when they contain personal stuff (about the development, not about your secret love for Jenny. Nobody cares about your love for Jenny… even her. Sorry). Even if you can always publish them on the Internet, and even if they are a great source of knowledge to anybody who is interested in game development, remember that the main purpose is to make YOUR team stronger and learn from the past. It’s not to communicate about your game in order to sell another copy or two.
Few things to put in your post mortem
When you write a post mortem it’s important not to fool yourself with the mood you’re in. The very common mistake is to write a nice and happy post mortem containing pictures of puppies if the game release was a success, and a very dark and sad one if the game did not meet its audience. Post mortems have to contain facts and only facts.
Gather your team and talk about the development. Ask everybody what they think about the previous development, what was good and, more importantly, what was bad. These questions should cover development conditions, techniques, game design direction, code architecture… the game in its entirety.
A discussion (often full of energy, passion and tears) will naturally start and you will be able to discuss everything in detail. For every point there is only one question you have to answer to:
How to make things better next time?
If something went wrong during the development there is no need to find who is guilty (usually everybody knows who’s guilty). The only thing that matters is to find a way to be sure the mistake won’t ever be made again. You can’t always find perfect solutions for every problems, but try to find leads on how to improve your development scheme and habits.
Games are forever
Back in the days finding the right moment to write a post mortem was easy. It was usually two weeks after your two month of post-release depression. But today games are never really finished. They are even sold before they actually exist. What a crazy world we live in. So when should you start writing your post mortem if your game is never actually finished? I would suggest you to take some times after all the critical bugs have been fixed and before the development of the first non-critical update or DLC. If you learn new things or detect new problems during the DLC development you can always add content to your post-mortem.
However in these crazy days I tend to prefer writing post-mortem even before the development is actually finished. Working on games developed in 5+ years taught me that memory is a very versatile thing. It’s easy to forget about entire things you have spent months to develop… but you should keep track of these. So I believe that taking an hour or two every month to write some facts about the current state of the development can be a good thing. After the release of the game you just have to gather all your note and share them with the team to write a real post-mortem document that would be more precise than if you would have to rely only on your tired memory.
Post mortems are useless if they’re not read
Now that you have written 2253 pages1 describing how shitty the development of your previous project was, remember all these are worthless if you don’t read them.
You have a game concept? Cool. The prototype is even finished? Excellent! So you feel it’s time to start the development of the game? Whoa! Hold on a minute.
It’s time to take some distance and to breathe in while opening your previous post mortems. Take some times and read them all. You should always start a new development with your previous mistakes and genius ideas in mind. It’s the best way to be sure to avoid the mistakes you already went through.
Post mortems come in various shapes. The number of pages is not relevant. An intelligent 10 pages post mortem is better than 2000+ pages of useless comments. ↩