💾 Archived View for spam.works › mirrors › textfiles › humor › gd_guide.txt captured on 2023-11-14 at 10:10:49.
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
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