Releasing a Map

From Empires Wiki
Revision as of 01:39, 13 May 2009 by Administrator (talk | contribs) (started porting my guide to the wiki)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Template:Contents

Introduction

This is supposed to guide you though some convetions that should be used before you release a map. This won't explain how to create the map itself, however it will provide links and useful information which can be used during the mapping process. This is a list of what should be done.

Tutorial

Naming your map

During the mapping process think about naming of your map. A map name usually consists of 3 parts, prefix(es), the namename and suffix(es). While there are no strict rules on naming, you should have a look at the following guidelines for determining how to name your map:

Map Prefix(es)

You should use something to represent the game type played. As of now empires maps don't follow these convetions, however tagging a map as emp_ctf_mapname (for example) makes clear which gametype is run on the particular map.

Map Name

I encourage you not to add your own (nick-)name to the maptitle because it makes the mapname senselessly complicated in the most cases (If you are afraid of copyright theft or anything like that, put your name into the map in several places (brushes, models, decals, descriptions) and protect your map against decompiles.). Apart from that you should stick to a short and meaningful title dedicated the style of the map (For example: emp_isle takes place on an island). Also you should try to use real words instead of random characters ("Wrong" example: emp_roflwtf!BBQz3).

Suffix(es)

The suffix of a map should be related to the map's version. The first part of the suffix should represent the current state the map is in (for example, Alpha, Beta or "Release Candiate"). The 2nd part should be the curret release number (according to its state). Here is a list of the Suffixes I recommend to use:

  • prealpha
    • This should be used on a very early release. A Pre-Alpha shouldn't be released unless you want to preview your map. In addition, a pre-alpha usually lacks most of the maps planned feature and is not intended to be playable.
  • a or alpha
    • Alphas are early releases, it should be avoided to release alphas. Alphas can be playable (but don't have to) to a certain extent, but it is likly that they contain many bugs or are quite imblanced. In addition, alphas lack many features planned for newer versions.
  • b or beta
    • Betas are early releases. Betas are playable, but are still unblanced, bugged or not feature complete.
  • rc
    • RCs (or Release Candiates) are pre-final releases to sort out any remaining bugs or issues. These should be optimised and feature complete.
  • final (or no suffix)
    • Final maps are really final; they are thoughly tested, feature completed and all bugs have been sorted out. Usually it means that you stopped working on the map aswell and that there are no future versions.
    • Personally I recommend not to use a tag if you intend a map release to be final.
  • fix (special case)
    • fix suffixes should be used the map release a small, but required release to remove game-breaking game bugs or imbalances. This suffix should be added in addition (for example: emp_mymap_b4_fix).
  • v2, v3, ..., vn (n being any number)
    • You should use a vn tag if you deceided to continue work on a previously final map - or if you intent the release to be an alternate version of your map (you might want to use emp_mymap2 instead). However personally I dislike seeing this unless it's really required.

Testing your map for consistency

This means that you try to get rid of any errors that occur. These include, but are not limited to:

Compile Errors

Generally all compile errors should be removed as they are there for a reason. Errors that can be ignored are the exception.

Console Errors

This is pretty much the same as for compile errors. Console errors are there for a reason and shouldn't be ingored. However these are usually less harmful compared to compile error, but they still cause problems or notify you of unintended baviour.

Here is a list of some common errors:

 SOLID_VPHYSICS static prop with no vphysics model! (<modelname>)

This means your models won't have collisions enabled. You can fix this by changing collisions of the partical prop_static to bounding box or no collisions.


Leaks

Leaks are caused in case some parts of your inner map touch the void (the black area around). Leaks generally can cause some very wierd map behavor such as horrible framerates, objects falling though floors, wierd looks or insane compile times. Therefore leaks should be fixed in any case.


Links & Further Reading

http://www.interlopers.net/errors/ http://developer.valvesoftware.com/wiki/Leak