Plugging Leaks
If your level does develop a leak, you can use a leak file generated by the ZHLT Compile tools to help find it. Once the ZHLT Compile tools make its leak file, load it into hammer using the Map menu to select Load Point File. This helps you to follow the path that appears until you find the hole.
Plugging leaks is important for three reasons. First, leaks can cause parts of the outer shell to be visible inside the level, unnecessarily increasing your counts. Second, leaks keep the levels outer shell from being removed by ZHLT Compile tools, increasing the size of the levels .BSP file on disk. Last, if ZHLT Compile tools have to do visibility calculations for the outer shell, it will take a great deal longer to complete. It pays to plug your leaks.
Another concern is a factor called overdraw, which is the number of polygons drawn on screen that are actually out of the players view behind other polygons. This is related closely to the visibility optimisations referred to previously. You can often find high levels of overdraw in rooms with lots of detail: columns, low walls, complex fixtures and cracks can all lead to overdrawing. Overdraw in a scene is measured using the R_SPEEDS 1 console command. In the development of the game Half Life, for instance, values of 400 -600 here were considered acceptable and values of 800 -1250 were danger signs. Once again, testing on your target platform to obtain figures for your own game would be wise.
Besides geometry related factors that may slow down your game when its running, you can also get significant slow downs if you use too many textures or several overlarge textures in a scene. Even in the age of AGP, if you use a 512x512 texture for everything from tiles on the bathroom floor to murals to the nameplate on a door, the game will run more slowly. As with many problems, this is best addressed in the design stages rather than in the testing stage.
You should try to resist the urge to use the largest texture possible and instead work to find a balance between a texture that looks good and is small in size. Objects that wont get much scrutiny like floor /ceiling tiles, wall to wall carpets and grass should usually be given small textures. Objects that the player will focus on (view screens with data, pictures, signs) can use higher resolution textures. The console command impulse 202 provides information on textures for help in troubleshooting.
Entities can also affect game performance. If you build a huge particle fountain that creates 1000 particles every second with a decay time of 10 seconds on each particle, the engine is going to be very busy keeping track of the particles. Likewise, large, moving objects such as props made from World Models can slow the engine down as it tries to manage their physics.
Character models and AI can also affect frame rate. A level that runs fine with just the player on it can bog down seriously when two very intelligent AI enemies are added to it. Likewise, a Boss character with thousands of pollies in her character model will slow the engine much more than a minor character with just a few hundred. Be careful how you code, design and place your AI. Also, be sure to test the results to make sure you haven 't stressed the system too much.
As mentioned before, optimisation is more art than science, and it takes practice. The warning signs of trouble you should always heed are low frame rates; high polygon counts in a scene, and sudden jumps in the length of time it takes to process your level. Any of these should make you take notice. Immediately backtrack and figure out what has caused the issue. Even if you don 't do anything to correct it at the time, performance issues are almost always easier to fix if they 're identified early. It is heartbreaking to have to discard a level that is completed but completely unworkable, and you will do so if you don 't pay careful attention to optimisation throughout the construction process.
