Game Developer Writers Guidelines Game Developer is a technical magazine devoted to the development of computer games. Its audience is programmers. Game Developer will also be of interest to entrepreneurs in the game market and computer artists, but its main audience is programmers. Good programmers. Really, really good programmers. Our editorial goal is to produce the most intensely useful programming magazine ever. We aren't interested in introductory articles. We aren't interested in articles about Windows common dialog boxes. We aren't interested in articles about software engineering. We're interested in highly technical articles about game programming. Period. Interviews Game Developer often interviews leading figures in the field of digital entertainment, but these are generally done by our staff. Just about the only time we'd be interested in a submitted interview would be if you had some credentials as an interviewer (a journalism background, for example) or if you had exceptional access to someone whose work is important to game development. Even then, we'd want you to clear the interview with us beforehand so we could let you know specific questions we'd like answered. Business Articles Game Developer devotes some amount of space to business issues, especially channel, legal, and marketing issues. Articles of interest here could deal with, for instance, breaking into the channel, legal protection when working with a distribution house, and marketing on the cheap. Of much more interest to us are articles on industry trends based on real numbers. For instance, how fast is the Windows game market growing? What's the market share of sport games vs. fighting games vs. flight simulators? What are the sound and video chip sets that are gaining market share? Such articles are of great interest to us. Technical Articles Interviews and business are all well and good, but the meat of Game Developer is its technical articles. Game Developer technical articles deal with high-performance programming in a highly constrained hardware environment. They do not deal with business issues. They do not deal with maintenance issues. They do not deal with academic issues. They deal with getting the job done without flickering, popping, jumping, or crashing. If you have a complex technical topic, and you're looking for guidance on what exactly to write, do this: Write a 5,000-word introductory article on the subject. Write a second 3,000-word article that's much more in-depth and assumes all the introductory stuff is well understood. Take all the terms in the introductory article and create a glossary of no more than one page. Submit the second article with the glossary as a sidebar. Sell the introductory article to someone else. For example, multitasking. Let's take a look at some introductory paragraphs and our reaction to them. "You want to program a flight simulator with a cinematic plot. Your user will take the personality of Billy Zoom, Skateboard Punk, who breaks into Area 51, steals a Manta hypersonic jet and flies across the world battling the forces arrayed against you by the Super Secret NSA. You're halfway through the program when you realize there's something terribly wrong. You move, and the opposing planes move, making for terrible jitter. You need multitasking! Multitasking is a complex issue that can only be touched on in a magazine article. This article will give an overview of the general theory of multitasking. So that we won't get bogged down in details, my examples will be in pseudocode." Destination: garbage can. The tone is condescending, the focus elementary, and it contains the two evil words "overview," and "pseudocode." What's next on the pile? "Abstract: An analysis of balking protocols in high-transaction multitasking environments shows an unfortunate degradation in performance under certain circumstances. This paper reviews existing balking protocols and demonstrates their theoretical weaknesses in these circumstances. A new balking protocol, based on the mass of the Top quark, is proposed." Our reaction: What do we look like, a Ph.D. review board? If you want to write something in the passive voice or that begins with the word "Abstract," we'll be happy to read it in an ACM or IEEE journal. But we won't publish it in Game Developer. Let's try a final one: "Minimizing input lag, so the game reacts instantaneously to keyboard, joystick, or mouse data, requires something more than a naive 'get input, process input, display output,' loop. I've written a series of efficient C++ classes that allow multiple input devices to be active simultaneously, eliminates type ahead problems, and require only 5K of overhead. This article explains the classes, how to use them, and suggests areas where they could be improved." Hello! We'll continue reading this article. It talks about a real issue for game developers, it talks about efficiency, and it has real code. There's still a long way to go before we accept the article -- 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!). But we're going to work with the author to make this article happen. C++, Pascal, C, and assembly language are the most important languages for Game Developer. It does not mean we are exclusive to them, though, or that we have any concrete ratio of C++ to Pascal to ASM that we stick to. Implementation Details We know that you'd like to get a quick response to your article, but the simple fact is that we deal with things in a strict FIFO manner. When an article comes in, it goes to the bottom of the pile without a glance. Sorry. Because we print out the articles, put them in a stack, and read them, we've discovered that when an article is snailmailed in, it's actually often resolved faster and is more likely to be accepted. That's because you make sure that the printing's all nice and tidy and the figures are all there. When an article is ZIPped and uuencoded and the figures are here and there and so forth, things can get messed up pretty easily. Our snailmail address is: Game Developer magazine 600 Harrison St., Fourth Fl. San Francisco, CA 94107 Atten.: Submissions Or, if you really feel strongly about it, you can e-mail a plain ASCII, WordPerfect 5.1, or Word for Windows file to larryo@well.sf.ca.us Figures must be in TIFF or PCX format. Article formatting We reformat all articles during the production phase, so you should not worry about page layout. However, there are a few things you should know to give your articles a professional appearance. Use short paragraphs. Use only one level of subhead. 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 need to write transitions. You should only worry about three fonts: a body font, a subhead font, and a code font. We use Caslon, Folio, and Voice Comp, respectively, but you don't have to worry about that. Code font should be used for program code, variable names, program names, and object names. If you're submitting an ASCII file and need to indicate code font, use and to tag the text. Replace all tabs with four spaces. Code snippets of four lines or less can be put inline with the text. Anything longer needs to be broken out into listings. Our listings are either 40 or 80 characters wide. Please format your code in a way that minimizes lines but maintains good style. For instance, we prefer: for(int i = 0; i < 10; i++){ doSomething(i); //matrix transform doSomethingElse(i); //post process matrix } to either: for(int i=0;i<10;i++){doSomething(i);doSomethingElse(i);} or: for(int i = 0; i < 10; i++) { /* matrix transform */ doSomething(i); /* post process matrix */ doSomethingElse(i); } Listings and figures need to be referenced in the text. You always have to use a phrase along the lines of "Because, as can be seen in Figure 3, the viewpoint has moved, we must transform the Foo matrix, as shown in Listing 1." 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()." Submit, Damn You! Game Developer was started as a guerrilla project by a bunch of editors at Miller Freeman Inc., the company that publishes such mainstream Software development magazines as Dr. Dobb's Journal, Software Development, and Microsoft Systems Journal. We felt that a magazine devoted to game programming would be a hit with programmers, and we've had great success with our initial efforts. But we want to get even more technical depth into the magazine, and we need your help. If you follow these guidelines, you'll have a great chance at being published in Game Developer and help make it into a magazine that's written by and for the best programmers in the world. Larry O'Brien (Editor-in-Chief) Game Developer magazine 600 Harrison St., Fourth Fl. San Francisco, CA 94107