magazine is by game developers, for game developers. We're always looking for articles that demonstrate new techniques, or espouse new theories, and we welcome your submissions. We are primarily interested in three types of articles: Features, Postmortems, and Product Reviews. Check out the subjects we cover, our guidelines, and submit your idea today. Send an email to firstname.lastname@example.org
for more information.
We want to let you come up with innovative article ideas without influencing you unduly. Technology and consumer tastes evolve more rapidly than this page gets updated, so we won’t try to list specific topics. In general terms, however, know that we cover the following areas:
Technical issues of interest to game programmers that talk about efficiency, and come with code listings and illustrations. The writing's got to be coherent, the code's got to be worthwhile, and there has to be enough text to "wrap around the code"; (at least a 10:1 ratio of words to lines of code!). C/C++ and scripting languages are the most relevant for Game Developer
ANIMATION AND 3D MODELING
Creating real-time and prerendered animation, character animation, mesh deformation, procedural world generation, et cetera... Tell us about your tools and techniques.
Good articles on game design are hard to come by. The article has to present concrete, real-world information to be of value. Case studies work well, as do proven theories coupled with actionable diagrams. Examples might include a survey of enemy patterns across various games, application of psychological studies, and actionable tuning techniques.
Features are generally technical, on subjects ranging from programming, design, project management, art/animation, quality assurance, sound, and so on. Our focus is on implementing solutions, using concrete examples from game development projects. If the subject is forward-looking, or elucidates best practices that are often ignored, that's likely to be of interest to us.
How to Submit a Feature Proposal
Send us a 1-page outline covering the following:
- 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 email@example.com
We may make a decision on the spot to go with it as-is, or we might suggest some changes. If we have already covered this topic in the magazine, we may shop it to our sister-site Gamasutra.com or another part of our network. If we're interested, we'll be in contact. Then, you can start writing the article according to the format below.
Features should be approximately 3,500-4,000 words (not counting code). We reformat all articles during the production phase, so you should not worry about page layout. Here are some things that will make the process easier:
- 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()."
A postmortem is a look at a recently finished game, written by its leads. Like an in-studio postmortem, you talk about the game and team’s initial goals, and explain what went right and wrong during the development and roll out of the game. The articles tend to be about 3,500 words in length, with plenty of art to supplement it.
What's a Postmortem?
A postmortem, for our purposes, is usually written by a tech or design lead, in which the development process is chronicled. In brief, the article should showcase the following:
- 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:
- Release Date
- Number of Developers (can split this into full-time and contractors)
- Length of Development
- Lines of Code
- Development Tools
- Any other interesting information (pizzas consumed, hours crunched, project restarts, softball matches won, etc)
Postmortem Pros & Cons
- 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.
- 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.
Game Developer reviews game development tools on a regular basis. We do not review games. Product reviews are intended to help our readers (including programmers, artists, animators, game designers, sound engineers, producers, and quality assurance personnel) make a purchase decision. For that reason it's important not just to tell what features the product has and what it can do, but how well (or not so well) it performs its tasks. Inject opinion into your reviews. Reviews should not read like the product's user manual. If it is a programming tool, write to an audience of programmers. If it's a 3D animation tool, pretend that you're writing to nobody else but animators. The length of product reviews is approximately 1,200 words.
How to Approach a Review
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?
What's Included in a Review
- 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.)
Most of our authors are working professionals, but we do offer an honorarium for completion of articles (naturally the greatest reward is seeing your work in print!). Features pay authors a flat rate to be agreed upon before publication, depending on the publishable length of the article, and various other factors. We will send contracts to this effect.