Detailing... Detailing and ....Detailing....

I have to admit I have a love/hate relationship with the detailing phase of my maps.

When I have a clear idea of the area I am creating its fine, its fun too.

When I don't have a clear idea on the area it can be frustrating and so so dull.

Bearing in mind I'm building all my areas with gameplay in mind primarily, I often dont have a clear idea of the type of real world space it may become. Sometimes the two come together seamlessly but more often than not I find I have to work quite hard to get my areas to look believable.

Basically, I think the goal when detailing is to add just enough detail that the player accepts the reality I'm presented to them. Sure I could go way overboard and add every concieveable detail however I'm sure that players would prefer me to create more playable areas of a map than adding a working telephone to an office.

There is no hard and fast rule about how much detail is enough but I want you to try an exercise for me.

Pick a section of the HL2 game or its episodes that you remember really well. Load it up using the console.
(for example "map ep2_outland01a"). Now punch in the "sv_cheats 1" "noclip" and "notarget" commands.

Now you can fly about the level at will and get a really good look at how Valve put the map together.

Look at the detail and lighting especially.

Normally, I find during this process that the elements of the map that I thought were particularly complex are actually fairly basic. By adding some of these basic detailing touches to your map you can give the appearance of detail without spending a huge amount of time on it.

A good example is a small balchony on the side of a building.
When I looked closely at these in HL2:EP1 I realised that actually theyre simply made out of two brushes. One to form the floor covered in a concrete texture, and a second brush that forms the railings. This is just a square brush with a railing texture applied to three sides of it.
Simple to make, but adds a great level of detail to the side of a building.

Lighting can do a great job of masking an under-detailed map. Long shadows especially give off the illusion of a detailed environment when actually detail has been kept to a minimum.

Detailing Prefabs

Some nights I'm not up to mapping or detailing. My brain just can't take it. Its weary... so I tend to spend these evenings creating stand alone detail prefabs.

Little things like flaming torches, working cupboards with items inside, fire escapes, window boxes, non-working doors with locked sound effects. These are things I can drop into any map to flesh out the world.

By building up a huge library of these items, detailing your maps can become far less painful. Feel free to share them online too. These kind of details can bring everyone maps up in quality.

Testing the detail

Players will always tell you a map needs more detail so be careful of this. Don't clutter you're map too much. Also, you must be sure that whatever detail you add, make sure it doesn't affect the gameplay.
The player getting snagged on a light model during a difficult jump puzzle can really spoil a map.

My rule for detail models is: if in doubt, make it non-solid.

The player will accept passing through small models. You might want to consider converting any small detail brushes you have to func_brush and making them non-solid too.

Feedback.... It's like crack...

This post is in response to a question posed by Phillip of the wonderful PlanetPhillip.com.

The question posed was, why do mappers and modders post alpha versions of their work online?

I totally understand his point. Posting mapping work too early can have seriously detrimental effects on your final release.

1: there's no surprises for players when your map is finally released.

2: any great ideas you have will be undermined by the fact that it looks crap in alpha phase

3: it gives the opportunity for someone else to take youre idea, make it better and release it before you.

So given the clearly detrimental effects of releasing alpha versions it begs the question why would we mappers screw ourselves over in this way?

Well ya see its all about the ego...

Mapping is time consuming, its not necessarily hard, it just takes a while to make things look great. The functional side of mapping, getting the gameplay right for example actually takes little time to create in the editor. As I've said earlier in this blog, I can put together a working dev map to test an idea in less than 10 minutes.

So, I've come up with a great idea and got it working in a basic dev map but I can't share it with anyone!

I want someone else to play it and tell me I'm brilliant. I want a pat on the head and a cookie for coming up with such a brilliant game device....

It's addictive when you get good feedback.

In order to share my fantastic ideas with the community, I would have to spend a month or more building a good looking level around my core gameplay idea.

But I want my pat on the head NOWWW!

It's the detailing that kills you as a mapper.

The community want Valve quality maps. Unfortunately, many of us mappers have partners, jobs, pets, family and other obligations which can limit the time we have to spend on our maps.

As a result the community often receive unfinished maps, maps that play well but look crap or vice versa.

I understand the frustration of reviewers like Phillip because I share it too...

