The usual way of distinguishing between teams in a trigger is to use a filter_activator_tfteam. It has a Team property which can be set to the red team or blue team. Spawn room doors are a typical use of this filter, to allow only Red players into the Red spawn room, and only Blue players into the Blu spawn room.

An alternative property, Associated Control Point, allows the filter to allow only playersfrom whichver team owns a particular control point. A trigger using this filter, connected to a door, would only open the door for Red players if Red had captured the control point, and similarly for Blue if Blue owned the point. If the control point was neutral, the door would open for nobody.

Finding the winners

In a king of the hill map, there is a single control point. Each team must try to hold the point for as long as possible. A team wins when they have held the control point cumulatively for a certain time; e.g. three minutes. Consequently, you can identify the winning team as the team that owns the control point when the round finishes. The winning team then gets ten seconds or so—the “humiliation period”—in which to slaughter the losers.

When the Red team wins a round, the tf_gamerules entity sends the OnWonByTeam1 output; when Blue wins, it sends the OnWonByTeam2 output. If you have a trigger, filtered by the control point, that is initially disabled, and then enable it when either team wins, only the winning players will activate the trigger.

I don’t really want to set the winners on fire—it would be a strange reward for winning—but I’ll add the logic here so you can see how it works. When the trigger gets an OnStartTouch input, it sends the IgnitePlayer output to !activator, which is the special identifier for “the entity that sent the input”, which in this case will be any player matching the filter. Hammer may not recognise these options, and will display them in red, but they will work just fine in the game.

Finding the losers?

Finding the losers should be easy. The third property on filter_activator_tfteam is Filter Mode. Set this to Disallow, and instead of allowing the matching team to activate the trigger, the filter will disallow them, and allow every other player to activate it. The team-filtered door in the second example above would open for both teams when nobody owned the point, for the Red team when Blue owned the point, and for the Blue team when Red owned the point. For pyromaniacs, the trigger shown below will set the entire losing team in the trigger area on fire.

However, there is a catch. If you enable this trigger during the round, it will work exactly as expected: the team that owns the point will be unaffected, and the team that doesn’t own it will burn. But if the trigger is enabled in the humiliation period after the round ends, both teams catch fire.

It turns out that for the duration of the humiliation period, all team-based filters will always match the winning team. This is so that the winning Blu team can open the spawn room doors of the losing Red team (or vice-versa), to slaughter any cowardly players trying to hide in it—a worthy cause, indeed.

But it causes me a little problem: although I can identify the winners, those-who-own-the-control-point, the inverted logic those-who-don’t-own-the-control-point that should identify the losers also matches the winners. It’s incredibly funny when both teams catch fire, but it’s not quite what I want.

All is not lost

I can still identify the losers, and only the losers, but those-who-don’t-own-the-control-point isn’t good enough because of the peculiar behaviour of filter_activator_tfteam after the round. What I need is to take the effect of the winning team filter (which still only matches the winners after the round ends) and invert its logic in some other way.

There’s another filter entity in Source, filter_multi, which allows you to create complex filters by performing logical operations on several other filters that you specify. If you set its Logic Type property to AND, it will pass only if all the other filters pass; set it to OR, and it will pass if any one of the other filters pass. I don’t need that capability here, but filter_multi also has a Negate Outcome property, which turns what would be a pass into a fail, and vice-versa.

What this means is that the output of the filter_multi is not affected by team logic or humiliation periods at all, but only by the outputs of the other filters it specifies. So although the Filter Mode property of the filter_activator_tfteam turned out to be unsuitable, if I use a winning team filter and send its output through a negated filter_multi, it will match only the losing team.

Final notes

There’s one small issue remaining with our trigger and filter set up: the filter_activator_tfteam matches all players on the winning team, and so the filter_multi, being negated, matches everything else. Not just players, but all other entities. The fix for this is easy: just ensure the trigger flags are set to just Clients.

All too common, the light level in the room is enough to illuminate the floor and lower walls but the ceiling is far too dark, all the effort you put into detailing it is going to waste!

