How to map for ne_dynamic

There are text files included with ne_dynamic that explain how to use the entities and such, but it’s probably easier to read with this blog’s nice formatting…

 

How to make a map for ne_dynamic or How I learned to stop worrying about monsters and love the mod….. ¬_¬

If you use Worldcraft for some reason… you will need this fgd file instead of the included .ent file.

(Necessary) Preamble:

Before we can begin with the actual dynamic aspects of the mod itself, first you must understand the new AI movement system because it is integral to the mod’s functionality.

Essentially, I have replaced Quake’s standard ‘bump around till I get somewhere’ movement AI with A* (‘A’ Star) navigation.  In other words, ‘HL2 style pathfinding’.

I say HL2 style more for accuracy, as probably most (if not all) modern pathfinding uses A* except with different ways of implementing it. id tech 3+ AAS versus source engine navmesh, for example.  Strictly speaking, I find AAS produces better results (especially in id tech 4) and it’s completely automatic, but we don’t have the luxury of using anything like that for Quake.  So HL2 style it is!

 

How pathfinding works:

If you have mapped for HL2, then you already understand roughly how this works.
You place path_node entities all over the floor of the map and at runtime, these entities will connect with each other to form a graph.

Once this is done, monsters search for the player through this connected system of path_nodes and use them to make decisions on where to move next.  This allows them to, for example, path up a spiral staircase or run away from you to get to stairs leading to you instead of remaining trapped in a pit.

I’m not completely familiar with how it works in HL2, but there are probably more limitations in my implementation of path_nodes than the Source engine.

1. A path_node can only be connected to 5 other path_nodes.  If there are more, a path_node will connect to the 5 closest nodes.
2. A path_node can’t connect through doors.  You must use a script_linkNodes entity.
3. A path_node can’t tell if a link to another node is walkable or not.  You, as the mapper, must take care that no links form between nodes that can’t actually be walked.

While placing the nodes themselves does represent a fair amount of work, there is also quite a lot of automation here.  You never need to manually connect nodes that are visible to each other.

 

How the automatic node connection works:

The default search distance for a path_node is 512 units.  You can change this by specifying a distance key.  For smaller areas with a lot of obstacles using a distance of 192 or even 128 helps to avoid too many unnecessary connections.
Any nodes found within this distance will be connected to.
This connection is one-way.  If the other node has a smaller ‘distance’ key, then it will not connect back.  This will create a one-way path where a monster can move from node A to B but not from B to A.
In order to stop a path_node from connecting to another, all that is needed is to break line-of-sight.
Simply create a func_wall (skip textured) and set it’s “think” key to “SUB_Remove” and it’s “nextthink” key to “1.0″. Now place this entity so that it blocks the visibility between two nodes.

This is the only really ‘cheesy’ part about the whole system…  this creates a solid wall during the period that nodes are connecting, and then removes itself before the player bumps into it.

IMPORTANT:  Use ‘developer 3′ in the console to see how your nodes have connected in-game.  Simply walk over a node, and lightning will show which other nodes it is connected to.
Monsters will also have lightning going to the node they are currectly walking to (or to you if they can’t find a path).  Expect to have to fine tune your path_nodes until you get used to the system.

 

How the manual node connection works:

As mentioned above. there are times when nodes won’t connect to each other automatically.  You will need to connect these nodes together manually.  Usually this is for things like upper and lower areas with high walls or through doors.
You use the script_linkNode entity for this.
First, give unique ‘targetname’s to the two nodes you want to connect, then add ‘target’ and ‘target1′ keys to the script_linkNode to match.
If the script_linkNode has no ‘targetname’, it will link at the start of the map.  Otherwise, it must be triggered to link the nodes together.
Setting the ONE_WAY flag can allow for things like a monster jumping down from a high ledge into a pit to chase you and then walking up stairs to get back to the top.
See ne_dynamic.ent for more details on the script_linkNode entity.

 

Final Notes:

Monsters can now trigger lifts.  As long as the path_nodes are set up so that it will bring them onto them, they can use them to navigate through areas now.  (In the dyn_qep1 map, you can see this behaviour in the e1m1 section, where monsters will use the lift up to the nailgun room if you are standing up there).

 

Setting up for Dynamic monster spawning:

How spawning is done:

Ok, the dynamic spawning portion of the mod is probably simpler than all that above was.  If you’ve done any Left 4 Dead mapping, you probably will understand this system fairly quickly.

