Always snap to grid
Legacy:Assault Mapping Tutorial/Attacking And Defending
This page is a section of the Assault Mapping Tutorial. If you have arrived here from some other place, this page will likely make more sense if you start at the above link and read the tutorial through from beginning to end.
Previous Section: Legacy:Assault Mapping Tutorial/PlayerStarts And The PlayerSpawnManager
Next Section: Legacy:Assault Mapping Tutorial/Continuing The Assault
Attacking and Defending[edit]
Ok, we've got our map and all of our objectives, and places for players to spawn and equipment for them to use. We just need a couple more things to make this a fully functional Assault scenario.
Bot Pathing[edit]
The basic bot pathing for Assault is no different from most of the other gametypes. Start out by laying out an appropriate grid of PathNodes around the map, so the bots know where they can and where they can't go. Once you've got a basic network down, and checked it to make sure that everything's reachable and all the other standard bot pathing issues, fire up the map in the game and give it a try with some bots to see how it goes.
You'll notice at this point that the attacking bots are able to find and attack the objective automatically, and the defenders are defending as well, but you might also notice something else: For the most part, the bots are always following the same path to attack the objective. This is not a good thing (predictable bots make for uninteresting levels). How do we fix this?
The answer is AssaultPaths. If you've made Capture the Flag, Bombing Run, or other "goal-type" maps before, AssaultPaths may already be familiar to you, but in case they aren't, here's a quick summary:
An AssaultPath actor allows you to specify one of several alternate routes to reach an objective. All AssaultPath actors which share a common AssaultPath->PathTag are part of the same assault path (each AssaultPath actor can have up to four PathTags, so it can be part of up to four different assault paths). Ordinarily, when a bot is deciding how to reach an objective, it picks the shortest route it can find to get wherever it wants to go and follows it. However, if there are AssaultPath actors associated with the objective, the bot will instead look at all of the assault paths available for that objective, and randomly choose one to follow. Instead of finding the quickest path to the objective, the bot will then look for the quickest path to the first AssaultPath actor in its chosen assault path and go there instead. Then it will repeat that process with the next AssaultPath (if there is one) in the path, until it runs out of AssaultPaths associated with the particular path it's following. Once it gets to the last AssaultPath actor for the assault path, it then falls back to its default behavior of finding the quickest route to the game objective from there.
One important point to note from this is that the AssaultPaths really don't define whole paths. Instead, what they really do is tell the bot "go here first, and then proceed from here". This means that in most cases you will not need very many AssaultPath actors if you're careful about where you put them. In a lot of cases, you'll only need one AssaultPath actor for each path you want to define (simply put it someplace where you want the bot to go first, and where the quickest route from there to the objective is a good path for the bot to take anyway, such as at one of the entrances to a base, for example). You do not need to lay out long strings of AssaultPath actors for bots. They're smart enough to figure out how to get where they're going already, you just need to give them a pointer here or there if the way they choose isn't the best one.
In the case of our map, all of the bots are going to take the same route until they get around the bend in the valley anyway, so there's no need to fiddle with that part. We will want them to attempt to attack the base from both sides, though, so we'll need an AssaultPath actor on either side of the base to direct the bots to go to one side or the other.
Add an Actor>>NavigationPoint>>AssaultPath on the left side of the base near the entrance (you may want to replace an existing NavigationPoint with the new AssaultPath). Open up its properties window and set the following properties:
- AssaultPath->ObjectiveTag = BaseDoor
- AssaultPath->PathTag[0] = leftpath
Now also add an AssaultPath on the right side of the base near the entrance on that side. Set its properties as follows:
- AssaultPath->ObjectiveTag = BaseDoor
- AssaultPath->PathTag[0] = rightpath
That's really all there is to it. Rebuild everything and fire it up to give it a try. The bots should now be attacking the base from both sides.
There is one other behavior associated with AssaultPaths: When bots reach an AssaultPath actor, they will sometimes wait to "regroup" with other bots on their team at that point before continuing on. In many cases, this is a useful feature, as it automatically adds some additional tactical ramifications to the bot attack patterns, but in some cases (such as when an AssaultPath is particularly exposed, or you want bots to attack individually for some reason), this behavior can be undesirable. In these cases, you can set the AssaultPath->bNoGrouping parameter to True, which will disable this behavior at that particular AssaultPath point (we don't need to do this with any of our AssaultPaths in this case, though).
Just to add a little more variety to make things more interesting, let's add two more paths with slightly different routes so that even if a bot is attacking a particular side, they won't always be taking quite the same route to get there. Create two more AssaultPaths with similar properties to the previous ones, but set their PathTags to "otherleft" and "otherright", and place them in alternate spots to the left and to the right of the base (you may want to position some further out and some closer in, so the bots follow significantly different paths to get to them as soon as they turn the corner. Take into consideration available cover and other strategic factors). Adjust as necessary to get reasonable variation without having needlessly long routes. You can also adjust the AssaultPath->Priority properties to determine how likely it is that a bot will choose a particular path to follow.
For more help with bot pathing see Pathing for Assault
Defense Points[edit]
Ok, so we've added some strategy to the attacking bots, but the defending bots are still doing their own simple bot things (which basically means they're all huddling around the objective). Time to make them a bit smarter too (again, if you've made CTF, Domination, or similar maps some of this may already be familiar). To do this, we'll be using some UnrealScriptedSequence actors. UnrealScriptedSequences are a fairly powerful way to script a lot of different bot behaviors, but the behavior we're interested in at the moment is just to set up some "defense points" which tell the bots "this is a good place to stand and shoot at things". As it happens, this sort of UnrealScriptedSequence is so common that it's built in as the default behavior if you create an UnrealScriptedSequence but don't give it a custom script of its own.
This makes defense points fairly easy to use: Simply pick a spot, and add an Actor>>Keypoint>>AIScript>>ScriptedSequence>>UnrealScriptedSequence. There are a few other things we'll need to do, though:
- Go to the objective this defense point will be associated with (in this case, our door). Open its properties, and find the GameObjective->DefenseScriptTags property. Set this property to an appropriate tag name (say, "BaseDoorDefense"). Now, go to your UnrealScriptedSequence actor, and set its Events->Tag to the same value ("BaseDoorDefense"). This will cause the defense point to automatically be active when the right objective is active, and disabled otherwise.
- When selected, you'll notice that the UnrealScriptedSequence actor has a little red arrow protruding from it (look very carefully, it's a little hard to see). This indicates the direction that a bot will face when using this defense point. Rotate the actor appropriately to make sure the bot will be facing the right direction.
There are also a few other properties which you may want to change, depending on the circumstances:
- UnrealScriptedSequence->WeaponPreference
- When using this defense point, use this weapon.
- UnrealScriptedSequence->Priority
- Relative priority of this defense point compared with the others for this objective. The higher this value, the more likely a bot will choose this script when deciding what to do.
- UnrealScriptedSequence->bSniping
- If True, this defense point marks a spot which the bot should snipe from. It will stay here, crouch, and shoot at anything which enters the associated SnipingVolume.
- UnrealScriptedSequence->SnipingVolumeTag
- The tag of the SnipingVolume to use for bSniping (Note: You don't have to have a SnipingVolume. If you don't have one, bots will just snipe at anything they see).
- UnrealScriptedSequence->bRoamingScript
- If True, the bot will not stay in this spot while using this script, but will roam around. Since defense points don't really have "scripts", and their main point is to say "go here", this usually isn't that useful, but it can be used, for example, to say something like "pick this weapon and then patrol this general area with it".
(For more information on defense points, take a look at UnrealScriptedSequence and Creating a Defense Point In UT200x)
You will want to put some careful thought into where you place defense points around your map. Keep in mind that a defending bot's natural inclination is to stay close to the objective, so you don't really need to put defense points there, but you will usually want to put some out in advance positions so that the defenders will intercept the attackers before they get too close. Don't place defense points too close to walls or other obstacles, or bots' vision may be obstructed and they may not defend as well as they should. Also keep in mind that bots will pick which defense point to use partially based on whether the WeaponPreference setting matches their own preferred weapon (and whether they have that weapon on them), so make sure to have a variety of defense points appropriate for different types of weapons, to suit different bots' tastes (also note that the PreferredWeapon property is only a suggestion, so sometimes bots will completely ignore it. It's good to place defense points in locations which are effective with a variety of weapon types for this reason).
A well placed defense point can dramatically improve defending bots' chances of holding off the attackers, but a poorly placed defense point can take one or more defenders effectively out of the action or make them sitting ducks for the attackers, severely hampering the defense of the objective. Be careful where you place defense points and be sure to test them thoroughly by observing how bots of different skill levels use them in real gameplay. You will likely have to adjust the locations and priorities of your defense points several times until you get a configuration that works well and reliably.
Critical Volumes[edit]
There is one last little detail which we should add to our objective, which will make defending easier both for bots and humans alike. You may have noticed when playing this level up to now that the DestroyableObjective_SM actor will automatically flash the HUD icon and play the warning sound when people start shooting at it. This is good, but what would be more useful is if it didn't actually wait until somebody was in the process of blowing it up before saying something about it. We can add this functionality with what's known as a "critical volume".
The first thing we want to do is to create a new ASCriticalObjectiveVolume in the map. This volume should be big enough (and the right shape) to enclose any parts of the map which one might consider "close to the objective". For our purposes, let's create a simple cylinder-shaped builder brush with Height=1024 and OuterRadius=2048, then place it over all of the area surrounding the base, and create a new ASCriticalObjectiveVolume there.
The next step is to associate this new volume with our objective. Open the ASCriticalObjectiveVolume's properties, and set its Events->Tag to some appropriate value (something like, say, "BaseDoorCriticalVolume"). Now we need to open up the properties for our base door DestroyableObjective_SM actor, and set its GameObjective->CriticalObjectiveVolumeTag to the same tag name.
That should do it. Now whenever an attacker enters our new volume, it will automatically set off the "objective in danger" alarm, alerting the defenders that attackers are in the vicinity. (Note that this will also affect bot behavior, as the bots automatically know when this alarm goes off to fall back and defend the objective more closely, too.
Proceed to the next section: Legacy:Assault Mapping Tutorial/Continuing The Assault
This tutorial was originally written and contributed to the Wiki community by Foogod. Questions and comments are welcome! Please either leave them on my personal page or at the bottom of the relevant tutorial page. If you see something which is wrong or unclear and you think needs some correction, please feel free to edit the text directly (that's what the Wiki is for!), but please try to keep the tutorial flow intact (no thread discussions in the middle of the tutorial text, please).
Note: To reduce clutter, comments on the tutorial pages will be periodically moved to the Legacy:Assault Mapping Tutorial/Discussion page. Look there for older comments and thread discussions.
