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.

Overview of the map

Early roof work

View from the lower level of the map

Inside one of the flag rooms. The third entrance is just behind the camera.

Level Designing for Team Fortress 2

This week is my week off between Game Design Summer Camps, and I took a bit of a break from applying to jobs to try to learn some new tech. 

I got back into Team Fortress 2 last week and wanted to give a stab at making my own level. As the Hammer editor was downloading from Steam, I banged out this mock-up of a level in Maya:

The whole level sketching process took about 2 hours, and I was reasonably happy with the result. The map style is Capture the Flag, so I only bothered fleshing out one half of the map, as they're symmetrical.

After downloading Hammer, I tried my hand at creating the level with the assistance of a ton of well-written guides on how to use Hammer. It was much slower-going, and after putting in about 12 hours, the many errors of an un-experienced Hammer editor began to surface. I'll list off what I did wrong, but first I'd like to show off my first attempt at creating a level for Team Fortress 2:

Similar view to the mock-up

View from the Sniper's Perch

Flag room, with a drop-down platform for enemy access.

It definitely doesn't look terrific, but this is where I started to get hung up. Hammer doesn't allow you to resize any of the pre-made props that exist in the editor, so levels tend to be at the mercy of the preloaded props, which my level was not. This was at the center of my frustration with making this map a reality, as I wasn't familiar with the scale nor the props of a typical level. I began by roughly sketching out most of the platforms of the level, only to find that they were too big. Scaling the entire level down worked for a while after I created all the major pieces in-line with each other, but I again ran into the problem of mis-fitting props in the level.

I did learn a lot, though, and consider it a relatively successful first learning attempt. Now that I know what kinds of things Hammer is and is not good at, I'm going to start over on a more humble map with many of these restrictions in mind.