Game Developer Postmortems
Jeff Atwood at Coding Horror recently brought up the Postmortems in Game Developer. He’s not in the game industry, but finds them to be generally useful anyway:
These postmortems are deemed so significant to other game developers that they’re often the cover story on the magazine. I think that’s exactly the priority level postmortems should have; if you’re not learning from your mistakes, or even better, learning from other people’s mistakes, then your next project will have a rocky future at best.
I’ve been reading the postmortems in Game Developer for years. Subscriptions are free to anyone in the game industry who is willing to answer “Yes” to the obvious “Answer yes to this question and you’ll get a free subscription” question on the application. Apparently you have to know a subscriber to get that form… I can’t seem to find it on their website.
The trouble with these postmortems is that they are pretty much always the same. They go something like this:
What went right:
- Lots of iteration
- Experienced team
- Early focus on tools
- Lots of control over scope
- Took advantage of feedback from actual players
- Partnership with company we like
What went wrong:
- Not enough iteration
- Absolutely horrible scheduling
- Out of control scope
- Poor tools
- Inexperience
- Trouble hiring good people
- Partnership with company we don’t like
Sometimes the specific headings are a little different, but usually the content comes around to one of these. The trouble is that there are so many disciplines at work on a game that the top 5 bullet points are never specific enough to actually benefit anyone. It’s all well and good to say that you should have a well-scoped schedule with plenty of time for iteration and tools, but actually pulling that off is much more difficult. The postmortems never go into specifics on HOW because they are only 5 pages long.
A better way to get useful information is to attend one of the postmortem talks at the Game Developer’s Conference. The best way is to hang out at a bar with one of the developers long enough that the drink loosens their tongues. Unfortunately none of those approaches scale, so I still find myself reading those Game Developer postmortems and wishing there were more details.
~Joe
fyi, the form IS on the website, it’s just well hidden.
Here’s the URL: http://www.gdmag.com/freeyear/
Sadly it’s only available to residents of the US and Canada.
I think the post mortems are good and they aren’t ALL the same. I agree that if you take a programmer out to a bar and get him drunk he will divulge things that shouldn’t be known. Through the PlayStation Museum’s research, we have talked to numerous developers who tell the REAL STORY behind the games, but they don’t want the information to go public or to be named because they still work in the gaming industry and it would threaten their job. For example, there are stories behind the original game Gex if you do a search. There are stories about other playstation games where the publisher was being hard headed and threatening funding if the game wasn’t out at a certain time so things had to get sacraficed. There are stories where SCEA constantly changed the design of a game so much that the developer was getting pissed but couldn’t do anything about it. The last thing you want to do is name names or create enemies with SCEA and other publishers.
The funny thing is, you don’t actually have to get them drunk to get them to spill the beans. It’s more the casual “just between you and me” atmosphere than the beer that loosens tongues.
Those things PlayStation Museum mentions, those are true of at least half of the projects I’ve ever worked on in my entire career as a developer (mostly in IT related positions). You’d think things would be better by now.