Who Reads Us

Postmortem Objectives

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:

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:

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...

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...

Don't forget the Data Box

• 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

Interested? Email Us.

Home | About | Subscribe | Write | Advertise | Resources | Customer Service

Copyright © 2004 CMP Media LLC. All rights reserved.

Privacy Policy | Terms Of Service