VERC: Writing Collective Articles Last edited 16 years ago2003-02-11 20:28:00 UTC by Penguinboy Penguinboy

This article was recovered from an archive and needs to be reviewed

  1. The formatting may be incorrect as it was automatically converted to WikiCode from HTML, it needs to be revised and reformatted
  2. Some information may be out of date as it was written before Half-Life was available on Steam
  3. After the article is re-formatted and updated for Steam HL, remove this notice
  4. Please do not remove the archive notice from the bottom of the article.
  5. Some archive articles are no longer useful, or they duplicate information from other tutorials and entity guides. In this case, delete the page after merging any relevant information into other pages. Contact an admin to delete a page.


As anyone who has had an Article rejected by the Collective editors will know, they can be fairly stingy. This short guide is aimed at people who might not have written any articles like these before, and are perhaps unsure about how to approach getting their idea for an article into a form and standard suitable for publication. You don?t have to be a great writer to write quality technical articles, although there are some points to be aware of in order to present your information in a way which is accessible and useful. The examples here are all related to mapping, since that is the area in which the author has experience; the general advice, however, should be equally useful for someone thinking of writing an article relating to other areas.


Perhaps the most important practical advice I can give is to remember that you are not writing a forum post. There are infinite different forms an article could take, and you need to be clearly aware of what the purpose of your article is. It is important that you choose a suitable format for the scope of information you are going to convey. The majority of articles rejected fail on this point: for example, a rambling page long discussion on clip brushes would have been more usefully presented as short step by step guide, with an introduction explaining which areas of maps the technique is often used for. Conversely, trying to write a step by step guide which explains the advantages and disadvantages of different techniques for reducing r_speeds would be equally confused. If your article is divided into clearly defined paragraphs, or sorted under subheadings, then you are on the right tracks. Just do whatever you feel makes the most sense, remembering that a brief introduction never goes amiss. It is also important to check that there is not an existing Collective article that covers the same ground as you are going to, as you would be surprised at the number of duplicate articles that are submitted.

Writing Style

Unless you are writing an especially personal article, your writing should be fairly formal. As technical writing, your goal is to present your information in the clearest possible way, which means the fewest words necessary. In order to do this, consider the level of your intended reader. If you are writing about an advanced technique, consider stating briefly in the introduction what the reader should already understand. In general, try to avoid repeating points throughout the article, possibly by putting any general points or warnings in a note at the top. Stylistically, short and clear sentences are what you are aiming for.

Often when writing a tutorial type article, it will be clearer to divide the instructions into steps, rather than presenting them as prose. Professional technical writers study for years learning exactly how many steps to have, and how wide each step should be. Thankfully, though, if you don?t have a degree, common sense will often do the job just as well (bear in mind that this is only a general rule; keyhole brain surgery, for example, is rarely successful unless carried about by a certified professional). If you are writing an elementary article, you might consider it necessary to say ?Goto Tools -> Transform, enter ?90? in the ?Z Axis? field, then hit OK?, whereas in a more advanced article you would just say ?Flip the brush 90 degrees on the Z Axis?. It is not something to worry about, as the editors who look over the article will inform you if you have misjudged the steps.


There is an article available here (Link: index.php?go=safe_css) which explains how to use CSS to format your articles. If you don't need that power, use the standard formatting tags. Subheadings and so on should be suitably marked up, but stay clear of playing around with the text colour. For a longer article, a miniature Table Of Contents with links to the subsections could be a nice touch. Stay clear of using forum-style text annotation, such as highlighting points with stars. **NOTE, I only tested this shearing technique on Poodle V2.3!!!**, just isn't stylish. Important general points could be enclosed in a formatted box if you really want them to stand out:


The shearing technique explained in this article has been tested on Poodle V2.3. If you have upgraded to the new Pooch 3 range (pictured), proceed with caution.

Don?t forget about pictures, as a few carefully chosen and annotated screen captures can make certain descriptions infinitely easier to follow. Pictures also have the general effect of making your article more inviting to read. Lastly, there is no excuse for spelling errors in submitted articles. Free Word Processors, such as OpenOffice (Link: , are readily available, so run your article through it?s spell checker before you submit.

While we're on the topic of images, how you use them is just as important as when you use them. First, the maximum width for images in a Collective article is 500 pixels. If this isn't large enough, you should consider using thumbnail images linked to larger versions. Also consider how the images will look in the article. Rather than putting in a string of thumbnail images, one per line, it would look much better this way:

| (Link: test.jpg)
| (Link: test.jpg)
| (Link: test.jpg)

(click above for larger images)

This method also results in better flow for the article as the images aren't as much of a break in the rhythm.


Perhaps one of the most important aspects of an article, it should be technically accurate . This doesn't require a whole lot of explanation - make sure what you're saying actually works . Granted this is more commonly seen in forum posts, but quite often you'll see things put forward as fact that simply don't hold up when tested. The best example of this is when people stubbornly declare that the proper scale for Half-Life mapping is 1 unit = 1 inch. I wish it were true, and most of the time the people will stubbornly argue about fields of view and human sight calculations, but if they simply built some area to scale and looked at it in-game, the whole argument would have been avoided.


Hopefully some of this basic advice will have proved useful, and encouraged someone who might not have otherwise considered writing an article to do so. And if not, at least you have seen a rather fine picture of the new Pooch.
This article was originally published on the Valve Editing Resource Collective (VERC).
TWHL only archives articles from defunct websites. For more information on TWHL's archiving efforts, please visit the TWHL Archiving Project page.


You must log in to post a comment. You can login or register a new account.