Bot Path Noding 102

By: Adam ‘Muad'dib’ Stiles

http://www.planetunreal.com/muad

muad@planetunreal.com

> PRE-REQUISITES:

> Basic knowledge of UnrealEd.
> Creating basic movers suitable for doors and elevators.
> Gone through the "Bot Path Noding 101" tutorial.
> If you went through my first Bot Path Noding tutorial, then you know that when I left off I mentioned covering some more "advanced" pathing topics such as doors, elevators, and teleporters - I'll be covering CTF related bot issues in a third pathing tutorial. Now let's get down to it!
> DOORS:
> First stop - the easiest of the above, the doors. Doors are pretty straight forward actually, although some folks can run into problems with them depending on how they have their doors setup. First things first, though, you're going to need a map with a door. Now for most deathmatch type levels a sliding door is usually appropriate. Whether it slides up or down isn't the issue - the issue is that the door needs to open fast enough that when a bot wants to run through it, they don't get caught on it. Right? So let's set up a door that would be appropriate for this:
> First create the mover for your door (you should already know how to do this - if not, go through the tutorials at http://unreal.gamedesign.net/). We want just a generic mover in this case - no fancy subclasses, just a simple Brush->Mover with most of the default properties will do fine. You DO need to check the Mover->MoveTime though. This is the amount of time it takes for the mover to go from point A to point B. In this case how fast our door will open - we want it relatively fast so the bots don't get hung up on slow doors so make it 0.5 for now (you can edit this to your tastes later).
> Now place a PathNode actor on either side of the door. Use the "Define Paths" button in the rebuilder dialogue to generate your paths, and then choose View->ShowPaths under your 3D view window. If all goes well, you should have a blue line going between your PathNodes and RIGHT THROUGH the door. Now fire up UT and give it a go!
> Rotating doors (e.g. a door on a hinge) is a similar set up. You do, however, want to be certain that the PathNodes you place don't end up in the path of the door. Make sure they are outside the swing radius of the door.
> ELEVATORS or LIFTS:
> Oh boy. Elevators, otherwise known as lifts - this is a common map item now a days and if you're not used to pathnoding at all, elevators can, well, be a pain in the arse to setup. Here's how:
> Of course, first, you need an elevator. Same setup as a door - just a generic Brush->Mover with most of the default properties. However, this time you NEED to set the Object->InitialState to be "StandOpenTimed". This means that the mover won't move unless someone is standing on it. It'd suck to have an elevator which went flying up at a mere touch (before you managed a foothold on it that is). The Mover->MoveTime property is subjective here. A smaller number indicates a faster move speed in general so set it up how you like.
> Now getting a bot to use this thing is pretty odd. For our example, lets assume that you have an elevator that starts out on bottom, moves to a "top" location when stepped on, and then goes back down after a period of time. In order to get a bot to use an elevator (or a "lift") there are some special actors (that will act as pathnodes if you remember the last pathing tutorial) that tell the bots where to get on the elevator, where the elevator is, and where to get off of the elevator at.
> The actors are called LiftCenter and LiftExit and both can be found in the Classes browser under NavigationPoint. You'll need 1 LiftCenter and 2 LiftExits to get bots using your elevator. The two tricks is to tie them to your elevator somehow and place them in the map correctly. So let's do it.
> First off - enter the properties for your elevator mover. Edit the Events->Tag property and give it some unique name to identify the lift/elevator. In our example lets use "lift1" (no quotes). Great now we have a name for our elevator which will be a convenient way to tie our LiftCenter and LiftExits to it. Now lets go ahead and set those up.
> Create a LiftCenter actor and place it just over the lift/mover - not too close to the surface of it, but slightly above it - about the same distance a pathnode would be off the ground. Edit it's properties and give it a LiftCenter->LiftTag of "lift1" - no quotes of course (this tells the engine which lift this center is for).
> Now create a LiftExit just in front of the lift on the ground - the bot will stand at this spot just before stepping onto the lift - think of it as an entrance point to the lift. Edit it's properties and give it a LiftExit->LiftTag of "lift1" (sound familiar yet?).
> Create your second LiftExit at the top of where the lift will go and place it over the surface that the bot will step out onto after the lift stops at the top. This will be the real "exit" point of the lift. Edit it's properties and give it a LiftExit->LiftTag of "lift1" (bet you guessed that tho).
> Now do the "Define Paths" thing, show the paths and make sure that you get lines (preferrably blue of course) between the LiftExits and the LiftCenter. The LiftExits will act as typical PathNodes (ie the Define Paths will generate paths between them and a regular PathNode) so use some PathNodes to guide your bots to the bottom LiftExit so they'll know how to get to your lift!
> TELEPORTERS:
> With UT there's an easy (easier anyway) way of getting teleporters and bots to coexist peacefully - if you check in your classes browser, you should be able to find a NavigationPoint->Teleporter->VisibleTeleporter. Plopping one of these down in your map will create that neat little blue and white swirly line teleporter that you see all over various UT maps. This teleporter will act as a PathNode. In other words, you can place some regular PathNode actors around it to guide bots to it and the Paths Define function will generate paths between the teleporter and the nodes. So you know how to get one in a map, but the problem now is telling the thing where to teleport a player to!
> There are a couple of options here. Depends on how you want to exit. First we'll cover what to do if you want to come out of the teleporter and NOT be able to teleport back (ie you enter teleporter, and when you exit there's no teleporter around) Second, is being able to teleport back and forth between two teleporters.
> First Option: Not being able to teleport back. This, DOES have it's uses - check my map DM-Overseer for an example of this. There are two teleporters on the top tier - both of which teleport you to the bottom tier. But you can't teleport back - one way trip, and the only way back up is to climb it! So lets set this up.
> Plop down a VisibleTeleporter as described above, edit it's properties and give it a Teleporter->URL of "teletarg1" (no quotes). Ok now we need to create this "teletarg1" thing.
> This teletarg thing is actually the generic teleporter. Create a NavigationPoint->Teleporter where ever you want to be teleported to. Notice it's also got a Teleporter->URL property. Leave it BLANK. But DO give it an Events->Tag of "teletarg1" (no quotes). Generate your paths as normal by now and you should have a functional teleporter that bots will use.
> Second Option: Being able to teleport back. Easy. Create two VisibleTeleporters. Edit their properties separately - give the first one an Events->Tag of "tele1" and a Teleporter->URL of "tele2". Now give the SECOND one an Events->Tag of "tele2" and a Teleporter->URL of "tele1". I.e. they're pointing at each other which is exactly what you want! Now generate your paths and test run it!
> CONCLUSION:
> This, along with the first pathing tutorial should give you a few rounded tricks to use in your own UT maps to make them more interesting for people to play. As ALWAYS take your time with pathnoding - it can often be a tedious process to get the bot behaviour just like you want it (and in some cases your desires may even be outside the realms of the engines limits ;) But good pathnoding can really make or break a level.
> In the next pathing tutorial we'll cover some CTF related pathnoding issues (as well as a few quirks that I've stumbled across and subsequently managed to solve). So stay tuned!