Legacy:MarZer/Assault

MarZer's Assault Mapping Tips

Recently, while helping PointlesS with his Assault map AS-CityInvasion, I realised that many mappers are having trouble mapping for Assault. Having completed a fully-pathed and co-ordinated Assault map myself I'm pretty well-versed in the subject. As such, I'm posting a bunch of random Assault Mapping tips (most of which I gave to PointlesS) for mappers to use as a reference:

General Assault Pathing

First things first: NEVER use the autodoor/door actors. They are complete ****. Use 2 pathnodes and force a path between them accross the door. I have noticed bots often get confused when Door/AutoDoors are used.

For every single vehicle path you have, try to have about 3 normal paths nearby. This is good for two reasons: bots on foot will attack/defend from different directions and if the vehicle gets off track, it can use the normal paths to find it's way back.

BlockedPaths, ForcedPaths and ProscribedPaths are your friend. Sometimes, bots just need to be forced:

ForcedPaths: Even if the editor doesn't make a link, you can force it yourcelf by first finding out the name of the node you want the path to (Properties -> Object -> Name), then selecting the node you want to make the link from and going to it's properties. Here, go to the Navigation group and head down to ForcedPaths. In the first item in the list, add the name of the pathnode you are forcing a link to. The next time you rebuild there will be a yellow line between the two nodes. This is one-way. To have it two way like a normal link, do the same thing, starting with the second node and linking back to the first.

ProscribedPaths: Set them up exactly like ForcedPaths, but they tell bots that they SHOULD NOT take this path, no matter what. This is useful as sometimes bots keep taking some stupid route and end up stuck, confused etc.. When you Rebuild, they will be red paths.

BlockedPaths: Sometimes you want bots to follow a path until something happens (a door closes, something falls in the path). This is what blockedpaths are for. Say you have a blast door that is shut and opens when a particular objective is completed. Put a BlockedPath in front of it then make sure that its bBlockedPath property (or whatever it is called) under Navigation is set to true. Seeing as though you will already have nodes on the other side of the door, force a path from the blocked path to one of the nodes on the other side (and back again). Set the tag of the BlockedPath to whatever event opens the door, and when it is triggered (when the door opens), the bBlockedPath property will be toggled to false which lets bots know they can now go down that route.

Vehicle Assault Pathing

ANY objective that requires the bots to use a vehicle, even if it is not mission-critical, should be given a VehiclePathName. You may have noticed this property before, here's how to use it:

In the GameObjective group of the objective, there is the VehiclePathName field. Here, you enter the name of the vehicle-accessible pathnode closest to the objective they should be trying to reach.

Another thing about vehicle pathing: When vehicle Assault mapping, remember ANY navigation points can be used by vehicles as long as bVehicleDestination (under Navigation) is true. In fact, you don't even need RoadPathNodes at all. The only benefit of using those over normal PathNodes is the distance they link over.

Vehicle paths should be as simple as possible: try to keep them as curves as opposed to sharp bends. The reason is this: If you have an L-shaped bend with one pathnode, it looks like an L to the bots. They don't slow down for it and generally crash. If you use a lot of pathnodes close together to round off the corner (say, 5 pathnodes, 300 Unreal Units apart in a curve, making up the corner), the bots will better judge the corner and slow down.

Defensive bots will not use their vehicles unless they see an enemy to attack with. Not by default. It is turned off in the vehicle code. Turning it back on is a simple matter of adding a few lines and saving it in myLevel. These scripts are used in AS-Confexia.

AI Scripts

The AI scripts system is bugged. I noticed this early in the making of HighRise. Here is the way it works:

In an Assault map, EVERY AI SCRIPT IN THE MAP MUST be linked to an objective. The AI in UT2004 is very intelligent, but not intelligent enough to be able to decipher a mapper's random tags and events :p

You do this: The group of AI scripts you want defenders to use when they defend an objective you give the same tag to. MyTag. Then in the properties of the objective they are to defend, go to the GameObjective group. Look for the DefenseScriptTags field. Enter MyTag (subbing in your actual tag obviously). The bots will now know what to do come that objective.

This must be done for every single AI script in the level, there cannot be one single one that is not attached to an objective of some kind or ALL OF THEM WILL FAIL.

Optimization

Fog: No further than 20000 units for the max distance is sufficient for outside levels, assuming you have antiportals and other optimization methods in place.

StaticMesh CullDistance (Properties -> Display -> CullDistance): If you have an indoor Assault Map, there is a good chance you won't be using fog, but there is also a good chance that most of the Static Meshes in the level won't be seen at the same time. By setting the static meshes a CullDistance, they won't be rendered by the engine when they are further away from you than this distance, even if they aren't occluded by fog, AntiPotals or Zones.

Checkpoints: Another thing that you can do is have 'checkpoint' areas close off as previous parts of your map become empty (as the mission progresses). This allows you to trigger antiportals to hide these unused inaccessable areas, making rendering much less taxing.

Doors: Make an antiportal that is the same size of your door but a bit narrower. Put it over the door. In the properties of the door, go to the Mover group. In AntiPortalTag set it a unique name. Then in the properties of the AntiPortal, go to the Events group and set its Tag the same as what you just entered in the mover's AntiPortalTag. Go to the Movement group and set the AntiPortal's AttachTag to that of the tag of the door. Then go to the Object group (still in the AntiPortal's properties) and set InitialState to TriggerToggle. This will stop whatever is behind the door (line of sight, unless the door is a zone portal as well) being rendered when the door is closed (when the AntiPortal is active and down) but when the door opens the AntiPortal gets turned off and moved out with the door, so it is as if it was never there. When the door shuts again it turns back on. This is very useful if you have a lot of indoor-outdoor areas.

Hiding Areas: When you place an AntiPortal it is turned on by default. Triggering it will disable it (provided it's Object -> InitialState property is set to TriggerToggle). You can use a sheet AP to stop rendering of all the behind bits of a map until players can actually get in there, at which point you turn it off.

AntiPortal size: Remember, one big antiportal is always better than lots of little ones. Always.

Zoning: Try to place ZonePortals in a place where they wont be seen that often. This causes the other zones to be rendered less often.

That is all for now, I hope it helps some people. I will update this later, as well as writing a decent Assault mapping tutorial that gets into the nitty-gritty, evil, nasty bits of it at some point. Feel free to add things to it (hey, this is the Wiki after all!)

Discussion

Graphik: Before you link to this page on Gametype:

If you desire this page to be part of the 'public domain', please create a new page for it not subpaged from your personal page. Anything on or below your personal page is considered just that: personal.

Additionally, a bit of cleanup is in order. If you move this content to a different page as mentioned above I'll do the cleanup for you if you like.