Adventures in Game Development: Level Design part II

I spent a good deal of time on research before working on my second attempt for a TF2 level. This time, the goal was to make it reasonably small and complete-able, just to get my hands dirty with the full dev cycle of a level. While I spent a good deal of time researching proper scaling, texturing, level layout, brushwork and asset placement, I didn't spend quite enough time researching optimization techniques before I jumped in again. I recently ironed out all the leaks in my level, to find that its compile requirements are so large that it practically froze my computer.

While frustrating, the reason behind it is actually quite cool. For performance reasons, the TF2 level compiler automatically breaks each area of the level into "visleafs", or visible chunks of the level. As it compiles, it determines which visleafs can be seen by other visleafs throughout the level, so at runtime only the areas that are already determined to be visible will render. If you've ever thought that TF2 levels tend to be kind of maze-like, it might be because they're made that way on purpose. By creating areas of the map that aren't possible to be seen in other parts (around a corner, behind a wall, etc), the CPU doesn't have to work as hard while you're playing the game, resulting in better performance.

Badwater Basin: This well-known map features a track that goes under a raised building. By lowering this location of the map, the area behind this building is impossible to see from where the picture was taken. "Don't draw the area behind this building" is a property baked into this section of the map, which reduces the load on the CPU by reducing culling calculations.

The problem that I ran into was my awareness of how visleafs are created. Hammer automatically divides the level up into probable chunks based on how solid, vision-blocking objects were placed. If everything in your level is a solid, vision-blocking object (which mine were), the divisions of the level will be quite small, quite ugly, and quite numerous. So numerous that it would practically crash your reasonably well-spec'd computer.

Fortunately, it's possible for me to retroactively go back and change the properties of my world-objects. The layout of my level was pretty open to begin with, which might have poorer performance because many places on the map have to draw almost the entire level. I'm hoping that the small size will make up for this oversight.

Here are some pictures of the level I've been working on, pre-detailed. I've spent around 25 hours reading up on Hammer and creating the level, and I look forward to fixing some of the necessary changes next week.