Who Reads Us

Most of our 35,000 readers work in medium- and large-sized North American game development companies. The audience for your technical article will include professional programmers, animators, sound designers, and producers. We do not target the hobby or amateur game development market.

Postmortem Objectives

The objective of Game Developer's Postmortem column is the same as that of a real-world postmortem. Your game has been completed, and you are documenting what went right and what went wrong along the way. Hopefully the lessons you learned along the way will be communicated to others so that they can repeat the successful parts of the development process, and avoid the pitfalls you encountered along the way.

Article Format

Begin the column with a brief description of what your game was originally intended visualized as, before the coding began. Explain the type of game, the goals of the game, the intended audience, and any specific technologies or features that you wanted to build into it that would set it apart from the competition.

Tell us about your development team -- what else they have worked on, what the team dynamics are like, and so on.

Talk about the tools you used in developing the game. This should include the hardware, software, outside services you used such as motion capture, etc.

After introducing the reader to your plans for the game and the team and tools that would build it, the bulk of the article should revolve around the "5 wrongs, 5 rights" concept:

  • Explain what 5 goals, features or aspects of the project went off without a hitch or better than planned. Were there any phases of development that you thought would be much harder than you had planned? Did a new programmer come on the team and inject great ideas or brilliant programming ability into the effort? Did a new technology become widely adopted by consumers that solved a particularly thorny development problem? Did new development tools become available that let you add better graphics or sound? Did you save money in certain ways you hadn't expected? Cut days/weeks/months off the schedule in some way you hadn't expected to? Did the marketing or PR team get some outstanding preview coverage in a consumer magazine?

  • Explain what 5 goals, features or aspects of the project were problematic or failed completely. Did the lead programmer leave the company halfway throughout the project? Did adapting to new technologies (for example, MMX, DirectX, a new graphics library or AI algorithm) create unanticipated problems for the developers? Did your development tools let you down in some way or not live up to expectations? Did hidden costs creep into the project, and if so, where did they come from? Did the schedule slip for some reason? Was the configuration testing or beta testing cycle problematic for some reason? Did features get axed because of scheduling pressures? Did the lead programmer quit? Did the marketing or PR team misrepresent the game to the public, causing false hopes? Be specific in this regard -- postmortems that accentuate the "what went right" and sugar coat the "what went wrong" sections are dismissed by readers and won't be accepted by our edit staff. Be honest, that's all we are asking.

    • Important: try to come up with things that went right/wrong during project that are likely unique to your project. Stay away from common and well understood problems and solutions (e.g., "communication between the team members wasn't good" -- that's been true of most games), and focus on what made your project different from others. Surprise the reader!

    Also important: We know you are nice people who do wonderful work, but the Postmortem column is not the place to engage in PR, display gratuitous self-aggrandizement, kiss up to your publisher, or try to find a publisher for your next project. Try to focus on the actual development process itself and what you learned professionally, bearing in mind that the audience for your article is not the same as the audience for your game.

    With these points in mind, tell the readers about your experience. To keep the format consistent from issue to issue, use the five wrongs and five rights as numbered subheadings. Here's an example:

    "The Making of Speed Racer"
    Introduction (Goals, vision, audience, team, tools, etc.)

    What went right
    1. After a long series of negotiations, we successfully licensed the Speed Racer cartoon and got the original actors to do the voice overs for the game...

    2. We successfully converted our static isometric perspective engine used in our last game into a moving camera perspective that tracked the car from different angles. This was achieved by...

    3. We hired away our competitor's lead developer; he ended up being the person that made the modifications to our graphics engine...

    4. Successfully made use of 3D audio API, the first time we've developed a game with this technology. It was a challenge, but here's how we did it...

    5. Implemented new multiresolution geometry technology that we licensed from [some company]. It allieviated some frame rate problems that we were having, and also allowed us to use more detailed models of our cars. Here's how it works...
    What went wrong
    1. Our original schedule turned out to be too ambitious. As a result, some features from the original design document had to be shelved, like...

    2. Our modified graphics engine had critical flaw not detected until halfway through development schedule. This forced us to pull 2 contract programmers into the project for a while, and hurt our schedule even more.

    3. Three days before E3, we realized that our audio team's latest tracks didn't sound correct. We spent 2 all-nighters fixing the problem, which we discovered was caused by...

    4. We lost our art lead halfway through the project...

    5. A critical technology we had licensed in our graphics engine turned out to have some serious glitches in it. We had to fix it by doing the following...
    Conclusion (Summing up lessons learned, etc.)

    Don't forget the Data Box

    At the end of the article, create a data box containing a snapshot of your game and its development. Here is the necessary data:
    • The number of full-time developers assigned to the project, and the number of contractors used.

    • The budget of the game (estimate/ballpark is OK).

    • The length of time the game was under development (from initial concept to ship date).

    • The release date of the game.

    • The platform(s) the game runs on.

    • Hardware used in the development of the game (what type of workstations, RAM, hard drive, graphics cards, etc.). This may differ from person to person, but list a typical workstation.

    • Software used in the development of the game (compilers, audio tools, animation tools, etc.).

    • Notable technologies or technical underpinnings that were used/licensed for the game -- one you couldn't have done without. For instance: motion capture, force-feedback input, Bink, DirectX, Unreal engine, etc.

    • Size of the project (number of lines of code, script, files).

    Include Visuals

    Readers want to see what your game looks like. Send us as many screenshots as possible, in the highest resolution (300 dpi preferred) you have them.

    Send screenshots taken during the creation of models (in wireframe view) or other images that convey the feeling for what the game looked like during development.

    Send scans of paper & pencil drawings done of characters during the initial concept stages of development.

    Send photographs of the development team, taken on the job.

    Length of article

    The length of the Postmortem column should be in the 3500-4000 word range. Broken down, that allows you to write about 3-4 paragraphs on each of the wrongs and rights of the project, plus an intro and conclusion. If you need more space, let us know. We may be able to accommodate a slightly larger article.

    Interested? Email Us.

    If you're interested in writing a Postmortem, email us at editors@gdmag.com. Describe the project, who developed it, who's publishing it, and describe the game. Also let us know what role you played in the development. If we give you the go ahead, you'll have about 4 weeks to write the article and submit it. We'll probably make some small style changes or ask you to flesh out certain parts a little more, and then ask you to look at the article once more. After that, we'll put it in the magazine.

     


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



    Copyright © 2007 CMP Media LLC. All rights reserved.

    Privacy Policy | Terms Of Service