Just edit the $reflectivity value in the .vmt for your floor material. Most materials wont have this by default but you can add it to the .vmt after extracting it using GCFscape. Once you’ve put it in the same folder it was in in the .gcf and renamed it something sensible you can start playing with the values.

$reflectivity works like a vector; followed by “[R G B]” where R, G and B are the tint values between 0 and 1. For example: the line “$reflectivity” “[0.75 0.75 0.75]” would reflect back 75% of the light that hits it. Each vtf will have a default reflectivity built into it, I haven’t the know-how to work it out exactly but I’d assume it averages the RGB values of the entire texture and divides by 255 to get a value between 0 and 1. The wood floor above would have [.38 .33 .30] if my my assumption is correct.

The default reflectivity compared to 0.5, 0.75 and 1 where 100% of incident light is reflected back.(animated gif, click to view)

As you can see, using values of 0.5, 0.75 and 1 all have the same floor brightness but considerably brighter  ceilings than the default. This per-texture increase in bounce lighting is incredibly useful, it’s easy to implement and you only need to include a single .vmt per texture changed, only a few kB. You can also use this to put a different tint into your environments, since you can set each colour value independently of the others. To demonstrate I’ve used values of [.25 .25 .75] to add an extreme blue tint on the reflected light. Be aware though that this only effects reflected light so the floor texture itself is not tinted blue.

With white lights you can still tint the environment with reflectivity, I hope you don't use anything this extreme though, yuck.

Thanks to Acegikmo for experimenting with this back in the summer.

The images after the jump are examples of sun spread angles 0, 1, 3, 5, 10 and 20 degrees. 3 degrees is the limit of what you want for a sunny day or a full moon (which is usually only a 60th of a degree smaller than the sun in the sky). 0 degrees looks blotchy on the lightmap scale 16 because of the chainlink, just smoothing that by 1 degree gets rid of that. If a cloud covers up the sun then the light source gets smeared out to nearly the size of the cloud, for such a skybox a larger value like 10 would be more accurate and for an overcast day 20 degrees is almost not enough.

Left hand side is using a lightmap scale of 16 and right hand side is on 1.

To the Team Fortress 2 mapping community, Turbine has become an icon of hatred. Everything mappers don’t like about Valve’s selection of maps, summarized in one single BSP file. It’s “too simple”. It isn’t “well-detailed”. The complaints against it are numerous. This is unfortunate, because Turbine is a map that should be carefully looked at and analyzed. It’s obviously a successful map, Valve picked it up because of its popularity. And what makes it a popular map? That is what I’d like to dive into.

Turbine is Simple

The simplicity of the map is one of the most frequently voiced complains against it (by mappers), but it’s also the reason players love it. It’s easy to learn, easy to understand, and easy to play, which great for a casual player not looking to explore the strategic depth of a map like Badlands, and is it just as good for a skilled player looking to do some fragging without the tedious work that is winning a more complex map.

Turbine has the Right Elements

Despite its simple layout, the map has everything necessary for good TF2 gameplay. I wrote about what elements make a layout good in What Your Map is Missing, so I’m going to look at the same points using Turbine.

• Height variation: the containers and battlements at mid, the raised platform in the one hallway and stairs in the other, the tiered flag room
• Scout routes: the containers and battlements at mid, and the raised platform in the one hallway offer different options for scout (and other class) movement
• Skill jumps: again, the containers at mid can be reached by most classes offering a high-ground alternative to those who use it
• Reasonable pickup placement: small health and ammo in the flag room, larger in the hallways and in the alcoves tucked away from the fighting at mid

You’ll notice that the same layout features make up most of the gameplay elements. The map is simple, but everything is there, just condensed. Furthermore, Turbine offers other basic elements such as alternate routes.

Turbine is not 2Fort

The map avoids one of the well-recognized problems with CTF in the mapping community: the 2Fort effect. With the flag placed in such a way that requires going past the enemy spawn to retrieve it, camping becomes intolerable and the game slowly degrades to a death match in the area between the bases. Turbine, however, has a left hallway which leads to the intelligence, while the right hallway leads to the spawn. In addition, it allows for the positive element of 2fort, which is direct access from spawn to the battlements or mid. So again, Turbine has the right elements for a good map, and a well designed layout for capture the flag.

