Readme 1st: Common TF2 mapping mistakes and how to fix them

Brandished

L5: Dapper Member
Jan 19, 2008
234
311
I've seen all of these in WAAAAAAAAAY too many maps so far (including my own :p) and I and others are tired of constantly putting these in map assessments over and over again. I've listed the most common ones I could think of here. Before asking a question in the forums or having your map assessed, please save yourself some time and read through this list to make sure your map doesn't have any of these problems.


1. Leaks

Leaks can create a huge number of problems in a map, anywhere from invisible water to weird, broken lighting. If you have an odd issue with your map, always start by checking the compile log. If you're fairly new to HL2 mapping, there's a nice compile log checker here where you can get a read-out on your log. If you do happen to have a leak in your map, but are having trouble getting rid of it, there's a very nice guide on fixing them here: http://developer.valvesoftware.com/wiki/Leaks

I'm lazy and usually just do this after every compile to see if a pointfile (mapname.lin) was created (aka there was a leak) rather then reading through the compiling notes.


2. HL2 Sky

By default, Hammer adds the same Half-Life 2 sky to every new map you create. Fixing this is rather easy, just go to Map > Map Properties and replace "sky_day01_01" with a TF2 sky. You can choose from this reference list here: https://developer.valvesoftware.com/wiki/Sky_list#team_fortress_2_materials.gcf


3. Little or no direction signs

Running around in circles trying to find map objectives is not my idea of a fun time and not most other peoples either. This is one of the main reasons all the orange maps are so popular, new players (a good portion of the TF2 player base) can figure out their layout in a few seconds. I'm not saying over-simplify a map, but just having a few direction signs and markers in a map will drastically improve your maps adoption rate. The most common directions are prop_static's with the sign_gameplay worldmodel, though there are a few other prop_statics to choose from, as well as several good decals/overlays.

Note: All the "signs_gameplay" models are set to "Battlements" by default, change the skin value and hit "apply" to see the other sign types.


4. Huge unavoidable open areas

While this might work in other mods (and people like to have those great panoramas), huge open areas will give snipers an overwhelming advantage over the other classes. You can still have them, but if you do, also have at least one side route to bypass them so everyone doesn't have to play dodge the sniper bullet. Open areas should also have some form of cover at least every 1000~1500 units for players to hide behind and regroup and for spies to stop while recharging their cloak.


5. Repeating\Unvarying textures and terrain

Large flat walls, floors, and displacements are nearly impossible to get to look nice, especially with only one, evenly lit, texture. There are a few ways to fix this, you aren't stuck only using different textures, you can add geometry and props to break up flat surfaces, and use different lighting strengths to create shadow contrasts as well.


6. Fullbright Lighting

"But my map does have lighting!" If there are no shadows, no, no it doesn't. If there are no light entities anywhere in a map Hammer will give the map an ugly, fullbright lighting during the compile process by default (this can also happen if the map had a leak, see #1). Not only does fullbright lighting make your map look ugly and hard to discern between brush faces with the same texture, but it can also increase the file size of your map as well. If your not sure if your map is fullbright or not, load up your map in TF2, bring up the console screen, and type in "mat_fullbright 0", if a good portion of your map turns completely black, there is no lighting in it. A single light or light_spot entity is rarely enough for a whole map though, you have to space many, many light entities throughout your whole map to fully light it. The exception being if you have a mostly outdoor map, then a single light_env actually might be enough to light your map. Good lighitng will drastically improve the look of almost any map and is usually worth the time involved.

Lighting tutorials:
Advanced Lighting (Interlopers)


7. No cubemaps

Weird purple/pink reflections are a dead giveaway for a map with either a lack of env_cubemaps, or a map with cubemaps that haven't been properly built. For reflections off of surfaces and models to work right, there needs to be a env_cubemap entity in the area. See here for more info: http://developer.valvesoftware.com/wiki/Cubemap.


8. Model textures on brushes

Note: Hammer should filter out model textures by default, so you shouldn't have to worry about this.


