introduction | entities | environment | gameplay | performance | publishing
Once your map is finally ready for public consumption, it's time for you to build your public release. First, always make sure you're compiling your final map using both VIS and LIGHT... don't skip the VIS stage, and don't use -fastvis. The LIGHT stage is essential if you want your map to look right.
The first thing you want to do when releasing your map is to build a PK3 that will hold all the files needed for players to use your level. A PK3 is actually a ZIP file with a different extension, so working with it should seem pretty simple if you're used to dealing with archives. You can create the file with any software that works with ZIP files, such as WinZip, but there are programs such as PakScape (available in the Quake 3 downloads section here) that are designed specifically for Quake. The directory structure inside of a PK3 can be quite complex depending on how many files you're including, but by looking at Quake 3's PAK0.PK3 and the PK3's of other custom maps, you can get a general idea of what yours should look like. What follows is a list of the various files that your PK3 will have, along with some screenshots to help you along.
Custom Media
For starters, you must include all of your map's custom media. This includes textures, shaders, sounds, or anything else that you've used in your map that isn't included with Quake 3's retail package. It actually doesn't matter where you place these files, just so long as your map knows where to find them. Generally, though, you should follow this guide below:
Textures: */textures/mapname/
Sounds: */sounds/mapname/
Shaders: */scripts/mapname/
Models: */models/mapname/
Notice that under each main folder there is a folder with the map's BSP name. If you place your custom media in these folders, it will prevent your files from overwriting someone else's - or, for that matter, being overwritten by someone else's. An example of this can be seen in the first screenshot above. As you're doing this, just remember that the paths to these files must be correct in the map itself, as well as in any shaders you may be using.
Levelshots
One of the things that should be included with your map is a levelshot. A levelshot is a small (traditionally 128x128, although the size doesn't really matter) screenshot of your map that is displayed in the map selection menu and as a background while your map is loading. The image should either be a JPEG or a TGA file... typically, JPEG is the best format to use. You can add text to the image that won't be covered by Quake 3's display - if you do this, you should probably make the levelshot at least 640x480 so that its quality won't be lost when it's stretched to whatever resolution the player is using. It should be in the */levelshots/ folder of the PK3 and bear the same name as your map's BSP. If your map's name is "mymap.bsp", then the levelshot should be named "mymap.jpg". This is the only way Quake 3 has of identifying the image, so this format must be followed.
Arena Scripts
Another thing you need in your PK3 is an arena script - this is a short text file that gives Quake 3 different kinds of information about your map. You can type these by hand, or use a program such as ArenaForge to generate them automatically. The script should be placed in the */scripts/ folder of the PK3.
Documentation
Last but not least, your PK3 should include is a "readme", or a descriptive text file (usually named "ReadMe.txt"). These are very important, as they allow you to attach your name to your work and reserve certain legal rights. At the very least, the file should contain your name, the date the map was released, a website players can find it at (if you have one), your email address, and some basic information about the map such as the recommended number of players, supported gameplay types, and so on. You should also include legal information. Typically, a copyright date is given along with a statement that warns users against distributing the map through profitable means. Other information can include a development log with information about software that was used, people who tested the map, and changes throughout the beta versions. In addition to being in the root directory of the PK3 file, the readme should also be placed in the ZIP archive that the map is being distributed in. You should look at some other mappers' readme files to get some ideas on how to format your own.
Beta Releases
Before you make a final release of your map, you should distribute at least one or two beta versions that players can test and give you feedback on. If you release a map without releasing a beta first, you're making a pretty big mistake - not only do betas greatly reduce the chance of unnoticed bugs showing up in your map, but they also allow users to give you feedback on the basic layout and design of the arena - and, since they're the ones who are going to be using it, you want to hear what they have to say. While releasing a test version, make sure you clearly indicate that it's a beta so players will understand that it's not the final version. The best places to distribute these are message boards or newsgroups, as few map review sites will feature them.
When you get feedback, don't make the mistake of taking criticism too personally... most likely, your critic has a good point. Besides, you have to remember that a lot of people are going to think, "man, this is an awesome map!", but they aren't going to tell you that. The people who will feel the most compelled to respond are going to be the ones that noticed something wrong. Take all your criticism into consideration, and you'll find that you can greatly improve your map.
If you are interested in having your map featured here on The Deathmatch Zone, send an email to dzone@denken.com and you can have it added to the Map Reviews area.
-end-
page 6 of 6
previous page: performance