Essentially, there is an ‘overseer‘ entity that controls where monsters spawn.  How the overseer decides where monsters should appear is by first looking at the path_node you are currently at or near and then ‘flooding’ outwards from there until it starts to find nodes that you can’t see.

If you have set up your path_nodes properly, then simply adding in a ‘overseer‘ and accompanying ‘overseer_classOption‘ entities should be enough to get it going, however a perfect nodegraph from path_nodes is hard to get the first time so you may see odd behaviour.

The important thing to remember is that an inactive (roaming, not currently fighting) monster will remove itself if it cannot reach the player through the path_nodes.  Once the player moves from one connected area to a different area, those monsters just poof out of existence.

In the case of one-way nodes, where node A is connected to node B but B is NOT connected to A, this will cause monsters to not spawn at node B if you are at A unless there is an alternate path (C) to A.

This can actually create a situation where the overseer spawns a monster but the monster removes itself right away.  Here’s how:
If you are standing on top of a ledge, the overseer can potentially flood down to path_nodes at the bottom of the ledge, but when a monster is spawned there, it can’t path back up to you so it would remove itself.  In this case, you must provide an alternate route back up to the player (some stairs or a lift) otherwise, the areas below the ledge will remain unpopulated until you actually jump down there.

 

How monsters are chosen:

Since the whole point of this mod is to minimize what the mapper places in the map, as a result, the mapper has very little control over what the player will encounter.

You can tell the overseer what ‘palette’ of monsters you want to show up, of course, so you can make a map that is only base monsters or only demons.

The overseer chooses which monsters to spawn based on what choices you added via the overseer_classOption entities.
Remember, simply adding a monster as a choice does not guarantee it will appear in the map.  All monsters have a minimum requirement of the player’s weapons, ammo and armor in order for them to appear.

For example, if you added fiends and shamblers as monster choices, but did not provide any weapons or ammo, no monsters would ever spawn.  Conversely, if the player had SG, SSG, NG and SNG and 100 shells and 100 nails, there is a very very small chance for a shambler to appear.  If they had GL, RL, LG, and loads of rockets and cells, expect to see shamblers and vores somewhat often.

It is important to keep in mind what I said about player equipment requirements.  If you give the player all weapons and ammo right at the start of the map (or use impulse 9) you will see powerful monsters right away.
The mod is designed in such a way as to escalate monsters with respect to player loadout.  As you get stronger weapons, stronger monsters appear.  You can indirectly control monsters in this manner and you SHOULD do so!  This makes the player feel as though the map is getting harder as he gets further in like a normal map.

 

Events:

Left 4 Dead has panic events that it uses to spawn in extra monsters during special times.  This mod has a rudimentary system like that as well.

Essentially, placing an overseer_frenzyEvent and triggering it will disable the overseer’s normal check for path_node visibility as well as disabling the normal cooldown imposed on spawning.  This means that monsters will now spawn in everywhere and often, not just areas that the player can’t see.  It also slightly increases the chance of powerful monsters appearing.  On nightmare, for example, it can and often does spawn in multiple powerful monsters such as shamblers and vores.  Remember to give the player adequate protection!

For a little more control, there are also overseer_end and overseer_start entities that you can trigger to both stop dynamic spawning completely, and start it up again.  (Dynamic spawning always starts on at map start, so you don’t need to make one for the beginning).

 

Testing:

The best part about this mod is that testing the map yourself is actually a viable option since you have no way of knowing what monsters will appear where.

You can use ‘developer 6′ to see some console spam displaying player stress level, time until next monster batch spawn and what monsters are currently spawning.

The format is:

stressAggregate: 2439.2 (stress balance: 600), overall chance to spawn: 0 (activeMonsterStress: 0)

stressAggregate represents the player’s stress.  This is a combination of how much damage he has taken, how much damage he has dealt and his health level.  Lower health, sustaining damage and shooting things adds to stress.

stressBalance represents the target stress level the overseer wants the player to have.  If the player’s stress rises above the balance (as it is in this example), it will stop spawning monsters.  Note, however, any monsters currently spawned are not removed.

the overall chance to spawn is simply the % (in decimals) that a spawn will take place each second.  0.1 = 10%, 0.9 = 90%.

When a batch spawn (multiple monsters) occurs, a cooldown is imposed on the overseer before it can spawn another batch.  This does NOT prevent the overseer from spawning monsters, however, it is limited to spawning them in one at a time.

Spawn chance CAN approach 0% if the total number of monsters currently active and chasing the player would require more ammo to kill than the player currently has.

Make sure the player always has enough ammo!