The texture browser contains model textures that go on models as well as regular textures meant for brush work. There's no one to blame but Valve for this and they are working on a fix, but until then, make sure the textures you're using
do not have "model" in their name; ie "models/props_mining/wood_beam03". Model textures will not look right in-game when used on brushwork, a tell-tale sign of model textures on a brush is a flickering brush face that will change in contrast when viewed from different angles, becoming oddly dark or bright.


9. Improperly set-up spawn rooms

If you are making a map for public servers, if players die in the spawn room upon changing classes, you have a problem. If all the players on a team spawn in the exact same location, you have a problem. If during a round players are repeatedly being killed by the other team before they've even left their spawn room, you have a problem. The problem is the respawn room in your map is not set-up properly, see here for a nice tutorial.


10. Little or no resupply items

For non-arena maps, avoid forcing players to die or rely solely on medics and engineers to refill their ammo and health. Make sure you have a few item_healthkit's and item_ammopack's entities scattered around your map, especially near choke points and map objectives. Conversely, don't go overboard and place them all over the place, choose there locations carefully.
 
Last edited by a moderator:

Brandished

L5: Dapper Member
Jan 19, 2008
234
311
11. Single narrow routes with no side routes

This kind of goes hand in hand with "Huge unavoidable open areas", but is not as common. All major objectives should have at least two different route options to reach them. A narrow route will almost always be a choke point and forcing an entire team to travel through a single narrow route to reach an objective will usually result in constant stalemates or a lopsided map (the same team color always winning). Avoid funneling multiple routes through a single narrow entryway on route to objectives as well, as this can also lead to stalemate land.


12. Paper thin walls between accessible areas

Can you guess which wall the soldier is hiding behind? The problem with the TF2 and a few other Source based games is players do not flatten against a wall. While walls do stop movement, they won't necessarily stop the player and weapon models from sticking through them. If a player can see both sides of the wall and access at least one of them, try to make the wall at least 16 units thick or more to avoid the above situation. If only one side is easily accessible and less then 16 units thick, you can work around this restriction by player-clipping the accessible side to keep players from pressing directly against the wall.


13. Invisible Barriers

If you have what would appear as an accessible path in-game blocked off with a player clip, nodraw, skybox or similar unseen surface, include some form of visible representation for the barrier as well, eg: a small fence, rope, ruble, etc.


14. Small or impassible entryways and corridors

This is a common mistake for mappers coming to TF2 from other Source based games such as CSS or HL2DM. The player model sizes in TF2 are much larger then those in many other Source based games and require more space to move around in. As a rule of thumb, try to keep door and entry ways at least 96~128 units high and 72~88 units wide. If the door or entry way is in a highly trafficked area, maybe even go as much as 144~160 units high and 96~112 units wide or more. Main pathways and areas right in front of a stairway and ramps should be at least 128 units wide. This is not to say you can't have small side corridors and vent shafts to travel through, but try to avoid having them be the main route to an objective.


15. Easily Camped Spawn Exits

Unless you want your map to be a straight deathmatch with no objectives and lots of griefing, avoid placing spawn points for opposing teams right next to each other. I'd recommend keeping opposing teams' spawn exits at least 2500~3000 units apart. If you're coming close to this distance in a map, or if one team can easily reach another team's spawn exit during the set-up time, have at least 2 exits available for a team to leave their spawn room by (think dustbowl or granary), the further apart the two exits are the better. Another option is to provide two, completely separate, spawn rooms for a team to start in, similar to 2fort's set-up.


16. No Spectator Cameras

It's fairly obvious when there are no spectator camers as, after loading the map, players will be viewing the map from the default 0 0 0 coordinate, which may create an odd viewing angle. Before putting your map on a public server, make sure it has at least one spectator camera (info_observer_point) entity in it. Not having any cameras in the map may crash a dedicated server running it when all the players on a team die, leaving no teammates to spectate. This happens because the server is trying to force the dead player to spectate something that doesn't exist. When you do add an "info_observer_point", make sure to aim it at a common battle area inside the map and not at a wall or inside a spawnroom.