All that potential, all those great ideas spread across 1000 unfinished maps. If you could just bring them all together...

...more on this idea soon...

Edit:!

As Brian has helpfully pointed out, I failed to mention that testing of your ideas is important as a mapper, even at the early stage.

The answer to this problem is, of course, to find a few close online friends who are happy to playtest for you and provide honest, detailed feedback.

Tutorial HL2: Getting Your NPC's Moving

Here's the first draft of a tutorial I'm writing. It needs lots of images adding but hopefully should be helpful for some of you in it's present form.
.....

One of my biggest frustrations when I first started mapping was trying to get my NPCs moving around in a convincing manner. I wanted my NPCs to move into an area and attack the player, or open doors and run away but they just don't do that by default.

So how do we get NPCs to start moving around rather than just attacking the player when they move into their point of view.

Info_nodes

Before Left 4 Dead, valve games relied on the mapper placing nodes on the ground to produce a series of points that the NPCs could follow.

Left 4 Dead and games after that from Valve use the nav mesh method of NPC navigation. So if your mapping for HL2 then you need to add info_nodes to your map. Add nodes to any areas you want NPCs to move through. For ground based NPCs (combine S etc...) use info_node, for flying NPCs use info_node_air and for hybrids who fly and walk (e.g. antlions) you ll need to add both. When you run the map in game for the first time in game the engine connects all the nodes together to create a nav mesh.

NPCs use all these connections to find paths to goals in the game. A goal might be the player or any other entity you choose as a mapper.
All nodes must be less than xxx units apart or a connection wont be made. That goes for info_node_air too!

Scripted_sequence vs AIscripted_schedule

I see many people suggest on forums suggesting that others use scripted_sequence to move their NPCs around but unfortunately its usually the wrong option under the circumstances.

Its a fairly straightforward rule to follow when choosing which of these two direction entities to use.
Basically, if the NPC can be interrupted or attacked, you should use aiecripted_schedule, if they cannot be interrupted or attacked then you can use scripted_sequence.
Scripted_sequence is intended more for getting the NPCs to play animations (best for cutscenes) where as aiscripted_schedule is to issue instruction during gameplay...

The reason for this is that while an NPC is following directions from a scripted_sequence they will be locked into an animation until its complete. So they wont react to being attacked and can often stand there looking dumb while the AI takes a a few seconds to kick back in.

With aiscripted_schedule you can get them to move around the battlefield with their AI fully intact and they can react to any event.

All clear? I hope so.

AIscripted_schedule

AIscriptedschedule is a godsend for making firefights more interactive. It basically encourages or forces NPCs to perform a specific action without switching off the NPC AI.

You can make the NPC run or walk to a specific place in the map or move to a specific target. You can direct them to move to and attack a specfic target, including the player.

To set it up, you just need to place an AIscripted_schedule entity in your map, give it a name, name the NPC who will follow its instructions. Set the instruction (move to goal entity for example) and then set the goal entity.

The goal entity can be any named entity in your map. If the goal entity is the player then just type in !player. If you just want the NPC to move to a specific location then use a named info_target to mark the location and use that as the goal entity.

You can trigger the schedule with any output but normally you'll be using a trigger brush. If you are using a trigger you can make your schedules a little more dynamic by using the !activator value as the goal entity.

By typing in !activator the schedule will set the target to whatever triggered the trigger.

Example:
I add an antlion to my map and set it to start burrowed. I name it antlion1. I set its sleep state to ignorePVS, Wait For Input. I set a trigger_once around it and add an AIacriptedschedule and name it AntSchedule1.

I set AntSchedule1 to direct antlion1 to Set Goal Entity As Enemy. I then set the goal entity to !activator.

I set my trigger_once to wake the antlion onTrigger and then 0.1 seconds later (its good to leave a gap) I set an onTrigger to StartSchedule on AntSchedule1.

I then place a group of friendly rebel NPCs in my map who will form a squad to help the player.

When I run the map, as the player and the team move across the map, whichever entity (the player or a member of the squad) hits the trigger first will wake the antlion and be attacked, like a trapdoor spider.

Interruptibility

The interruptibility option on an AIscriptedSchedule is really important.