It’s Detailed (Just) Enough

While simplistic in detailing, Turbine is actually a well-detailed map. It achieves everything it needs to:

• It uses team colors to differentiate each side of the map
• The center of the map is “plain” while inside of the bases there is spytech
• While nothing special, Turbine is not an ugly eyesore

The reserved amount of detailing can even be considered a good thing. With a neutral color palette and a lack of visual clutter, the map lets you focus on what is important: other players.

Am I saying that every map should follow in the footsteps of Turbine? Not at all. But is Turbine the terrible piece of disastrous mapping failure that people make it out to be? Not at all.

Unfortunately the improved lighting introduced with the Orange Box was not added to hammer’s default compile settings, even as options, so we must add them ourselves. That means we need to know what they are and what they do. There are three options that we’re going to look at today, texture shadows, per vertex lighting for static props, and exact outline shadow casting for static props. So what exactly do they do?

-staticproppolys

-staticproppolys tells VRAD to use the exact outline of a static prop when it works out how light is cast. You might think it does this already as I once did but there are some props that cast odd shadows. VRAD uses collision meshes by default because, for many reasons, collision meshes have a lot simpler geometry which makes calculating lighting around them a lot quicker. For realistic lighting though, this is a problem as a lot of props have collision meshes that don’t precisely mimic the contours of the object itself.

-textureshadows

-textureshadows does what it says on the tin, it makes VRAD calculate shadows from textures with alpha channels that are applied to props. Chainlink fences and foliage are the most common props with alpha textures, to save having to model all the individual links in the fence a single sheet is used that has a transparent texture applied to it, but if VRAD is using the collision mesh or even the exact outline of the prop for shadowing then it thinks the links are as solid as a sheet of steel. -Texture shadows solves this. The prop must however be named in a lights.rad file in the root of the game you are compiling for otherwise it won’t bother with it. I’ll cover that in a bit.

-staticproplighting

-staticproplighting calculates per-vertex lighting for static props. Before all static props were lit by a single calculation at their origin or lighting origin. If that was inside a wall the prop was black, if it was in shade the entire prop was dark, if it was in light the entire prop was bright. Now though if half a model is in light and half is in shade, only the vertices that are in light are bright and if part of the prop is inside a wall then only the vertices that are actually inside the wall are black.

Unlike the previous two, this will increase the filesize of a map as well as the compile time. Since the previous two are lightmap based, the resulting filesize is the same with or without them but -staticproplighting forces VRAD to calculate hundreds if not thousands more bits of lighting information for each static prop used in the map.

Lets look at some examples:

This one shows notable improvement for each compile parameter added. For -staticproppolys the shadow cast by the crane is turned from a dark blobby mass into an accurate network of dark and light as the light shines through gaps in the planks of wood. The dark blob around the rocks disappears as VRAD uses the outlines of the rocks instead of the collision mesh that the rocks don’t actually have. The razor wire top of the fence also cast a shadow before but with -staticproppolys the shadow from it is almost nonexistent.
With -textureshadows the massive dark area caused by the fence disappears. If the sun spread angle was lower and the lightmap scale on the ground low enough you’d be able to see the chainlink pattern cast as a shadow here.
Finally -staticproplighting has a subtle effect but if you look carefully at each prop you’ll see it working. The spigot is half shadowed and half lit now, the boulder is casting a shadow onto the smaller part of it that is hidden from the sun, the inside of the concrete tubes are dark now.

This example shows most improvement with -staticproplighting. The corrugated metal sheets have some shadowing on them, the smallest one’s origin is either inside the plank of wood in front of it, or just behind it, in a dark shadow, but with -staticproplighting light falls on all the vertices except for a single strip through the middle. The oil drums have more natural lighting in the final shot, the one in the front casts a shadow on the one behind. You can also see the shadow cast by the fence disappear in the second two screenshots.

How do we use these features?