17. "Sticky" Surfaces

Maps that have detailed structures and props that stick out can sometimes "hook" players as they come in contact with them. If you find surfaces like these during playtesting, smooth them out using clip brushes so that players don't get caught on unexpected obstacles. For example, if there were two signs next to each other, it might be a good idea to place a clip brush around them so players brush against a solid, even surface and don't get stuck between them.


18. Floating / Disconnected Geometry

When surface do not touch, one structures may appear to "float" above or in front of other surfaces. Floating objects are usually created when adding prop based entities and after rearranging the structure of a map. You will want to make sure one solid surface comes in contact with another solid surfaces to avoid this "floating" appearence and also to avoid the game rendering unneeded surfaces.


19. Broken Prop Shadows

The Source Engine is often quirky in the way it creates shadows for prop entities during the compile process and doesn't always get them right. Many prop entities have shadow casting turned on by default, and this is not always a good thing. Prop shadows will often be cast on top of other shadows, through walls, and at the wrong angle. It's a good idea to go through a map after compiling to find and disable all the broken prop shadows; don't be surprised if you're left with more shadows disabled then enabled.


20. No Screenshots

When you want people to try your map out, including screenshots of what it looks like in-game is a must. Many people won't download a map that has no screenshots, even if it was made by a reputable mapper. It is also possible to partially assess map problems from screenshots as well. Another thing to keep in mind is to try to keep preview screenshots small in file size (I try to stay under 100 KB) so people on slower connections don't have to wait several minutes just to see what you map looks like.
 
Last edited by a moderator:

Brandished

L5: Dapper Member
Jan 19, 2008
234
311
I wasn't quite finished with this list, but I decided to post it anyway as I otherwise would have kept putting off working on it. I plan on adding some more corrections, references, and screenshots to it as time goes on. I'm trying to keep this list down to only more common problems as a list of specific, rarer mapping problems would be an unending wall of text that might overwhelm newcomers.
 
Last edited:

Ida

deer
aa
Jan 6, 2008
2,289
1,372
This is great! Now I can just link to this list when I see some of these problems in a map. :p

Also, it seems I have to increase the thickness of some of my walls, I never thought a player's weapon could go through a 16 unit thick wall...
 

DJive

Cake or Death?
aa
Dec 20, 2007
1,465
741
*bump* sticky
 

Brandished

L5: Dapper Member
Jan 19, 2008
234
311
Heh, I was just going to refer this post to someone else, and was looking through the forum thinking "Where did it go?", then I noticed the sticky, lol. I've been wanting to update this post, but I've been quite a bit busy with some family stuff recently. Hopefully I have some more free time here soon.
 

Invictus

L1: Registered
Oct 15, 2008
26
1
I've noticed that a lot of maps have detail objects that stick out, "hooking" players that run against the walls. Clip brushes should be used so that players don't get caught on unexpected obstacles. For example, placing a clip brush between two support pillars so you're running against a smooth surface.
 

Earl

L6: Sharp Member
Dec 21, 2007
284
38
I think you should add bold text on #8 that's like "weird/dark lighting on certain objects". We seems to get a thread every week by someone who uses the model textures...
 

Brandished

L5: Dapper Member
Jan 19, 2008
234
311
I've noticed that a lot of maps have detail objects that stick out, "hooking" players that run against the walls. Clip brushes should be used so that players don't get caught on unexpected obstacles. For example, placing a clip brush between two support pillars so you're running against a smooth surface.

Hmm, I've seen that occasionally, not super often, but I was thinking of adding something like this before.

I think you should add bold text on #8 that's like "weird/dark lighting on certain objects". We seems to get a thread every week by someone who uses the model textures...

I wanted to add an example pick for #8, I could put something like that in with it.

The other one I was thinking of adding was "disable all prop shoadows by default", since they usually ends up jacked up more often then not.


