Walking Target
2008-05-12 21:37:34
1. Maps should be tested to run on both windows and linux servers.
2. Maps should be fully packed. Optional: a readme.txt and a .res file that points to it. This allows people to dump a downloaded map directly into their maps folder.
3. Maps should have LDR lightmaps. ie. Not fullbright or HDR lightmaps only.
4. All map names should always be in lower case eg. dm_mymap_v3. This prevents redirect downloads causing problems on linux servers.
5. Maps should be prefixed with dm_ unless designed for a specific type of play:
tr_ for training maps
ctf_ for capture the flag
cp_ for capture point
6. Short, one word map names are more memorable and easier to manage than long multiple word names. For killboxes, it is traditional to place the word killbox after the dm prefix. eg. dm_killbox_mymap.
7. Maps that are in beta stage should be clearly labelled as such with the word beta as the suffix. eg. dm_mymap_beta1, dm_mymap_beta2.
8. Intial release of your map should just be the full name of the map. eg. dm_mymap
For maps that are a complete rebuild of an existing map from the ground up, it is common to use the suffix _reloaded.
9. Subsequent fixes or changes to the map should be released with a numbered suffix. once you decide on a suffix, stick with it. Common suffixes are "r" for revision and "v" for version. Try to avoid using "b" as this is often confused for beta. eg. dm_mymap_r1, dm_mymap_r2. Ent edited/server side fixes to maps are best avoided because the clients have no way of knowing which version they are playing until they test or check the issue that was fixed. Always rename and re-release if you change your map.
10. It is preferable to have one map that is balanced in such a way that it can be played in any mode, rather than multiple releases of the same map for different modes (ffa, 1v1, tdm etc).
2. Maps should be fully packed. Optional: a readme.txt and a .res file that points to it. This allows people to dump a downloaded map directly into their maps folder.
3. Maps should have LDR lightmaps. ie. Not fullbright or HDR lightmaps only.
4. All map names should always be in lower case eg. dm_mymap_v3. This prevents redirect downloads causing problems on linux servers.
5. Maps should be prefixed with dm_ unless designed for a specific type of play:
tr_ for training maps
ctf_ for capture the flag
cp_ for capture point
6. Short, one word map names are more memorable and easier to manage than long multiple word names. For killboxes, it is traditional to place the word killbox after the dm prefix. eg. dm_killbox_mymap.
7. Maps that are in beta stage should be clearly labelled as such with the word beta as the suffix. eg. dm_mymap_beta1, dm_mymap_beta2.
8. Intial release of your map should just be the full name of the map. eg. dm_mymap
For maps that are a complete rebuild of an existing map from the ground up, it is common to use the suffix _reloaded.
9. Subsequent fixes or changes to the map should be released with a numbered suffix. once you decide on a suffix, stick with it. Common suffixes are "r" for revision and "v" for version. Try to avoid using "b" as this is often confused for beta. eg. dm_mymap_r1, dm_mymap_r2. Ent edited/server side fixes to maps are best avoided because the clients have no way of knowing which version they are playing until they test or check the issue that was fixed. Always rename and re-release if you change your map.
10. It is preferable to have one map that is balanced in such a way that it can be played in any mode, rather than multiple releases of the same map for different modes (ffa, 1v1, tdm etc).