First you’ll need to enable expert mode on your compile options (click the ‘Expert…’ button on the ‘Run Map’ window) pick a configuration you wish to modify, generally these options are good for very final compiles, I only use them when doing a final build or for fine lighting tweaking, so ‘HDR Full compile -final (slow!)’ is probably a good configuration to alter. Find the $light_exe one in the list of compile commands and select it. There is an image below, but yours won’t look exactly like this because I’ve added a few of my own which I can toggle on/off for different compiles. Add this to the Parameters of the $Light_exe one you just selected (without the quotes) “-lights mylights.rad -staticproppolys -textureshadows -staticproplighting”. Add them at the start of the list, NOT the end. The very final bit in the Parameters box should always be “-game $gamedir $path\$file” which should already be there, just make sure anything you add to $light_exe is in front of -game.

There is one last thing that needs to be done, you need to create a mylights.rad file. This file is just a list of all the props you’re using that need -textureshadows enabling for them. You use ‘forcetextureshadow’ followed by the filepath of the model, each model on a new line. “forcetextureshadow models/props_gameplay/security_fence512.mdl” for example.
Once you have that file, and have added in your parameters in hammer, just hit ‘Go!’ and wait for your compile.

Wait, there’s more!

Whilst these options are generally fantastic for improving visuals, there are a few cases where they make things worse and need to be turned off on a prop by prop basis. There are three options at the bottom of the keyvalues for any static prop which alter how these compile settings work. Well actually, just how -staticproppolys works. ‘Disable Vertex lighting’ does what it says on the tin, stops all per-vertex calculations for the prop in question and uses the pre-2007 method of using just the prop’s origin. ‘Disable Self-Shadowing with vertex lighting’ doesn’t turn off the per-vertex lighting calculations, but rather tells it to ignore other parts of the same prop when calculating lighting. I haven’t found a case where I’ve needed this, but the fact that it’s there means Valve did. Finally ‘Ignore surface normal for computing vertex lighting’ makes each calculation unaware of which direction the face is facing.

Here the top image shows the scene compiled with -textureshadows, -staticproppolys and – staticproplighting turned on but you can see there’s a bit of blotchy lighting on the concrete tube. This is caused by a single vertex on the tube being in exactly the wrong place, it’s in the shadow of one of the chain links. This isn’t a terrible example but if you wanted to remove this unrealistic blotchyness you might want to change the ‘Disable vertex lighting’ option to ‘yes’ which is shown below. You also lose the darkness on the inside of the tube, so you have to weigh the pros and cons in each case. The tube’s properties look like this:

Below is another example that occurs frequently. Single sided models, that is models which are only a single sheet of polygons with a texture using $nocull so you can see the back of it, only receive light from their front. This means if a piece of corrugated metal, such as the centre piece below, is facing away from the main light source it will be unnaturally dark especially if it’s next to similar props facing the opposite direction.

You can see with the ignore surface normals option changed to yes the middle sheet of metal now receives light like the others do. Again, this is what the properties of that prop look like:

Enjoy. (No doubt I’ve made something unclear or have made a mistake, so… comments!)

Straight after spawning I take a look around and instantly see two awesome things: an asymmetrical roof with some awesome support work going on, and a light switch that visibly leads directly to its light. I apologise if its hard to see on your screen, there is a strong fog in viaduct and not much light up there.

There is always the temptation to just clip your rooftops to a symmetrical angle instead of taking the more creative route of  having one side shallow and one side steep. I stayed in the Alps last summer and I was surprised by the number of buildings which had this kind of roof. It also lends itself well to the neat supports here, don’t forget to consider adding the metal plates on the joins. The light that’s casting a nice shadow on the ceiling is just a 90 brightness point light entity and a little cylinder of blocklight just above it.

This shot shows boarded up windows, often windows are just sunk slightly into a brush textured with wood\wood_beam03 and left as just that but since the alpine theme came along there are 6 patch models, each with three skins. They’re great for boarding up windows and doors, I’m pretty sure the _small variants of the patches were sized specifically to board up the sawmill_window’s seen on the right hand side here. The image below shows another boarded up window that uses wood\wood_wall001 instead of wood_beam03. What I’m trying to say here is try using other methods to board stuff up, I know I certainly use wood_beam03 too much.

