Half-Life 2 Map Editing Optimization Guide

Some general notices

First things first, preventing is easier than fixing up later. Here are some tips:

Tip 1: Don't enclose your map in one huge box. Take a look at the image below. This is the skyline of an example map. Black are brushes, blue is the skybox.
Examples of skyboxes 1.) This map is pretty optimized. By making sure there is as little "wasted" space as possible you make sure the compile process doesn't waste time and effort on area's the player never gets to. With "wasted" space I mean space which is on the inside of your map, but the player never gets to. Large (high) skyboxes are not good, as the player never gets to them but the compile programs actually do work just in case the player does get to them. What a waste of time! You are far better at deciding where the player can or can't get to.
2.) This map is quite acceptable, though you can understand how situation 1 is much better, since it has the least amount of "wasted" space in it. This situation has one advantage though: Because there is skybox above the lower buildings, the compile tools will understand the player can see over the smaller buildings to see the big one. In situation 1, a player standing to the left of the leftmost building wouldn't be able to see the big building even if that building was twice as high.
3.) This situation is bad. DON'T DO THIS! There is tons of wasted space, and the green area below our level is completely useless. It may even cause the compile programs to think the player can see underneath the level, which causes the entire level to be drawn when that is not needed. Also, the red sides of the brushes are rendered, whereas in the other situations they would have been deleted because they were considered outside the level.
4.) This is the most ideal situation I can think of. The 3d-skybox allows the player to see all the buildings they can, while still making sure the playable area is as small as posslbe, thus giving us the least amount of wasted space. Remember that geometry ( =brushes ) in the 3d-skybox is much easier to render than geometry in the main level, this is because a 3d-skybox is scaled down to 1/16th of the normal size. This is why this is the best situation. If you have Counterstrike:source, check out de_aztec: You will be able to see how low the actual skybox is: all the roofs you see are actually part of the 3d-skybox. For a tutorial about 3d-skyboxes, check this out. Besides optimizing, 3d-skyboxes are also usefull for making the level appear much bigger than it actually is. If you have a skybox, also make a 3d-skybox, even if it's just for looks. Don't make the 3d-skybox too detailed though, as it gets rendered behind everything.
Don't try to blindly decrease the size of your skybox, players don't like to bump into the walls of your skybox. Even though it looks like the level is much bigger, no player can get through the skybox walls. So make sure the skybox is big enough to accomodate jumping player, thrown grenades, flinging physics objects and bodies flying through the air due to big explosions. Nothing is sadder than a flying body trying to get into orbit but getting stopped by the skybox walls!

Fix leaks

Fixing leaks increases compile times, because the biggest part of the compile process doesn't happen when leaks are present. So don't think leaks are a good thing because of that! Fixing leaks WILL increase map-speed. A tutorial about leaks, what they are and how to fix them, can be found here. If your map has leaks, the main optimizing process, vvis, will not work at all. Vvis is the process that calculates which parts of the level are visible from where, thus allowing the game to know which parts of the level don't need to be rendered at any time. Thus leaks cause more of the map to be rendered than needed, and that sucks.

Don't make brushes overlap

Overlapping brushes are a sign of sloppy work. Your level looks much cleaner without them, and you don't need to worry about compile tools getting a headache figuring out how these brushes should have been made. Ocassionally these brushes are visible ingame, resulting in wierd effects. Unless that is your goal, don't make brushes overlap. There are exceptions offcourse: triggers and other volumetric entities consisting of brushes can overlap each other no problem. As long as the overlapping brushes themselves are not visible, nothing is wrong. However, it is still a good thing to reduce this as much as possible, so you can work easier. Noone can work on a messy desk, nor can anyone with a messy map. Learn to do this and you'll thank yourself later.

Don't make displacements overlap

Displacements aren't cut to size like world-brushes, they are rendered as you make them. If you make a displacement under a house where noone can see it, it still gets rendered. ENTIRELY! Even when the visible part is 1 unit big!
Big displacements that go under walls and other big objects may be rendered more often than you desire!