If you leave it set to General this then leaves it to the NPC AI to decide if there is anything more important it should be doing (i.e. defending itself) rather than follow the instruction. In my experience, general should only be used to direct friendly NPCs when there are no enemy units in that area.

On Damage is a clever option and very useful for certain gameplay types. Basically an NPC will carry out instructions unless it is damaged while in the process of carrying out that instruction.
What this means is that you can set up nice areas where enemies attempt to reach a certain goal and the player has to stop them by shooting at them... or say you want NPCs to run past the player but not attack them, it would be farely unrealistic if the NPC didn't respond at all to being shot, so the On Damaged option will make them attack the player if shot. Handy!

On Death is the daddy. An NPC will follow direction given by the schedule no matter what happens. This is the one to use if you want to move an NPC into the area of play. From outside of the players viewpoint.
With On Death you can have NPCs moving all over the place and because the AI is still switched on, they will continue to fire on the player whilst moving. So you can make Combine soldiers retreat to a certain point, or make Antlions fly up to a high ledge etc...

The info_nodes

In order for your NPCs to follow instructions from an AIscripted_schedule they need to be able to find a route to their goal through the info_nodes you have placed in your map. If your NPCs are not following direction from your schedule, an incomplete node path is probably the reason why.
You can check your node connections by activating sv_cheats 1 in the command console and then typing in ai_show_connect

Doors

Annoyingly, things like doors can break a node path. The reason for this is because the node graph is built at the point the map is launched in the editor. Its then saved as a data file in the graphs directory of your maps folder.
If all the doors in your map are closed at the time when the map is first loaded then the node graph will not connect nodes on either side of a closed door because the door would stop the NPC from moving between them.
For this reason, its often handy to set all of your doors to the open position when your map spawns then close them using a delayed logic_auto after 1 second. As long as the door is not in the players view when they spawn in the map you should get away with it.

If you want doors to open and close when NPCs approach them then you can add a trigger multiple that is only triggered by NPCs. Expand the trigger so that it reaches out on both sides of the door. Now just add an OnTouching output to the trigger to open the door. You may need to play with the size of your trigger in order to get it working properly.
Note that this will only work of your doors were open when the nodegraph was built.

The NPC Clip Texture

NPCs are sometimes a little dumb and need some extra help to keep them out of areas of your map you don't want them in.
Obviously you wont need info_nodes in areas where you don't want NPCs to go but sometimes they decide.. to hell with it and follow the player there anyway. This is where brushes covered entirely in the NPCclip texture come in very handy. NPC clip brushes act like invisible walls that are non-existent to the player keeping NPCs away from dodgy areas.
The uses for NPC clip brushes can really be quite varied. You can make NPCs seemingly walk on air if you like... or use them to funnel NPCs in the right direction.

Player clip brushes

Equally, sometimes you may want an NPC to ignore the fact that theres a fence model between them and the player and go for the player anyway.
In a recent map of mine I had a situation where a fast zombie runs and jumps at the player across a fan shaft. The player is behind a fence so they cant accidentally fall in. As the zombie jumps at the player, a trigger push whips them away into the fan blades to their doom.
I achieved this by setting the fence to be not solid and then covering it in a thin brush of player clip. As far as the zombie is concerned theres nothing in the way and the node graph is connected so he goes for the kill yet the player finds the fence to be normal.

Getting NPCs to jump.

Go read this tutorial...

Now I will explain whats missing. Some NPCs can jump a really long way... like fast zombies. To encourage them to make those jumps you can add a few info_node_air entities to their jump path to encourage them to make that leap.

Climbing NPCs

Oooh this is where things get a little tricky... well fiddly...
Some NPCs do have climbing animations and can climb up special ladders with their AI in tact all the way.
NPCs that can climb are the following:
NPC_Fast Zombie
NPC_alex

In order to set up these special ladders go read this tutorial... then come back here and I'll tell you a little more...

Go on...

Off you go...



Back? Good.

There are a few things missing from that tutorial that you need to understand when it comes to NPC climbing. Heres da rules.

1. If your NPC ladder is higher than 128 units high you'll need to add info_node_airs at regular intervals up the ladder. Like this...

Add image!

... so that the node graph is still connected all the way up and a path can be found.

2: Your info_node_climb nodes must be lined up exactly in a straight line. Like this...