There is also a wooden support running all the way around the bottom of the roof, I don’t often do this but it’s quite common in the real world so there isn’t really any good reason for me not to. It does also create a nice contrast between the dark wood and light icicles, making them more visible.

Apart from the previously mentioned boarded up windows, there’s an extra wooden lintel brush above the standard doorframe model, a fast and easy way to make any, otherwise boring, doorway more interesting. Snow is also like the sand I pointed out in badlands, you can sink props like tyres into it without worry, just make sure that you don’t on any firm grassy ground for non-desert, non-snow maps.

I’d also like to point out here the repeating black strips present in so many of the metal wall textures, I hate these and always try to hide them whenever possible. Not because I don’t like the way they look, but because of how regular and precise the repetition is, especially on large walls. Any wall over 512 units wide must have at least two of them showing and the repetition is even worse if tiled vertically which many large industrial buildings need to be. To counter this I sometimes start the first 256 units off as a brick texture which you can see through the door is what Valve have done on the other side, and I like to add smaller extensions when any single face gets over around 768 units wide. Since the new section of building is small, the texture can be carefully aligned to show as few black strips as possible. Then I use doors, windows vents and supports to hide any remaining strips as best I can. I try not to hide them all, but aim to break the regularity in their pattern.

So where did that train come from? When detailing high areas like this, remember that the player can’t see the ground, which really knocks perspective, until I opened Viaduct up in hammer I’d always looked at these trees and assumed they were much closer and not anywhere near the tacks. As long as it’s not easy for a player to see that it’s wrong, it doesn’t really matter, hence the lack of anywhere for the train to go even if the tree wasn’t there.

Telegraph poles run either side of the viaduct and a single cable runs along its side. Viaduct has three telegraph pole networks in total, one running across the central viaduct, and one coming in towards each spawn building. They’re really essential in any map, whether they’re carrying power or phone lines, almost every building needs electricity so if you haven’t got any in your map, you should turn off all the lights.

Way off buildings like this are great, often it seems weird that all of the buildings are concentrated in the centre a seemingly arbitrary space and adding some in the distance helps sell the map being part of a larger industrial environment. For buildings do far away only the bare minimum is needed, those windows and door you can see are just toolsblack textured brushes. The roof also has a dark wood border around it so you can see it clearly. As it’s exactly the same size and shape as the out-of-bounds buildings on the other side of the map as well as very nicely off-grid, it was probably a func_instance that was collapsed to have it’s detail removed. Instances are great for off-grid rotation because in the instance .vmf all your work is on the grid at 90 degrees, then you rotate the func_instance and everything rotates properly.

I don’t have anything insightful to say about the rolling hills, rocky cliffs or clumpy trees, just that it looks great. Viaduct has one of the simplest 3D skyboxes, just a smattering of tree cards arranged to give the illusion of dense forrest.

That’s it folks.

Touching on a previous topic here, clustering details around doors. Since doorways are a place players run through a lot they see the details that are there a lot as well so you can get a free ride with your detailing by putting it closer to areas players see a lot of. Since they see it so often they’ll end up with the impression the map is more detailed than it really is – great! This one also shows some cans and a bottle, those are prop_physics_multiplayer, they’ve got some keyvalues set so that they don’t lag up the server by checking for collisions too often but a good rocket blast will send them flying, just like the hazard cones in many other maps. I’ve yet to see a these really take off in custom maps, not that I play many now.

Another thing to consider in your doorways, cobwebs. I’ve had a lot of people ask which model they are, most are suprised to hear its just a standard brush with a texture on it. Ok, so you have to make it a func_ilusionary so that you don’t get caught on it but its still just a brush with a texture, ultra simple. They work well if you put a strong light near them, then they’ll stand out a lot. The texture isn’t double sided so you’ll need to put it on both sides. There is now a model version of it (since the Halloween update) but the drawback of that is it you’re stuck with a fixed size, if you use the brush version you can scale them how you want. (Don’t forget to make the model version nonsolid if you use it as by default it will use it’s bounding box for collisions!)