Don't overdo dynamic lights

Dynamic lights are lights whose effects are calculated ingame. In HL2 and HL1 all lighting effects are calculated during the compiling process of the map, as opposed to during playing the map. This enables us to use precious CPU and GPU power for other things, like physics and AI, because the game doesn't have to calculate how dark a wall has to be while playing the map. However, sometimes we do want dynamic light effects, like swinging lights. For these situations the light_dynamic exists. This special light isn't pre-calculated, so it requires a lot more cpu/gpu than other kinds of lights. Therefore, use these sparingly. Also note that if you have lights with custom appearances (eg fading or flickering), you will also have a dynamic component: for these lights, only the 100% dark and the 100% lit state will be calculated. The rest of the states (eg 50% lit) will be calculated by the difference between the two pre-calculated states. Though not as hard to render as real dynamic lights, they are still harder to render than normal static lights. Games like FEAR or DOOM III use allmost solely dynamic lights, this is because their engine is much better at handling dynamic lights than source is. This is also why their shadows are so much better than those of source. However they do come at a high price, which is visible when comparing system requirements between source and Doom's engine, for instance.

Make brushes standard sizes

With standard meaning x^2, eg 8,16,32,64,96,128,256,512 units. The more you do that, the more your brushes fit the grid, the less leaks you will get and the less messy your map will look in the editor. It's also better when fitting textures, a texture looks hundreds of times better on a scale of 0,25 than on a scale of 0,26 ( though the difference seems minimal check it out ingame and be amazed of the difference in sharpness ). I suggest you map on a big grid (eg 16 units) and make it smaller when adding details, and larger again for walls etc. ( use [ and ] to quickly alter the size of the grid ).

Dont carve

Yes, I know. Carving brushes is very easy, and gives you results very fast. But if you can, DO IT YOURSELF. Hammer has the tendency to create hundreds of brushes extra when carving anything that isn't a simply box, and all those extra brushes won't do your map any good.
carving: Hammer  versus me

See the difference between Hammer 's carving ( left ) and mine ( right ) ? Not only does my version look better, it's also easier to scale, and gives you a less cluttered view, less chance of microleaks between those brushes. The advantages are limitless, so, once again: Don't carve. In the sole occasion where carving is ok, it's faster to do it yourself anyways. Please note that the number of brushes between the left and right situation doesn't always matter: If brush-sides match up nicely the compiler will try to merge the sides. Brush-sides that partly overlap, or have even the smallest of space between them, will not be merged though.

Don't overdo water

Water is very nice in source. But, because of that, also very hard to render. So when placing water, make it as small as possible. In multiplayer maps this means water is usually a no-go, especially in high-action area's, but it's okay in moderation. If you really want water, but find it causes to much lag ( makes your level run too slow ) there are a few things you can do:

Avoid open area's

If your entire level can be seen from a certain point there is not a lot of optimization you can do. Make sure there are actually brushes available which you can use to hide parts of your level behind so they don't need to be rendered. Try to block the player's view ( that of vvis to be exact ) with buildings or walls to make sure you can actually hide parts where the player isn't looking. ( with or without the use of entities and hints ) Also, adding lots of corners in straight hallways may enable you to optimize your map better, but it comes at a cost: Will your map still be any fun? Will it still look great? ( did it ever? ).

Plan ahead

It's always a good idea to start with a layout. With a layout you can determine where the high-action area's are. High-action area's shouldn't be too high in detail ( low framerates show best in action moments, one hardly notices low framerates when quietly walking through a hallway ), low-action area's should be mainly there to show off your mapping skills.
So make low-action area's high in detail ( as high as you can ), but keep more room for high-action area's where players meet enemies or physics stuff ( like explosions ).
You should playtest a lot to find out where these area's are, and offcourse, where you can spare more details.

«- Previous Chapter Next Chapter -»

© Webdesign Copyright by Kolezan, contents Copyright by Ralph 'zombie@computer' van Hoorn