Add image!

NPCs can only climb straight upwards.

3. The NPC must exit the ladder in the direction they started it in. Like this...

Add Image!

4. NPCs can die and fall off ladders if shot but cannot fight while climbing. They just dont have the animations for that... sorry.

5: NPCs can climb downwards but it aint pretty. Fast zombies for example simply play the upward climbing animation when climbing downwards... always keep them climbing upwards.

HL 2 Weapon Fatigue

Weapon Fatigue

One thing I learned from a recent map testing session was that players actually got annoyed by the sound of their own gun if fired too often. The repetitive sound of the shotgun every few seconds as they capped another zombie grated on them.

What I discovered was that players would switch weapon, not because it was a more effective weapon against an enemy, they switched weapons also to add variety to gameplay and sounds.

I've learned that if you give the player at least two weapons at any one time their feeling about a map changes dramatically. The map seems more interactive, more dynamic because the player can engage the enemy in a number of ways.

This is worth noting if you're intending to use lots of the same NPC in one area. Due to the fact that there tends to be an optimum weapon for each NPC, if you use lots of one NPC type in one area, the player will be tempted to use that same weapon over and over. As a result, that particular gunfire sound is going to start to really grate after a while.

So how can you prevent this weapon fatigue?
By making the player engage the enemies in different ways.

The shotgun is fairly ineffective at a distance. The SMG ia also pretty useless at a distance.

The magnum is crap against fast moving NPCs like fast headcrabs.

The zoom on the crossbow is risky to use if you could be attacked by a melee class NPC.

The rocket launcher is slow to reload and dangerous at close range.

The AR2 is probably the best all round weapon so keep the ammo scarce.

The grav gun is wayyy powerful so limit the prop physics in some areas.

My current dev map and a great example of good mapping feedback

OK.. it's my blog so if I can't post my own maps in development here... where can I huh?

Here's the map... it's still a work in progress hence the feedback. This is the 3rd map in a 5 map series.
It's for HL2 EP2.

http://www.mediafire.com/file/o1x8u9h4c69h86c/ep2_aquaduct-3_5.rar

Here's the feedback I received from an very kind individual who took the time to play my map and then feedback...http://www.blogger.com/img/blank.gif

This is the kind of feedback you should be looking for if you can get it. To each point below I'm going to add some comments of my own.

I won't mention the testers name but I would like to say thank you very much.

Any other comments from readers are welcome.

-----------------

The first gate I come to after the lift, on the left, only opens a fraction. I kept thinking it was how I was opening it. Eventually I realised that I wasn't allowed down there. I suggest blocking the door with something that obviously can't be moved with the Grav Gun. Perhaps a generator or something.

This is an issue with the player's visual dictionary. The player has just opened a door with a breakable padlock on it. The player then comes across a second door with the same set up. The assumption by the player (quite rightly) is that this door can also be opened too. The player has performed the act of breaking the padlock but the fact the door doesn't open means the player doesn't get rewarded for that action. Bad Aazell!

I found the first area too dark and I am not a big fan of dark areas. Perhaps have some of the torches all around.

As per my previous post on darkness. Getting the balance right between light areas and dark is very tricky. I have way too much dark in this first area. So more light must be applied for the player not to get frustrated.

The first zombie I encounter was too close to the corner and I could see him waiting for me. If you moved him further back and had him moving towards me as I turned the corner it would feel better.
Actually, same for the second zombie.

A quick fix but clearly this will make all the difference to the players reaction to that moment. As I have said previously the difference between something feeling right to the player and feeling wrong can be a simple small movement of an NPC.

I found both sets of steps a little steep. Didn't seem right.

I'm pissed at myself about this. The first area with the arches was a pain in the ass to seal and optimise. Now I need to rethink some of it. Thinking of removing the stairs completely...

There is a round opening that allows barrels to fall through but not the player. I tried to jump down there and was frustrated not to be able to. The "cover" of spiders web is not a strong enough indication I can't go there.

The web referred to above was a response to a challenging issue. I had manholes where NPC_Fastzombies would spawn from. How do I communicate to the player that they can't go down there yet leave it open for the zombs to pass through. My solution was to place Player clip over it and a non-solid brush covered in the Antlion web texture. I think it works in the later area but without a light on the web in the first instance it's very hard to see and therefore doesn't work. Will add a light.