Bland is bad? Nope, not at all. I was quite suprised when I was spectating around 2fort to find such an empty wall but actually I’ve never noticed it being bland whilst playing since I’m usually way too busy dealing with sentries or running with the intel. When you come to detailing your map it can be best to leave areas quite blank, these areas will usually be ones that have sentries in them constantly, since you’re always so focused on getting past/sapping/blowing up/etc the SG you’re far less likely to notice the huge blank wall behind it.

Another seemingly blank wall, but actually this area sees little traffic so it doesn’t make sense to put a lot of detail here. However the holes in the roof and the wooden back to the window in the middle are just to stop you from realising how empty it is.

This texture just here… TF2 texture?…. Nope. Its one of the stair textures from HL2, but it works well on TF2 stairs. Just a reminder that its not always a cardinal sin to use HL2 textures, you just have to be careful about which ones you use and where you use them. Another note here is that stair textures often get very, very repetitive. It’s important for stairs that see a lot of upwards traffic to vary the x offset of the texture so that you don’t see the same bit of texture stack vertically on every step.

See the little yellow spots I’ve circled? func_dustmotes. If you’ve got an area with lots of light flooding in from the sun or bright spotlights you might want to consider adding some of these guys. Be warned though, they make the area look dusty and they really stick out in places that look clean, like the locker room type spawnroom. If you apply them too heavily you can really see the bounds of the brush, they’re best applied very lightly so there are no harsh transitions. Also in this room there is some fake volumetric light streaks, adding to the dusty look. Unfortunately for us, knowledge of a modeling application or a friend with willing is needed to make these.

Do you see how the lights seem to give off a little glow? Thats done using an env_sprite. They’re an effective way to make the computer models actually look like they’re on. Valve also use these on their security cameras and generators as well. Be careful adding one for every light though each sprite adds to the edict library, which is a common cause for crashes on detailed maps running on 32 man servers. Every dynamic entity adds to the edicts, remember to only name entities when necessary, like lights, naming a light makes it dynamic.

One thing I noticed here that I can’t show with a screenshot is the soundscape, as you fly though a map the sounds you’ll hear change depending on where you are, deep inside the spytech base of 2fort the computer wirring sounds are strong and theres a low humming that really adds to the atmosphere. Don’t forget to make sure when you go outside you change the soundscape to something more suitable though otherwise it will just feel wrong.

See the wires between the lights here? going to a conduit on the wall? It’s a really nice touch, something that might often get overlooked or forgotten. Normally a room like this with a high ceiling would not require details like this, but as anyone who has played 2fort knows, a lot of Engies like to hang around in here, so they’ve got a lot of time for looking around.

And lastly just a really nice image, I don’t know what to say about this one just that when I saw it I thought “wow, I’ve never seen that before…. it looks great!” The colour correction present in 2Fort helps it feel painted. I can’t remember if they actually do or not, but the clouds in the background are brushes in the skybox tied to a rotating brush so they should move slowly as the game progresses. A nice touch.

Next map in the series is yet to be decided, leave a comment and tell me what you want to see.

Let’s pick it apart and see what we can learn!

Windows, Valve uses them a lot. They’re a very easy way to add detail to a building, inside and out. Boarded up windows are good at adding detail without changing any gameplay value, The only window that isn’t boarded up here is virtually useless, you could lob a nade through there, but the chances of being able to do so without being shot from the other side are slim.

This corridor is quite an enclosed space, especially as there are wood piles down it’s length and crates at the end. The boarded up pit under it and open roof help make it feel less claustrophobic. If you look above the pit there is actually a mine head directly above it, some good continuity, rather than just a random pit. As I said in the others in this series, you can make an area feel larger by adding visible but inaccessible sections at the limits of the area, in order to be able to act this way, the pit would need to be lighter so you can actually see it. It’s already in shadow and boarded up, it would be almost pitch black if there wasn’t a fake light in there, half way down is a single, dim, light entity giving enough ambient for you to see into the pit from above.

