Poison Zombies are one of Half Life 2’s most mechanically unusual enemies: not in terms of how they’re supposed to be beaten, but how they fight and the kind of threat they can pose to a player. While a regular Zombie might be able to hound the player in a certain direction or serve as an additional threat to avoid during platforming or puzzle segments, a Poison Zombie is capable of delivering instant death to the player in the right circumstances, and can perform a limited amount of area denial and player harassment from a distance.
The Poison Zombie As An NPC
Poison Zombies behave similarly to standard zombies while idle – they wander around aimlessly, search for new threats and make feral grumbles and groans. While all Zombies sound somewhat terrifying, the Poison variety have a special set of sounds that emulate the grunting and groaning of a dying, crying and poisoned old man. Lovely.
Most of the general AI behaviour is still the same, right down to way they navigate the world. If you want to get an overview of how zombies work, you can check their entity profile here. Any techniques that work with regular Zombies will work for them, too, so they’re generally the same in terms of mobility and how they approach their targets. However, they deal far more damage than the standard variety, often approaching (or even passing) triple their normal damage output per swing. On the other hand, their swings are far less common and frequent, and they attack at a much slower rate than the standard variety, making them weaker overall in terms of their damage per second.
The Posion Zombie has a unique attack that can easily catch first-time players off guard – the ability to throw up to three Poison Headcrabs at their targets from a distance. This isn’t just a way to damage the player like a standard ranged weapon – these Headcrabs become a separate NPC entirely (which will get covered in more detail in a future Entity Profile). Like any Poison Headcrab, they’ll instantly reduce the player’s health to 1 on a direct hit, followed by the player automatically regenerating it – minus ten health from the total they originally had. This can’t kill the player on it’s own, but it opens up an opportunity for the Poison Zombie to deliver a killing blow.
As with regular Zombies, the Poison variety can also drop it’s main Headcrab if it’s killed without sufficient damage to the head, as well as any remaining Headcrabs on it’s back. This is much more common than the main one dropping, even if the Poison Zombie is hit with a direct explosion, but fire and vaporization will usually take them all out at once. However, they can’t survive any kind of bisection: they’re either alive or dead, with no crawling version. In addition, they don’t have the ability to “sleep” and are much more limited in terms of scripted sequences, so they’re better suited as an actual threat rather than an actor for carefully-prepared background events.
The Poison Zombie As An Entity
Like normal Zombies, Poison Zombies are fairly limited in terms of their entity properties and Flags. The only major option that’s unique to this variant is the “Crabs in nest” setting, which adjusts how many Poison Headcrabs it carries on it’s back, with a maximum of three and a minimum of one. This does not include the one controlling it, meaning that you’ll be choosing between four and two Headcrabs in total. As mentioned before, the ones on the back have a very high chance of dropping off if they haven’t already been thrown, so you should set it to the lowest possible value if you want to give players an easier time.
Other than that, they have no special Inputs or Outputs with other entities and triggers aside from the ones shared with most NPCs. The way they handle navigation is also similar, with the ranged attack being the only difference: it’s triggered seemingly at random as long as the player isn’t in (or very close to) melee range, and the throw is angled in a way that will send the Poison Headcrab directly at the player. If they’re in an unreachable spot, the Poison Zombie will usually throw the Headcrabs repeatedly without pause until they run out.
The Poison Zombie As A Level Design Element
Posion Zombies are one of the most durable humanoid enemies in the entire game, with over triple the health of a Regular zombie and an immunity to bisections from explosions or sharp objects. Even if they’re shot in the head, it can take multiple magnum rounds or two RPG direct rockets to take them down properly, making them an extremely important threat that many players will try to take out as quickly as possible. They’re perfect for a “tank” role, acting as a slowly-approaching bullet-absorbing obstacle that can back poorly-equipped players into a corner: they aren’t particularly fast and they have limited ranged attacks, but one or two Poison Zombies can put a lot of pressure on player without many weapons.
Their ability to deploy Poison Headcrabs also gives them a certain level of area denial, since they’re more likely to throw them if the player is far away or on a surface they can’t reach. This makes it incredibly hard for a player to just hide on a raised rooftop of object, and can harass the player into changing positions where they’re more exposed. While no amount of Poison Headcrabs can actually kill the player, they can still wear down their valuable health straight through whatever shields their HEV suit has.
The instant reduction to 1 health point also means that even the smallest type of damage can immediately kill them. If a Poison Zombie gets a chance to drop one or more of it’s Headcrabs, they can work together to instantly kill the player under the right circumstances. However, this means that they can also be ranged support for other Zombies: if the player’s getting pursued by a crowd of the regular variety, a single bite of a Poison Headcrab can temporarily make the fight much more weighted against them.
Each Headcrab can also take a while to kill, which is compounded by the fact that they have slightly more health than a standard Headcrab (just under double). Since a single Poison Zombie can be come up to four targets at once (and even sometimes drop it’s own Headcrab when it dies, giving it an extra chance to harm the player), a handful of Poison Zombies can saturate an entire room with extra targets, taking up a lot of the player’s resources if they don’t have another way around. If there’s a shortcut or some alternate path they can take, then this makes for a great natural barricade instead, pushing players to use the environment rather than just force their way through.
When mixed in with normal Zombies, many players will see them as a “commander” and try to take them out first, which you can exploit to draw attention away from other groups of Zombies coming from behind. They have very little setting them apart from normal Zombies once their Headcrabs are thrown, but their darker colours and bulkier, hunched posture mean that they stick out more in crowds.
As with regular Zombies, they’re ideal “filler” to include some challenge and hostility into an area without many enemies, and the threat they pose can make many players stop to fight them, even if it’s not necessary. If the player doesn’t have many offensive options, they’re also a good way to keep players on the move, either by harassing them from a distance in open spaces with Headcrabs or slowly swarming after them in linear areas.
Poison Zombies are a relatively minor threat to a fully-equipped player with a lot of room to move around, but their ability to suddenly deploy tough and health-draining Poison Headcrabs adds a lot of extra lethality to a group of assorted Zombies. If the player doesn’t have the tools and time to take them out quickly, even a single Poison Zombie can deliver a quick kill if they get close enough: a fact that can make players focus on them, even if it’s entirely unnecessary and opens them up to being flanked by a letter enemy.
Even from a distance, they’re not harmless – a thrown Poison Headcrab can spread a Poison Zombie’s presence much further, and they’re much more dangerous than most other enemies when it comes to long-range harassment.
The standard Half-Life 2 Zombie is one of the most basic humanoid NPCs in the game, but there’s still quite a deep level of complexity build into how the NPC operates, reacts to its surroundings and the way it can interact with environmental objects.
This entity profile will be an in-depth look at the Zombie, it’s traits as both an NPC and entity, and how it can be adjusted or controlled by mappers.
The Zombie As An NPC
The regular Zombie is very similar to the kinds of zombies you’ll see in horror films – slow, durable and not very bright, with no way to fight at a distance and very limited coordination. However, unlike your average “horror movie zombie”, Half-Life 2’s undead are still fairly smart when it comes to navigation, and this can be improved on even further with certain mapping tricks or techniques. Zombies are some of the most common enemies in a lot of Source Engine mods, mainly because they’re easy to work with – you don’t need to create complex scripted sequences of them talking or using equipment to make them believable, threatening and sometimes downright scary.
Zombies have different behaviour to gun-toting enemies. Their primary goal is to get to the player and attack them, regardless of the situation, so they’ll stop at almost nothing to close the distance even if it puts them in harm’s way. A good example of this is the spinning trap in the base game’s Ravenholm section – whereas other NPCs will generally avoid a moving object that could kill them, a Zombie will wander right in and get sliced in half, since they’re focused on nothing but the player.
To facilitate this kind of behaviour, they have an ability that no other class of NPC gets: they can shove objects out of their way or towards a target they’re chasing, causing minor to significant damage to the entity it hits depending on what the thrown object actually is. This can also break down wooden barricades or cause fragile items to shatter or break. This isn’t really a ranged attack, but it can still act like one if they’re lucky enough to hit the player.
There are two additional events that can happen when a Zombie is killed, neither of which are directly controllable by the player. The first applies to every Zombie type – if they’re killed in a way that doesn’t damage their head very much, their Headcrab can pop off and attack the player itself even after the body is dead. The other, which only applies to regular Zombies (and Fast Zombies in the Half Life 2 episodes), allows them to survive explosions or bisection as a crawling torso.
Zombies can also “sleep” by lying down or against a wall, waking up when a player passes by or they take any damage. This is mainly used to scare players or keep them on their toes in areas full of Zombie corpses. In addition, when set on fire, they’ll continue walking after the player rather than stopping and panicking like other NPCs, but will still eventually die if the fire persists long enough to drain their health.
The Zombie As An Entity
As an entity, NPC_Zombies are one of the most basic functional NPC types in the engine, with no unique Flag options or settings. They also don’t respond to tactical options very well – while they’ll still follow Squad rules or other similar settings, they won’t be able to carry out the goals they’re given nearly as well as more intelligent NPCs.
All of their unique attributes and abilities are built into the entity itself, so you don’t have a way to easily turn them on or off without altering the entire NPC_Zombie entity. There’s also nothing particular special in their Inputs and Outputs, with almost all of the options being shared across all other NPCs.
Despite it’s intentionally limited behaviour as an AI, it still responds well to navigation meshes, paths and other movement-based interactions. Like any other NPC, they won’t head towards you in a straight line, so a good navigation mesh will allow them to get through complex areas without getting stuck.
The Zombie As A Level Design Element
Zombies are the most basic living threat a player can come across, which makes them far more limited in terms of how they can be used in mapping. However, it also opens up a lot of interesting ways to experiment with them, especially if you’re able to turn them into a genuine threat.
If there’s one thing that sets Zombies apart from regular enemies, it’s the way they respond to cover and obstructions. Against normal Zombies, cover is practically meaningless to the player, since it restricts their view and makes it much harder to keep track of each individual threat without reducing the danger they’re in. Zombies, obviously, can’t fire back at you, so cover won’t do you any good – there’s nothing to take cover from.
A single zombie is a decent match for a player with no weapons or nothing but a melee attack, but becomes irrelevant once they have a ranged weapon. Ammunition scarcity can be a good way around this, especially if the player has to decide how much ammunition they can afford to waste killing a Zombie that might never actually get in their way. This is the single most useful factor when you’re designing good Zombie encounters: limited resources. Limited space, ammunition, health or time can all turn a simple low-level threat into something much more dangerous, and even a fully-equipped player can be given a fair fight if they’re not given any high ground to work with.
On the other hand, they make great “filler” for maps where you want the player to expend ammunition without necessarily being in constant gunfights. Standard Zombies are psychologically threatening thanks to their excellent sound design and stiff movements, and players might even enjoy finishing them off when it’s not necessary as target practice. Depending on a player’s personality, they might even aggressively attempt to hunt down all zombies in the area, which can make them a good way of eating into the player’s ammunition reserves and forcing them to play more conservatively.
On the other hand, an infinite swarm of regular, slow Zombies (such as in Half Life 2’s Ravenholm section) can do the exact opposite, persuading careful and exploration-happy players that they need to keep moving and should focus on avoiding enemies rather than trying to take them all out.
Overall, Zombies struggle to be a threat if the player has ranged weapons, is a fair distance away, is in an unreachable area or can easily evade them by moving around a large open area. However, if they’re used correctly, they can become a major threat that’s able to hound players into certain areas or deny certain pathways to them, and can exhaust their ammunition supplies thanks to their hardiness.
They’re not the most dangerous enemy type, nor are they the most intelligent or varied, but they make up for it with the fact that they’re a very simple, single-minded hostile presence that will always try to close in on a player, making it very likely that they’ll get backed into a corner.
Path_Track (and it’s sister entities, such as Path_Corner) is one of the simplest yet most versatile point entities in Source, and it’s one that many people never get a chance to fully try out, especially since it doesn’t seem very complex from the outside.
To put it simply, Path_Track lets you mark out paths that other entities can follow, whether they’re NPCs, moving objects or other invisible entities that the player never gets to see. It’s not the same thing as a navigation mesh, since it’s not telling NPCs where they can and can’t go – it’s just showing them a path that they’re supposed to follow when triggered in a certain way.
The biggest difference between a Path and a normal navigation mesh is that it tells a character when, where, and how to move, but not why. The chosen NPC (in this example, let’s say it’s a Combine Soldier) will be given a new goal of reaching the next point in the path chain, but it won’t have any context for why it should, unlike the natural movements to avoid grenades or flank the player. This makes it less of an AI tool, and more of a way to set up specific routes that you want something to take during gameplay.
A Path_Track is only one part of a chain, so a full path will take at least two to set up. Each one needs a unique name, and needs to have it’s Next Stop Target set to where the chosen entitles are supposed to go next. The end of the chain doesn’t need to lead anywhere, but you can also choose to have it loop back if you want to create a circuit that makes the entity move in a repeating pattern.
The unique name is important, and not just in terms of the path itself – each path in the math, regardless of what it’s connected to, needs a separate name that isn’t shared with any other entity. After all, a straight path can’t end in two places or split off into multiple directions.
If you do want a path that eventually splits off into other sub-paths or multiple ending points, you’ll either need to create more than one separate path, or set up triggers to change the Next Stop Target of the point that acts as your ‘junction’.
You should also keep in mind that paths and standard navigation AI often work together in an… unusual way. If an NPC bumps into an object in their way, they’ll try to shuffle around it, but they won’t walk around the object if it’s large enough. There are ways to mark a position that an NPC should navigate to on their own, but a path isn’t one of them, and you’ll need to specifically mark out the exact lines they’re supposed to take.
Creating A Path
Creating path points is easy. To start, put one down with the Entity Tool like with any other point entity. It’ll just be a little grey cube, the standard shape of a lot of entities without their own icons or graphics. On it’s own, a single Path_Track is nearly useless, but there’s an easy way to fix that.
First, double-click the entity and add something to it’s Name and Next Stop Target. I personally like to name it after the path’s purpose, such as “Combine_Path_01_P1“, but anything will do. The next stop target, ideally, should be related to the Name (in my case, I’d use “Combine_Path_01_P2), but this is just to make it easier to manage multiple paths at once.
When you’re ready to make another one, select it in one of the 2D views and hold down the Shift key, then drag it somewhere else. This’ll create another path, with a line going between the two. What’s happening here is that the engine is automatically filling out the new Path_Track’s properties to create a connection between them, which is what the yellow line signifies. You can keep doing this if you want – as long as you do it in a linear way, you can automatically create an entire path without having to adjust the settings yourself.
You don’t need to use this shift-drag method, though. In fact, I often do it manually, since it makes it much harder to slip up and create a broken or split path. Every Path_Track entity you create can be altered to change it’s connections, so you can have two separate paths meet at a single ending point, or have multiple NPC movement patterns end up in the same loop.
Like a lot of point entities, Path_Tracks have special properties that you can use to alter how they work. The most notable is an Flag labelled “Teleport to THIS path track” which lets you make an attached entity teleport to that marker whenever they’d normally move to it. This is great for things like trains, production lines or background characters, since it helps create an illusion of there being more to explore that the player can’t reach without forcing you to build an entire looping environment or tunnel.
You might also notice an option for a “Branch Path” in the Class Info page. This is used to create an alternate path, which you can trigger just like any other entity action. The Flag option “Branch Reverse” also lets you mark this alternate path as a way to travel backwards, rather than forwards.
One of the most useful options you can change is the Oreintation Type. If you’ve made something like an elevator or a moving platform that follows a path, you won’t usually want to use the default setting – this’ll make it swing around to face that way it’s travelling, which often results in players getting flung off the side or instantly killed after being crushed against a wall.
The Flags mentioning an “uphill/downhill path” are mainly used in Team Fortress 2, as a marker of how the payload cart should move on slopes. They don’t often apply to other games, but feel free to use them anyway if you want to.
Path_Corner is almost identical to Path_Track in every way, with only a handful of differences that make it better suited to specific roles. For a start, it has a value that you can use to make entities wait before continuing on. You can also adjust how fast objects turn – there’s no option to stop them from turning, like with Path_Tracks, which is why they’re mostly useful for corners (as the name suggests).
Both entities are interchangeable, and you can link them together. You can even use the same shift-drag method to create multiple corners at once, and you don’t even necessarily have to use them as corner nodes at all. However, if you’re actually using them for corners, it’s a good idea to stagger them and use multiple for a smoother transition between angles.
Getting Something To Follow Your Path
Once you’ve gotten a path ready, how do you get something to follow it? Well, it depends on the entity, but most compatible entities will have their own “Next Stop Target” field. Simply put one of the path nodes’ names into there, and that entity/NPC/whatever will start to follow it from the note you’ve entered. If it loops around, they’ll follow that loop indefinitely, otherwise they’ll stop at the end of the path. Player-controlled vehicles like Func_Tracktrain can be driven backwards down these paths, etc, but without additional scripting or triggers, most entities will either stop (if they’re brushes or inanimate objects) or resume their normal behaviour (if they’re NPCs).
One of the most important parts of a 3D engine is its ability to ‘cull’ objects that the player can’t see. Imagine if your brain had to try and perceive everything in the direction you were looking, regardless of whether or not you could actually see it with your eyes – you’d probably end up with a huge headache.
That’s that culling is for. The more a game engine has to load, the slower it’ll run and the longer it’ll take for vital actions to process properly. In most cases, the difference will be impossible to notice, but it’s still there and the engine still feels the weight of the visuals it’s loading. To put it into simple terms, an engine needs to know which surfaces the player will see at any given moment and react accordingly, whether that’s displaying visible ones or hiding ones that are out of sight.
Source, as you might expect, is no exception. However, unlike a surprising amount of modern engines, users have the ability to build the culling settings into their map directly as 3D objects, something that makes even the trickiest changes incredibly simple. It’s all thanks to one thing – visleaves.
Let’s say we have this little shack in an outdoor area – when the player is indoors, we’ll ideally want the area behind the shack to get culled, and when they’re away from the door we’ll want the inside to be culled instead. Since it’s a small area, the engine might not do it for us automatically, but we can force it to.
The texture tools/toolshint is just what we’ll need here. All I’ll do is draw a little block inside the doorway, which will tell the engine that I want a new visleaf to be created here. That doesn’t fully solve the problem, though, since the player indoors will still be able to see the outside world in full.
To fix this, I’ll draw two more, one on either side of the shack, at a point where players won’t be able to peek around the corners of the doorway and see them.
For this example, it’s a little more tricky, I need to use three different visleafs to cover the whole area – I can simply do that by putting them in place, grouping them, hitting ctrl + t and telling them to act as a func_viscluster. Now the Source engine sees them as one block.
Now, if I hop into the game and load up the map for real, everything will look more or less normal. Did the visleaf actually work?
By turning on mat_wireframe 3 I can see that, yes, it did! When I’m on the other side of the house, the inside isn’t rendered at all: the faint red outlines in the first image don’t show any space inside the shack, and the second image shows that everything behind the shack isn’t loaded once I step inside.
This is only a small change, but it makes a big difference if used correctly. Source will try to make its own visleaves automatically, but it’s not always perfect and it can miss spots that desperately need their own culling. Imagine this shack as a giant, equipment-filled warehouse and the outside area as a lush green jungle, and you can see why it becomes so important – the more decorations and graphical “extras” you add to your map, the more load it’ll put on your computer, and culling is the easiest way to ease off some of the pressure a little.
Info_player_start is one of the most recognisable entities among Hammer’s users, and it’s not just because it’s the default selection in the Entity Tool every time you open up a fresh session. Aside from a select few multiplayer games, it’s the single most important entity for determining where a player will spawn in the game world, and it’s silly appearance makes it easy to recognise once you’ve spent a sizable amount of time in the engine.
That’s not all it’s good for, though. It’s the perfect size to measure the width and height of the player’s body, making it a great scale for sizing up certain map elements, and it can be a useful reminder of the angle you want the player to go once the map loads.
On top of this, it’s one of the easiest entities to use, since it only has one optional Flag setting and there’s not really any way it can break. It can’t even be used in scripting or named, so you won’t be able to accidentally create scripts that remove the player’s ability to spawn into the map. It really is as simple as placing it down and leaving it alone.
Using Info_Player_Start Properly
Of course, it’s not flawless, and there are certain times where you’ll need to be careful with how you use it. For example, I’ve run into quite a few situations myself where I’ve placed an info_player_start onto some displacements (if you’re not familiar, that’s bumpy natural ground, like hills or grassy areas) and been stuck in the ground each time the map loaded. In other cases, I’ve accidentally put it in a position where the player will be seen by enemies before they get a chance to turn in the right direction.
Ideally, you’ll want to make sure that your spawn points are on flat surfaces (or non-solid displacements with clipping brushes in them) with a few units of distance between the bottom of the entity and the ground. This helps avoid issues with the player’s physical avatar, but doesn’t impact their gameplay experience (three units is equivalent to about five centimetres, which is barely noticeable even if you record and play back the footage at a high framerate).
Remember – this entity isn’t just a spawn point, but it’s the physical location your players will appear. Anything that can see, touch or block the entity will also block them, since Source doesn’t use any special spawning rules by default, even in multiplayer games. If you drop an info_player_start directly into the path of a mounted gun or explosive object, they’ll have to deal with the hazard almost immediately, which is usually seen as terrible level design unless it’s deliberately delayed long enough for them to escape.
This is doubly true for multiplayer games, where other players can retain knowledge that NPCs and AI-controlled characters can’t. Say you have a spawn point in a very visible, accessible location: there’s nothing stopping the other team from standing right behind it and blowing away anybody who appears there. This is the main reason why games like Day of Defeat: Source use one-way ramps that block access to the spawning areas, making it impossible for the enemy team to see the spawn points in normal gameplay.
Things To Remember
- One info_player_start in every map can be given the “Master” flag. This means that it will override all other copies of the entity in the map, which is great for games where you need to force a player to always spawn in a certain area. This can also be used for testing purposes, since you can set yourself to spawn further in the level without having to remove all your other spawn points.
- The “Green Freeman” model used for this entity (in most games) shows the exact measurements of the player’s height and width while they’re standing, and it can be used as a scale for tight areas and claustrophobic environments. Note: Certain Source games, notably Team Fortress 2, have different player measurements. Counter Strike: Global Offensive uses the in-game Terrorist and Counter-Terrorist models instead, but the entity’s bounding box is still useful as a virtual measuring stick.
- If you’re using cordoning to compile certain pieces of a map without including the others, you can use different info_player_starts to set up different spawn points for each area. This is another good use of the “Master” flag, since you can keep one spawn point as the main one while still having others for specific section you want to test.
Hammer and Crowbar is something I’ve wanted to create for a while, but I never gave myself enough time to actually start working on it. Today, I decided to just push straight into it.
Welcome to Hammer and Crowbar.
This site is a bi-weekly community resource site that’s meant to help people learn more about the Source Engine and it’s companion SDK, mainly in terms of making new maps and mods that add new gameplay to some of your favourite Source Engine games. I’ve had a lot of experience with different aspects of Source, and it felt like I should try to put together my own resources for new modders and mappers – it’s definitely not the easiest game engine to learn, and I wanted to create something that would let people skip the hurdles and setbacks that I had to go through.
Until recently, most of my experience with Source came from trial-and-error tests. Even things as simple as building a working level were done with very little outside help or documentation, and I’ve only started turning to other online resources now that I’m trying to make full-scale mods of my own.
This has given me something quite useful that a lot of other guides overlook – I know how the engine reacts to mistakes. No matter how confident you are, you will make mistakes while you’re learning to use Source, and being able to identify their causes and the relevant solutions is something that not all online resources cover that well. There’s also the fact that some official and semi-official sites, such as the Valve Developer Wiki, are simply missing some pages on specific entities and objects for no explained reason. I’m not against ‘learning by doing’, but not having a way to quickly search up the purpose of something has been a huge problem for me in the past.
Welcome to Hammer and Crowbar. I hope you enjoy your stay, and feel free to come back weekly for more posts and articles that might help you on your journey into Source!