I got the feeling that the handle that open the gate carried on forever. I didn't see it stop. Does it?

A simple fix but it's interesting that the player picked up on it. The turning degrees of the turning handle is currently set to 3000. Lol. I honestly didn't think the player would care if it stopped or not as long as they could get under the door. But clearly the expectation is that they are to turn the handle until it stops and that indicates that the door is fully open. So I've learned that even though the main reason for turning the handle is to open the door, it's not the door that the player focuses on. Interesting stuff innit!

The area with the three fans is excellent but it feels too much like a place in a game than a real place. For example, why would all those crates be there? Think about it. That would mean they would have to have been manually carried there and that doesn't seem "real" to me. Of course, this area needs something, but I would suggest just rubbish would be enough and maybe some tools etc.

Very true.. A further detailing pass on this area with a few fake doors added should clear this up and hopefully make it feel a little real world.

All three fans stopped permanently after I turned them off a few times. Is that supposed to happen.

This is exactly the sort of testing feedback I need. It's a very good example of why the mapper is not the best person to test their maps. I'd become so familiar with playing through the map I simply rushed through each fan area on the first time I hit the reset button. It didn't occur to me that players might hesitate and hit that switch more than three times. LOL

I would delay the fast zombie for a fraction longer, as when I entered the area I looked around and didn't seem him get sucked into the fan. of course, it's pretty obvious, but if he is there to demonstrate, as I assume he is, it would be better to have it very obvious.

A moment I'm really proud of was missed by the player simply by triggering it slightly too early, I think we're literally talking about a 2 or 3 second delay but it makes all the difference.


The next large area looked fantastic but this is where I really wished I had recorded the demo because it was boring to play. The first thing I did was jump down onto one of the supports and collected the ammo etc. I then jumped across to the main area. A quick look around told me that a poisonous zombie was behind the door.

I don't know what made me do it, but I decided to jump to the next support. At that moment, the lights seem to come on and the fast zombies appeared. I simply stood next to one of those pipes and as they came out shoot them. Of course, they also cam out from other pipes but jump across and when they land it's easy to pop them.

Another classic example of the fact that the player will not always play an area as you saw them playing it. My intention with the fast zombie Arena was have the player constantly moving around being chased by zombs. It's much more fun that way.
By putting the ammo next to the zombie holes I gave him a perfect combination of ammo and spawn point so he just stood there and capped the zombies that appeared. Must have been really dull. For those of you that play the map, try and stay over on the main area and you'll get the idea of what I was going for.
I now have to rethink this area a little to stop the player moving onto the spawning platforms.

I feel that that support area should be just for the fast zombies and I should be forced to move around in the main area.

The double fan was fun, but when you smash the crates the piece fall to the ground. I suspect there's nothing you can do about that.

A minor tickbox change to my trigger_push brush, but when the debris from the broken crates falls to the ground when everything else is being blown up to the roof it can break the mood and the illusion.



The vertical elevator shaft is fine, but those three fast zombies are wasted. They should appear the moment I enter the corridor, so I have to run to break the wood or stand and fight.

When I got to the elevator shaft I assumed the blades were to kill the zombies or break the wood blocking the entrance. I tried three time to jump into the elevator, thinking this was the way forward. It too a few moments to realise that I needed to cut the cables.

Yes my big finale to this area. It clearly needs a little more work to stop the player from wanting to access the elevator and to stop the player from heading back down the ladder and killing the zombies. I think I will have the zombies climb up towards the player. Should add some pressure.

----------------------

Hope this gives you a good idea of the sort of feedback you should be looking for and I think it gives some great examples of the traps you can fall into when putting a map together.

Hope you enjoy the map in it's current form. I'll be posting a new version soon.
Let me know any further feedback you have, and please keep it constructive... (be gentle).

Example of map area development... choices choices.. hmm...

Developing an event list

I thought it might be useful to take a look at the thought process that leads to a small section of my map.

The setting is simple... a lift shaft..

So how much fun can we have with a lift shaft. Heres several scenarios I've built in test mapping.

1. Player jumps to ladder on far side of shaft. As they climb, combine blow the lift cables and lift falls down shaft past the player. As player nears top of shaft, manhacks are released and combine with SMGs fire down onto player from top of shaft.

Pros: Movie moment with lift hurtling past the player. Combat while on ladder is different and plays quite well. Feels kinda Die Hard!

Cons: Lift never actually is near player so no interaction. Manhacks are rather predictable in these circumstances. Difficult to gate in order to ensure player doesnt just speed up ladder and escape.

2: Player ascends ladder with lift at top of shaft. As player climbs, fast zombie jumps on ladder below them and climbs up towards them. Player jumps off ladder onto lift roof and across to other side. Lift is blocking exit. Player is presented with circular saw blades which, using grav gun can cut lift cables and send lift falling down shaft to kill persuing zombie.

Pros: Love the idea of player seeing zombie jump onto ladder and start coming for them. Love the idea of finishing off zombie area with a final fairwell of crushing them with a lift.

Cons: zombies cant attack player while climbing, its a set animation. So player would have to reach the top of shaft before zombies start climbing. Will player even notice zombies are at bottom of shaft? Will have to be a pretty short shaft...

3: Player climbs ladder of abandoned shaft and reaches beams blocking shaft with prop_physics metal panels on top. Player has to use grav gun to clear the ladder and send prop physics junk falling to bottom of shaft. Once clear player moves to top of shaft and jumps onto lift roof. Lift creaks and one cable snaps and lift descends a little to a point that player can jump off onto second ladder. As player jumps off lift, final cable snaps and lift crashes to bottom of shaft.

Pros: Like the upward grav gun play. Nice movie moment at the top. Also good to have puzzle and movie moment section as this follows a big long combat sequence.

Cons: No combat.

I haven't decided which to go with yet but as you can see, by creating three different test maps for each scenario I can establish which is the most fun and try and judge which players will enjoy the most.

I'm very tempted by number 2 to be honest. Its a nice bit of closure to the zombie section of my map series...

Let me know your thoughts...

In Game Story-Telling

As I mentioned in my previous post on the evils of the cutscene, there are always methods to relay story or information to the player without removing them from they're own perspective. Lets explore some of these options.

Monitors and Cameras

One of the most effective methods of doing a cutscene in game is to use a monitor system. Most games are capable of outputting camera feeds to some form of surface within the game itself. This method is fantastic because you can show your cutscene without breaking the players immersion.
Simply gate the player and un-gate when the cutscene has ended on the monitor.

NPC scripted scenes



These are scenes played out around the player within the map. If the player could possibly interrupt the scene then keep them away from the npc actors behind a fence or forcefield etc...
Friendly npc scenes can normally progress with the player in direct contact as the player can normally not inflict damage on friendly npcs.

Enemy NPC scenes are usually best played out when the player is apparently unnoticed by the enemy. Keep the player in a dark spot and light up the area where the scene is played out.

Most of the time the player is happy to let the scene play without attempting to interrupt however you should ensure that the player can't interrupt the action anyway because some players just can't help themselves.

Enemy npc scenes, if not critical for gameplay, can be made interruptable if you so choose. Go play "No One Lives Forever" for interruptable enemy scenes at their best. Good god that game is funny...

Environment Stories



As in Left 4 Dead or Portal, you can apply a story via the game environment. If you haven't realised before, the graffiti on the walls in the L4D saferooms tell multiple stories about survivors who had passed through before you got there.

Tannoy Systems or Walkie Talkies

Having voice messages played out to the player while the game progesses can be very effective.

A tannoy system is great for keeping the player up to date and can also really ratchet up the tension in a map if the player is given a message that the enemy is on their way.
This is probably the most acceptable method of delivering information while the action is ongoing. Just make sure you're in a quiet period if you are going to tell the player anything important.

I like the idea of adding a narrator to a story. So the narrators voice plays at key points in the story recounting what the player has done or is about to do. You could have a lot of fun with this by having the narrator misinterpret the players action for extra comedy.
If you've ever seen Monty Python's Holy Grail think brave Sir Robin and his minstrels and you'll get the idea.

Even better have the narrator tell the story from the enemies perspective, painting the player as the bad guy. I may try this one day but feel free if you want to have a crack at it.