• Brief description of your idea
• Explain the problem game developers face
• Briefly explain the solution you'll write about and the domain in which the solution works, tools required, and any potential drawbacks
• Include relevant source code examples, figures, or screenshots (in a lossless file format), where applicable
• Short profile of you and your background including current employer
• Email the outline to editors@gdmag.com

• Use short paragraphs.
• Send a text doc, not a PDF.
• Use only one level of subhead (a phrase, usually a partial sentence, that divides sections of an article). Although you may (and probably should) use more than one level of subhead for your own outline, when you turn this into an article you will need to write transitions.
• Code snippets of five lines or less can be put inline with the text. Anything longer needs to be broken out into listings. (e.g. Next we integrate our widget, as shown in Listing 1.)
• Please include all source code as a separate zip, with some annotations as to what’s going on. This will be made available for download in the resources section of Gdmag.com.
• Our listings can often only be as wide as our columns. Please format your code in a way that minimizes horizontal space but maintains good style.
• Send as much relevant artwork to support your article as possible, but do not embed these screen shots or artwork in your article. Please send artwork in a separate zip file.
• Artwork should be sent as uncompressed TIFF or BMP files, or layered PSD files if they include fonts or vector-based layers. Diagrams and charts do not have to be "picture perfect;" our artists can help with that. If you have an artist on your team who wants to help, though, we welcome that too!
• Number your figures, diagrams, and illustrations sequentially, and reference them in the text. Do not include your illustrations in the document. Please reference figures directly in the text. (e.g. Sparse Voxel Octrees can used to animate large models, as in Figure 1.)
• Provide explanatory captions for the artwork, being clear about what is depicted. This can be done in a separate document file, or at the end of your article.
• Include a "Resources" section at the end of your article for readers who want to find more information on the topic of your article, if the article warrants it. This could include books and web sites.
• The text must be more than a walkthrough of the code: "Then, we call foo(). This returns an integer, iRetVal, which we pass to bar()."

• Introduction - Briefly discuss the game's initial spark and final result, and company origins if necessary.
• 5 "Rights" - Five things that went right with development, supported by concrete examples. Sections should be numbered (not ranked) and titled.
• 5 "Wrongs" - Five things that could've gone better with development, supported by concrete examples, and perhaps potential solutions for the future. Sections should be numbered (not ranked) and titled.
• Art - Please include preproduction assets, concept art, screenshots, a photo of the development team (if possible), and high-res images for potential spread and cover use.
• Conclusion - Sum up the experience of making the game, and perhaps give an indication of where the team is going from here. Also remember to include a two-sentence bio for the author, written in third person, saying what he or she did on the project, and some related info.
• Data Box:
• Developer
• Publisher
• Release Date
• Platforms
• Number of Developers (can split this into full-time and contractors)
• Length of Development
• Budget
• Lines of Code
• Development Tools
• Any other interesting information (pizzas consumed, hours crunched, project restarts, softball matches won, etc)

PROS

• Details - The more detail, the better. It is much better to say "we had trouble nailing down our art pipeline, and here's what we did to fix it" than it is to say "our art team really pulled together for us." Better to say "our scripting system integration caused headaches for designers, but we decided it was better to educate them than lose the potential wins they could bring," than "various factors led to our level designs being later than desired." This may sound obvious, but lots of people make the mistake!
• A good perspective - Postmortems should either be written by someone who can speak to all aspects of the game, or who has gotten good input from everyone. We've gotten more than a few assistant producer or public relations-written postmortems that were extremely light on detail, and were forced to reject them. It saddens us as much as it saddens you.

CONS

• Self-promotion - Unless otherwise specified, people will assume the team did a superhuman job—after all, who doesn't in this industry? Phrases that are considered too promotional will be cut. Being frank and humble benefits you as well as it does us, as your article appears to be very level-headed and sensible. Of course, some back-patting is acceptable; after all if we want to feature your game, you surely made something rather interesting. But the conclusion is the best place for that.
• Generic statements - This has been covered to some degree, but postmortems with specific information are much more successful than those that lack anything to grab hold of.

• Klei Entertainment’s Shank
• Mojang’s Minecraft

Research the product. Unless you have used the product a great deal before, read up on it. Take the time to read any supplied reviewer's guide and the user's manual. If the product has any built-in tutorials, run through them. These activities require relatively little time investment and provide a base knowledge about the product. In addition, we highly recommend you seek out user forums and newsgroups that pertain to the product or the technology. By reading what other users are saying about the product, you can pinpoint strengths, weaknesses, and find out where the bugs are. In addition to these suggestions, here are some other rules of thumb:

• Run the product through at least one trial project that people would buy and use the product for. Talk about your experiences, what was going through your mind about the product and process.
• Describe who the product would be beneficial to and the type of project it would be best used for.
• Clarify the technical proficiency one needs to benefit from the product. This includes any concepts or methodologies one must be acquainted with.
• Give your opinion of whether the product lives up to expectations. Did it deliver on its promise (as described in a press release or on the product's packaging), whatever that may be?
• Let the reader know how it compares with its competitors.
• Point out any special hardware, software, or networking requirements for the product.
• Wind up your review with a concise paragraph or two summarizing what you think about the product, and who the product would be good/not good for. Answer the question every reader has: "Is it worth the investment?" and be honest with your answer.
• Look at the product's price. Does the product justify the price tag? This can be especially important if you are reviewing an upgrade of a product. Should someone who has the last version of the product shell out the money to buy it, or are there not enough new features to justify the expense?

• Data Box:
• Product name and version number
• Company name
• Company address
• Company URL
• Product price
• Software requirements (operating system/environment, etc.)
• Hardware requirements (megabytes of RAM needed, the recommended hard drive space, etc.)
• 3 pros and 3 cons about the product (these should be short, one or two sentence summations of your main points from the body of the review).
• Where possible screen shots of the product are a great addition, especially as you’re using it. Screens should be in .TIF, or high-quality .JPG format, and at least 1024x768 resolution, but the bigger the better.
• A 1-2 sentence bio about yourself (game credits, current position, etc.)

• Trinigy Vision Engine 8