Another inaccessible area, this one doesn’t add much to make the area feel larger though. It’s main purpose is to provide light to the area below. Often light props hang down too far from a low ceiling to effectively light the room. If the area above the room isn’t being used you could raise the ceiling, or do something like this. This solution requires a brighter light as a lot of it is blocked by the props, you can see how bright the light is in the inset.

These grass props have a very low polycount and go great against building and cliff bases, the grass overlay also is a good way to add a little bit of blending into the bottom of a cliff. That same overlay is also used at the top of some of Dustbowl’s cliffs, adding a little overhanging grass looks great. Both prop and overlay can have reasonably short fade distances if they’re in an intensive area.

Too many custom maps have very bland and flat rooftops, there isn’t much to say about this one except look how much stuff there is on these roofs. Vents, pipes, chutes, chimneys, little raised bits, conveyors. Obviously the amount of this you should employ depends on how industrial your environment is, also don’t forget that there are a lot of bland flat rooftops in real industrial environments, but they’re less interesting.

Again not a lot to say for this, just that a lot of custom maps neglect drain pipes and gutters when almost every building has them in reality. The gutter props have two skins, this rusty red and a grey version, good for red and blu themed gutters.

Tall buildings like this are awesome, they look cool, provide continuity since you can see them from multiple areas in the map and they cut down the amount of stuff you have to make. As long as the whole thing is a func_detail it will be entirely visible from both sides of the skybox brush that is cutting it in two. If you still want it to block vis as well as being visible on both sides, make a copy of it the same size and shape and leave that as nodraw (world brushes) and that will cut vis without shadowing the func_detail. (This method is used for Badwater’s tower).

Just 2Fort left to rewrite from TF2maps.net, then I’ll do one more based on popular opinion, leave a comment.

What’s the focus of this picture? Wires. In my time testing maps I’ve seen a lot that have little or no use of wires, and on the flipside I’ve seen maps that have wires here, there and everywhere. The way official maps employ wires is probably closer to the latter, but they don’t go completely over the top. Wires between telegraph poles, from crane wheels, between building roofs, these are all common spots for wires in the real world and should be in your maps too, they’re something that’s very quick to add to your and easy too. The power a simple wire has to make your map look better is amazing; if you’ve not used wires before try them out. Bung in a move_rope, set it some slack (usually between 90 and 120 looks good) and then give it a keyframerope to connect to. Often the width of the wire is fine at the default value but don’t be afraid to vary it a little. If you’re really feeling daring you could change the material it uses to try a different colour or perhaps rope. I’m not sure if there are any non-default wires in official TF2 though, but when did that ever stop anyone?

Got any mine carts in your map? Instead of leaving them empty, put a small displacement in it with a gravel or even gold texture, this is a dead simple way to make each one look different from the last. Plus, you get the added bonus of it looks like someone actually worked in your map; a map full of completely empty mine carts will just feel weird. Of course you can vary the scale of the texture to make it look like it has bigger or smaller rocks in it. If you’re going to place several next to each other like this shot, make the first displacement then turn texture lock off before you copy it. That way the rocks on the displacement look different for each cart even if the displacement is the same shape. This wasn’t done in this shot and you can see that all three mine carts have the same pattern of rock in them. It doesn’t just stop at mine carts, you can add displacement mounds of dirt/rocks/gold anywhere, like at the end of those tracks in the background of this shot.

Nice bands holding the wall’s support beams together. Taken from close up.

This is the same wall but seen from the opposite side of the playing area then zoomed in. The small bands in the previous shot haven’t just shrunk to a size too small to see, they’ve actually disappeared. This is normally a trait associated with models, when they get far enough away they fade out and your PC doesn’t render them any more, actually this can be done by brushes, and even overlays. It’s a really great way of cutting the amount of stuff your PC has to render, you pick small brushes that you can’t really see from a distance and you make them a func_lod instead of func_detail. That way you have complete control over how far away they should fade out and of course once they’ve faded out they are no longer drawn and aren’t a burden on your system. A good little trick for areas that have a few to many details for good FPS.