I've been planning a big update to this post as it is. Imageshack, while super reliable for keeping images up nigh indefinitely, seems to have become quite spammy in the past few months with the flash and pop up site ads. Maybe I didn't notice them before as I usually browse with noscript, but I'm considering moving all the pics to a new host because of this if it gets too much worse.
 
Last edited:

Nineaxis

Quack Doctor
aa
May 19, 2008
1,767
2,820
Another common mistake is to not put in any spectator cameras (info_observer_point). Not having any will crash the server the map is running on if a player dies and there are no teammates for them to spectate, causing the server to crash as it tries to force the dead player to spectate something that doesn't exist.

So, simply place 1 spec cam for each team and problem solved.
 

Brandished

L5: Dapper Member
Jan 19, 2008
234
311
Another common mistake is to not put in any spectator cameras (info_observer_point). Not having any will crash the server the map is running on if a player dies and there are no teammates for them to spectate, causing the server to crash as it tries to force the dead player to spectate something that doesn't exist.

So, simply place 1 spec cam for each team and problem solved.

I'm not sure about this one, while I agree that every release-level map should have an observer point, I've never seen a lack of one crash a server before. By default, if there is no observer point, the 0 0 0 coordinate on the map is used as the observer point. I have seen plenty of maps in full rotation that have no info_observer_point entities run fine without crashing the server (eg: cp_lazytown, ctf_snowfort, cp_wolf, cp_snowbridge, achievementbox, cp_orange_x, cp_orange_cross2).

Your comment does bring up a great idea for another good mapping discussion/sticky, though. A "what every TF2 map should have before being released" thread. Like a final checklist of sorts for mappers to go over before stamping their map as a beta or final release. I don't think I have enough placeholder posts to include that kind of addition to this thread, though. I'd need like 3 or 4 more in addition to the ones I already have to keep everything on one page. :p
 
Last edited:

Nineaxis

Quack Doctor
aa
May 19, 2008
1,767
2,820
Well, it will use the origin if you join spectate, but if an entire team is dead (a rare occurance, but it happens), it will not use the origin but try to assign players to spec other players on their team (which there aren't any).

It crashes servers, Immortal and quite a few other people could tell you as we did it with a few maps with no spec cams on the server before gameday started.
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
If I'm right this isnt an issue with payload maps sonce the cart acts as a spectator point.

am I right?
 

Nineaxis

Quack Doctor
aa
May 19, 2008
1,767
2,820
You are right.

Another common mistake is HDR without a tonemap controller, and HDR without cubemaps (which makes reflective objects bright white instead of purple).
 

Altaco

L420: High Member
Jul 3, 2008
484
120
It hasn't done it in my experience. When I've been testing my maps, I've found it just watches your corpse until you spawn. Maybe it's just a dedicated server thing?
 

Nineaxis

Quack Doctor
aa
May 19, 2008
1,767
2,820
It hasn't done it in my experience. When I've been testing my maps, I've found it just watches your corpse until you spawn. Maybe it's just a dedicated server thing?
Yes, when personally testing it, it just assigns the cam to the coordinates you died at. On a dedicated server, it will try to force you to spec a teammate or camera, and if there are neither, "kablooooeey", as the demoman would say.
 

Brandished

L5: Dapper Member
Jan 19, 2008
234
311
I haven't been able to recreate the bug so far, I'll try again today or tomorrow. It might be worth asking around the HLDS to see if anyone else has had the problem, and if so, reporting it to Valve.
 
Last edited:

Master

L1: Registered
Nov 29, 2008
13
0
You took the words right out of my mouth. I HATE these problems in custom maps. I ruins the rep for customs.
 

Brandished

L5: Dapper Member
Jan 19, 2008
234
311
Well, finally got off my lazy butt and sent an email in to the HLDS about the "info_observer_point" and found several server owners reporting that it has caused problems for them in the past. Someone was even kind enough to code a SourceMod plugin to deal with the issue. With this in mind, I updated the list to include some of the new stuff that had been discussed, bringing the new total to 20 items.

Now to get some more picture examples together and switch to a new image host, I wonder how long this will take me...
 
Last edited: