textfiles/humor/gd_guide.txt

                         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  
 <codefont> and <end> 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 
 <codefont>Foo<end> matrix, as shown in Listing 1."

 The text must be more than a walkthrough of the code: "Then, we call 
 <codefont>foo()<end>.  This returns an integer, 
 <codefont>iRetVal<end>, which we pass to <codefont>bar()<end>."

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