Each of these areas that are completely sectioned off from the playing area really help to enlarge spaces. Keep them reasonably small and light them well and they’ll really help convince the player he’s in a bigger environment. Inaccessible balconies are great for this too, as long as the ceiling is high enough, adding  a small balcony with a door either side easily improves a bare room. In the bottom shot there’s another displacement pile of gold, just like the mine carts. Oh yeah, don’t for get to add some glow to those lights, env_sprite, point_spotlight or env_lightglow all work well.

This shows same building viewed from upclose and from the other side of the area. How many props can you see in the first that aren’t in the second? I make it about 26ish (probably more than that though) which means from the far side of the space you can see this building from it still looks much the same but you’re rendering about 6 or 7 thousand less polys than if those models hadn’t faded. The way this is achieved is from the fade distances set in the model’s properties. This is a feature vastly underused in custom maps, many have no fades set at all and in Official maps around 80% of props have a fade distance. Naturally some props are just too big or can be seen too far for a fade distance but the vast majority of props are better with one set.

Ahh yes, the displacement roof, great for abandoned or just aged facilities, not a technique to abuse for any freshly built kind of environment though. Make some of your roofs into displacements, power 2 is enough – then warp them slightly like this one. You can only really see the effect when you’re still but when you’re playing its a small thing that really helps make seeing roof after roof after roof less monotonous. Because displacements are done as a batch process this isn’t as intensive as you might think, whilst I can’t give any really figures on if its better or not it really isn’t the sort of thing you need to worry about when optimising. Displacements are also not cut by the tools/skybox texture so you can safely divide an area across a displacement roof and know that the whole displacement will be visible on both sides of the skybox brush, great for tall buildings.

More coming soon.

Once more into the breach, dear friends

This first shot shows off the 3D skybox being used, notice how as the mountains get further into the distance they become more and more blue? The fog colour that has been used matches the rough colour at the base of the 2D skybox behind it. This holds true for any map, in any game. The fog colour you pick should be roughly the same as the colour of the skybox texture near the horizon. Think about it, when it’s foggy, what colour does everything get as its further away? What colour is the sky, at the horizon? If you answered both those with the same colour then you are correct and understand the principle. Pat yourself on the back.

Here, some simple ways you can block players from leaving the play area. Whilst it is clear that a demoman or soldier could jump over those fences they can’t. And nobody questions it. On Hydro there is a fence that is only knee high and nobody questions it. All that is needed is a visual barrier that divides the playing area (visually interesting) from the out-of-bounds area. The out-of-bounds area is usually quite bland but generally it has just enough key details in it to stop it looking out of place, for example that dirt track, keeps going on through those gates, as does the train and track. That billboard in the background as well. Little things like this keep continuity even though there is an immediate fall off to visually sparse.

Some simple details here. A few tires sunk into the ground along with some foliage, rocks and an overlay on the ground under the plant as well. Most of the ground in Badlands is pretty free from props and they tend to be clumped like these. The tyres can acceptably be sunk into the ground in this near-abandoned desert environment, you wouldn’t want to sink tyres into grass on an alpine map though, soil tends to be a lot firmer than sand. The player will hardly notice these because they don’t have to worry about them. They can run straight over them and are never going to get snagged on them whilst running backwards away from an enemy. It’s always important when putting low props on the ground to make sure that players can run over and around them easily without even thinking about it.

This perfectly illustrates how you should never be afraid to tell the player where to go. You would think that three massive signs all pointing the same way would be too many, but no, it works just fine and players hardly even notice them. Whilst a player is busy taking in lush environments/killing waves of enemies/fleeing from waves of enemies, their subconscious will see the signs and gently push them in the right direction without them really being aware of it.This shot also shows a bit more of how small details are continued in the out-of-bounds areas. And although this area is only blocked off by chainlink fences, don’t be tempted to only use chainlink fences in your map. Don’t forget to vary things a little.

Finally (for now) this image shows where detail is needed. Detail is needed most wherever the player is. That means around doors, around windows they might shoot from, any room with intel/CPs in, spawn rooms… You want to be putting details like junction boxes, clocks, signs, boxes etc where the player will be most often and props clumped around doors are a great example of this.

That’s all for now. Look out for the others coming soon.