Opinion: Producers, Postmortems And Solving Past Problems

[Why do game developers keep making the same mistakes? Game Developer magazine EIC Brandon Sheffield cites developers from Harmonix, Hothead, and Neversoft to discuss how the lessons of postmortems should actively be applied to new projects, in this editorial from the January 2009 issue.] In the December issue of Game Developer magazine, we ran an article called "What Went Wrong," highlighting common mistakes in game development as seen through postmortems. There was one area I wanted to highlight, but didn't have the space for -- when developers continue to make the same mistakes they've made before. It comes up quite often. The author begins by saying something like "this is really important to us as a studio," but then goes on to say how they went ahead to retread old ground. Here are some examples from past postmortems: The Examples Penny Arcade Adventures: On the Rain Slick Precipice of Darkness "Being an experienced team meant a lot of us had developed certain 'best practices' that we used to maximize the quality of the final product. It was sobering near the end of the project to realize that despite knowing these things, we had simply failed to employ them." -Joel DeYoung of Hothead Games Guitar Hero "For the most part, we were successful in creating a complete and detailed schedule early in the project and sticking to it. However, there were a number of seemingly small and mundane features (such as the unlock store, the intro cut-scene, and the win sequence) that were either underspecified or didn't make it into the schedule at all, and they added up to quite a bit of work. "This is a classic developer misstep, and one that we've made before. We thought we had learned our lessons and applied the necessary structure to avoid this problem, so it really stung when it cropped up again." -Greg LoPiccolo & Daniel Sussman of Harmonix Music Systems Age of Booty "One serious consequence was a breakdown in cross-disciplinary communication, something we take a lot of pride in, as evidenced by our completely open pit-style office." -Max Hoberman of Certain Affinity GUN "With human resources in short supply, we let a critical Neversoft convention fall apart: game and mission reviews." -Scott Pease & Chad Fidley of Neversoft Stranglehold "Quality of life is really important to us, and when we started we really tried to limit crunch but in the end we still failed miserably." -Brian Eddy of Midway Chicago Problems of Production These comments are all from accomplished developers who should know better -- and, in fact, often do. Why then does this happen? It's one thing to simply have an in-house postmortem, but it's another entirely to actively try to learn from and fix the problems that are highlighted as a result. A lot of these issues have to do with scheduling and communication, which in turn has a lot to do with the quality of producers. Proper producers seem to be sorely lacking in the game industry, and often wind up as glorified spreadsheet keepers. A good producer should be fixing problems with the production pipeline -- identifying areas where documentation is lacking, as in the Guitar Hero example, and then making sure that gets done. Or in the case of Gun, making sure that a "critical convention" doesn't get lost in the shuffle. As far as I can tell, this job confusion isn't solely the fault of the production team, but is also tied in to the fact that the structure of most companies is not conducive to producers actually doing production work. Due to improper job descriptions, or even a lack of understanding on a studio's part about what a producer should really do, general producers seem to spend more time worrying about the game's direction (which should be the job of a director or equivalent). Alternatively, they become a conduit through which marketing communicates its ideas to the team. This is often the role they are given, and it seems a mistake to me. Producers should be solving problems. In a sense, they should be the team's internal Q/A-making sure that all the communication, scheduling, and dare I say production bugs get smoothed out in a timely manner. The job goes beyond ordering pizza for the team and updating the Microsoft Project file. The issue is clearly deeper than I can get into here, and I don't mean to suggest that producers are the root of these problems-but they should be the canaries in the coal mines alerting the team to these issues. With some proactive "bug" hunting on the part of a production team, many of these repeated, known problems can be avoided.