Releasing a Map

From Empires Wiki
Revision as of 14:04, 8 June 2009 by John Shandy` (talk | contribs) (Expliots)

Jump to: navigation, search



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.


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).


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.

There are more suffixes to be used, however I recommend avoiding complex version numbers as these over-complicate your map name (examples: emp_mymap.005, emp_mymap_v1.00.005). Using these kinds of complex version numbers rarly makes sense on a map as it's unlikly to reach hundrets of map release - if you really pump out a new release every day, you should think about doing less (less is more sometimes ;) ).

Testing your map for consistency

This means that you try to get rid of any errors/exploits 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 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.


Possible map exploits that can be used to gain an unfair advantage. This can be achieved by building a wall to get to some places you are not supposed to go to and building stuff there. In general this can be prevented by using clip textures/invisble textures/comm no build areas where you want the players not go or commanders not to drop buildings.


It is very important that you optimise your map to it's fullest. Nobody wants to play a laggy map. Even if you think fps are ok you should try to optimise your map even further. Keep in mind there might be situation where 64 players and 20 tanks aswell as some buildings meet in the same place hogging down the frames. Your goal should be to achieve very high fps so it leaves enough resources for any situation you can think of.

I won't describe the following optimisation techniques in detail, however all of these should be considered to be used in the map.





Fading Distances

Additional Resources

There are quite a few guides out there explaining the optimisation process in detail. See the following links for details:

Creating Optional Map Resources

To provide a high quality release you should create any optional map resources such as the minimap or maplist thumpnails.

Map List Thumpnail

Read the following link on how to do it:

Testing your map

Make sure to test your map thoughly. This means you are not only going around to test it your self, but also test it with your friends or give it to experienced mappers to test it for you. The point of this that you possibly sort out any additonal bugs you haven't found. Also getting a second always helps to improve your map

Final Compile

This should be done because it should give the best looks. Keep in mind final compiles will take quite some time. A final compile means:

  • Full VBSP
  • Full VVIS
  • Final VRAD (LDR mode)
  • Final VRAD (HDR mode)
  • Compiled Cubemaps afterwards

Yet another test

You should check the map for any problems that occur again. Sometimes problems occur due to the compile even if they haven't before. If you find any problems fix these before going on. I recommend to do a backup in case everything goes allright at this state before going on with the next steps.


Bspzipping allows you to zip custom files used in your map into the mapachieve. There are pros and cons for bspzipping, however I highly recommend to make use of bspzipping.

Further reading on bspzipping:


  • Increases your mapsize a lot, eventually causing your map to be too huge (64mb+) to be downloaded on servers without FastDL enabled (however as most emp maps are too big to be downloaded anyway and all (decent) servers use FastDL this can be ignored usually)
  • Any bspzipped content can't be used in future version of your map, causing them to be redownloaded.


  • You never need to put a bspzipped file into a .res file which prevents work with .res files, but also avoid errors in the res file due to the fact your res size includes less files.
  • As soon these are bspzipped, they can't be forgotten to be included in a zip file.
  • Other mappers can't use bspzipped files UNLESS they extract them from the map. This prevents using custom textures if you don't want to - incase you don't know its custom, but some other map added it to your materials folder.
  • In case someone wants to reduce size of their empires (server/client) installation, they don't need to check the res file to remove any additional files the map has added and only a quick delete of the map itself is required.

Test No. 3

At this point you should check your map again for any possible problems again. Sometimes custom programms for bspzipping (if you use any) corrupt your map achieve causing wierd problems with your map. Incase this happens you should think about bspzipping manually and step by step to figure out what file is failing/causing the problems.

.res (Resource) file creation

Now you need to create the .res file to allow clients to download any content which hasn't been bspzipped into your file. Using a .res file has pros and cons too:


  • Better way to use content that is shared on many maps (skyboxes for example); this also saves space compared to bspzipping, but only IF the specified file used in multiple mapss


  • Large .res files are hard-to-read and quite messy. Its possible to get lost (and missing some files)
  • Every item in a res file needs to be deleted manually by the user/server admin incase they want to remove the map complety
  • Every item needs to be compressed for fastdownload on a server seperatly
  • Incase a file is removed from server/user's empires folder it may cause problems with another map which uses the file

bz2 compression

You should provide an extra download or folder (called fastdl) in your map release to reduce the work for server admins running a server with fastdownloads. The fastdl folder should contain every file compressed with bzip2 using ULTRA compression power except for very small files (generally .txt, .res and .vmt files shouldn't be compressed).

I just want to note here that it will reduce the work for server admins sigifnicanlty (especially if you have a lot of custom files) making it easier for them to put on your maps on their server. Basically server admins don't want or need their time to spend zipping stuff to upload it. Keep in mind that you need to do this once in your release, but every single admin needs to do this.

Create a Map Achieve

At this point you need to create a mapachieve. I recommend creating a folder and move everything in there you want to compress. As for the compression format it self I recommend to use a popular format like .zip, .rar or .7z. Personally I recommend using 7zip since it provides the best compression causing your map achieve to be faster to download since it's small (keep in mind, that not everyone has a fast connection).

Files which should be included

  • map achieve
  • custom content files (such as mapoverview, custom texturs and models, etc)

Files which are optional, but should be present

  • fastdl/
  • readme.txt (or html)

Files which shouldn't be in the achieve

  • screenshots
  • old versions
  • files not required to play (for example: .vmf,.prt,.log)

Achieve & Map Consistency Check

Again, it's time to check everything for it's consistency so you don't release a broken achieve or map.

  • Create a backup of your current files in your empiers folder. This is required for the next step.
  • Delete any map files from your empires folder.
  • Unpack your achieve and copy it over.
  • Now try to run your map and see whether something is missing; if something is missing fix the achieve and run it again
  • Send the achieve to your friends to test it.
  • You also might want to send it to a server owner to test the server compability (whether the res file and/or fastdl files work) for you.

Take Screenshots

Taking screeshots is an important part of a releasing a map. You should try to obtain high quality screenshots; good screenshots will make your map look more appealing to server admins and player resuling in testing it out (and eventually putting it on their server). Also you should provide enough screenshots so people can get a good impression of the map, however multiple screenshots of the same place should be avoided.

Apart from that I recommend you do the following to improve your screenshot quality:

  • Set your game to it's fullest: 16xAA, 16xAF, very high resolution and everything set to enabled and maximum.
  • Disable your hud (type cl_showhud 0 in your console)
  • Disable netgraph (type net_graph 0 in your console)
  • Set jpeg_quality to 100 (type jpeg_quality 100 in your console)
  • Go specator to remove any remaing elements on your screen (such as the weapon)

Now you are ready to take the screenshots. Try to take a lot, even multiple of the same place. As soon you are done, you should select the best screenshots to provide them in release threads or file submissions later on. If you want, you can also edit your screenshots to make them look even better or to add copy right elements (i.e. watermark, etc.)

Uploading the Map

Time to upload. Try to upload your map to many mirrors and sites as possible to provide a wide spread coverarge. Also you should try to use mirros which keep files for a long time so your map won't disappear after a certain time.

I recommend using since it will automatically upload the map to many mirrors at once. Also it might help to boost the mods popularity as fpsbanana is a well-known source for anything related to FPS game, especially source-games.

Uploading Screenshots

While some sites already required screenshots to be uploaded for uploading the map achieve I recommend uploading all your screenshots to a sperate site so you can provide them in your release thread as additional resources people can look at. Basically the same rules compared to uploading a map apply: try to get a site which keeps the screenshots a long time so they don't get lost.

Map Announcement & Release Threads

The time has come to announce your map to the world. You have done the preperation and now you are almost done with your job. However, to increase the popularity and knowlege about your map I recommend to create well-structured announcement threads in every suitable board you frequent. These announcements should contain information about your map; everything that a potentential downloder might want to know: background story, changelog, planned features, compile time, progams using desgin process, multiple mirrors, screenshots, known issues (if any occur after the release), etc.

Apart from release threads you also might want to publish short announcement in steams groups.


This guide has been created by Omega_K2.

Links & Further Reading