Compiling:Healthy Map

The fact that your map compiles fine and is playable doesn’t mean it’s good. There are several factors which define your map as healthy or unhealthy. An unhealthy map has poor fps, huge .pk3 size and long loading time. Your objective is to create a map as small and lean as possible — great visuals or loads of gimmicks will not ensure a long popular life on their own.

Don’t build a big box filled with smaller boxes

The first map people build will usually conform to the infamous “box map” stereotype — a map where every area can see most other areas, resulting in most of the map (and the players in it!) being drawn at any moment. Quake 3 engine (and by extension Urban Terror) works best with maps that are built like corridors or series of rooms connected by doorways. Fear not for your artistic vision, because most maps you’ve played indeed do look like this without you being able to realize this; their corridorness is simply well hidden.

For an old-but-good article about building a reasonable-looking yet efficient outdoors map, see SweetnutZ’s site. For a more in-depth explanation of how the Q3 vis culling works, see the Nib’s World article (Wayback copy, original site is dead).

Always use unique folder names and shader paths

Breaking other people’s maps — and the old versions of your own map(s) — is a very common thing beginners do. While you have no control over others you can still do your best to aovid conflicts by using only folder and map names that are unique to your map (and its current version). I.e., for a map named ut4_example_b1, you would:

• put all your textures in textures/ut4_example_b1
• put all your sounds in sounds/ut4_example_b1
• put all your models in models/ut4_example_b1
• put all your shaders in scripts/ut4_example_b1.shader
• and use only textures/ut4_example_b1 in your shader paths

Doing this is a bit more work-intensive than just igoring possible conflicts, but it pays off. To see what I’m talking about you can download ut4_tohunga_b8 and ut4_tohunga_b9 — the newer version causes flickering “missing texture” on the walls of the older one. (As you can see, even an accomplished mapper like Delirium can make this mistake.)

The same principles also apply to recycled stuff — if you reuse something from another map and change it in any way, rename anything that might cause a conflict!

Use as few assets from other maps as possible

Many mappers have released a map that looks perfectly fine on their system but is completely unplayable for anyone else who doesn’t have all those other maps that lent their shaders, textures and sounds. (This is also a good argument for having a separate clean install for mapping.) Even if you restrict yourself to only textures found in the default installation, your map can and will break when the game is updated. There are even some maps that rely on some particular textures only found in 4.1, displaying copious amounts of tricolors when played in 4.2. The older the map compared to the game version, the worse it gets.

All texture sizes must be power of 2

Power-of-two values are 64, 128, 256, 512, 1024, 2048 — and so forth, but you can’t use anything larger in UrT (in fact even modern games rarely use larger sizes). Textures can of course have differing height and width values (16×128, 1024×512, etc).

The way Quake 3 engine works, non-conforming textures are scaled down to the nearest power-of-two values. For example, a 1024×1023 texture will end up looking just like a 512×512 texture, except its filesize remains as large as that of a 1024×1024 texture.

FIXME: Delirium’s demonstration (dead link, no Wayback copy)

Don’t include model files (.ase, .md3, .qc)

Models are “baked” into the BSP during compilation so the original files would be useless, only increasing the PK3 size. (You still need to include the textures though.)

Remove unused shaders and textures

During the development process you will most likely try out many shaders. Some of them will not make it to the final map, yet if they’re included in the .shader file they will still get loaded. The same applies to textures — you can reduce the PK3 size quite a bit by making sure only files that are needed are included.

Don’t create shaders for textures that don’t need them

 textures/infiltration/bunkerwall3
 {
 	{
 		map $lightmap
 	}
 	{
 		map textures/infiltration/bunkerwall3.jpg
 		blendFunc filter
 	}
 }

This shader represents completely normal, common, solid wall. Don’t write shaders for them, because texture*lightmap is the standard format. It will save loading time and PK3 space.

Don’t leave textured surfaces on invisible brushes sides

Players won’t see everything during gameplay, make sure you texture these surfaces with caulk.

This is what player see during game. He sees building, but not complete roof:

In ghost mode you can see, that mapper textured roof top with caulk texture:

Roof top cannot be seen during gameplay, so it does not need to be textured. Keep that rule in your mind, it will increase FPS count on your map.

Use areaportals to cull rooms that have all their doors shut

Learn how to use areaportals and use them in rooms with doors. It will slightly increase FPS on your map. (This suggestion was much more relevant back in the day when Quake 3 was new and Urban Terror could bring a quite beefy machine to its knees. Nonetheless, it can be useful in certain cases.)