So you can Code, Punk ?
Great ! The Quake community has been built on contributions from thousands of people, your
contribution will certainly be much appreciated.
1. Submission Guidelines
We accept submissions in any of our sections (tutorials, articles etc). To start with we
recommend that you do a tutorial or two. Try to keep your tutorial simple yet informative.
Break your work into logical sections and explain what you're doing at each point.
Please make sure that your work is original, accurate, readable, and CORRECT. Why not send the
tutorial / article / whatever to a few friends to try themselves ? Often they might pick up
some errors that you've missed.
2. Style
Very importantly, PLEASE follow the style of this website EXACTLY. We provide stubs
for you (don't worry) - it's just a matter of pasting your material into them. Submissions that
don't follow our style can't be accepted...
Download the stubs
3. Grammar and clarity
We won't reject a tutorial for bad grammar (we're less than perfect ourselves):
we're more interested in the content and explanation of the neat things you've
been doing to the Q3 code.
For those of you that do want to "write better" (perhaps English is your second
language, or grammar class in school were dull), well we've found an accessible
article that might just be of help. We won't beat you over the head with it,
but you might just learn something.
Thanks go to Allen Eccles and Frank Rogan for
"GameSpy's Guide to Good Grammar".
4. Code Formatting
Formatting code inside an html can be especially hard. We enclose all our code segments
within a pre tag. This means that line breaks in the code are presented ok, but it
also means that extra extra long lines will exlpode the browser window horizontally.
Remember that some poor people only have 800x600...
So, we ask you to BREAK or REDUCE any lines that explode the page over 800 pixels (about
80 characters is fine). If you break a line, be sure that it still compiles (for example, if you break
a comment halfway thru remember to put // on the next line too). We often break lines
between the code and the comment (align the comment with tabs on the next line
so that it looks ok.) A good way to REDUCE a line is to trim away tabs between the
code and the comments.
Also, we use a red color to highlight new or modified code. Please avoid using green
colors for code that is removed (Yecht!). The reason for this is that we like our code-segments
to be cut-n-pastable into the compiler (think of newbies here).
5. Submit !
Ok, send it in to one of us (have a look in the news to see who has been most active recently,
some of us go into hibernation occassionally). We reserve the right to modify the content
and/or style of your material (and ultimately the right to post it or not so be nice to us :P )
|