Audience: Level designers, programmers.
Last Updated: 07/01/98
Typically, you will use the default values for the parameters below, with the following exceptions:
The following initial orders can be given to all creatures. After killing an enemy, they will attempt to continue to execute these orders. Some orders (patroling, guarding) are associated with other actors in the level. For these, you should set the creatures OrderTag to the tag of the associated actor.
The default orders for all creatures. Creature will wait in place, playing various waiting animations, until it receives some external stimulus (sight or sound).
Patroling creatures will patrol along a set of Patrolpoints (a subclass of NavigationPoint) specified by the level designers. The creatures OrderTag should contain the tag of the first Patrolpoint in its patrol. When a creature reaches a Patrolpoint, it will pause for the PauseTime specified in the patrol point, facing in the direction the Patrolpoint is oriented. While pausing, it will play waiting/patrolstop animations. If a PatrolAnim is specified, the creature will play that specific animation the number of times specified by NumAnims. Each time it plays the animation, it will also play the PatrolSound if one is specified. Note that the amount of time creatures playing a PatrolAnim pause depends on how long it takes to play the animation NumAnims times, and not the pause time. However, the PauseTime must still be set to a positive number. It will then continue to the Patrolpoint specified in the current Patrolpoints NextPatrol. If a creature cannot reach the next patrol point, it will wait at its current position. If bFixedStart is false, the creature will start at some random point along his patrol route (not yet implemented).
Guarding creatures will guard the actor whose tag equals their OrderTag. They will remain near, and try to return the guarded actor after combat. If their initial attitude is ATTITUDE_Threatening, they will threaten the player, and try to remain between the player and the guarded object. If the player touches the object they will attack.
The creature is waiting, but more alert than in the waiting state (and possibly playing different animations). If bFixedStart is false and there are Ambushpoints (a subclass of Navigationpoint) with the same tag as the creature, the creature may randomly pick one of these as its starting point. The orientation of the Ambushpoint determines the orientation of a creature using it. Ambushpoints may also be used by creatures that decide to ambush rather than pursue a player.
Horseflies, biterfish, and blobs all use variations of swarm AI. Do not place individual Horseflies and biterfish in your map. Rather, place horseflySwarms and biterfishSchools, and specify in their properties how many individual creatures they should contain. For blobs, add a parentBlob and a number of bloblets, and give them all the same tag.
You can place pathnodes manually, or you can use PATHS BUILD LOWOPT from the console to get a first pass placement done automatically. In any case, you must do a PATHS DEFINE from the console to create the connections between pathnodes.
To use the navigation system, a creature must first choose the best nearby node to
"get on" the network. For performance reasons, creatures limit their search for
path nodes to those within an 800 unit radius (see FSortedPathList::FindVisiblePaths in
UnRoute.cpp). This is because the test to determine if a creature can reach a path is very
expensive. However, once creatures are "on the network", travelling from
pathnode to pathnode, they use the reachspec tables in each pathnode to determine
reachable nodes. There is no distance limit for reachspecs, so paths may be defined
between two pathnodes which are any arbitrary distance apart. For performance reasons,
paths between distant pathnodes which have a suitable alternate
path using intermediate path nodes (with a low added cost) are culled from the path network.
I recommend that paths should be less than 700 units apart, so that creatures don't ever start off going in the wrong direction to get on the network. In addition, paths on stairs and ramps should be closer together (<350 apart) Given that, you should use the minimum number of paths needed to cover the area for which you want intelligent navigation. Note that all navigation points are equally used as paths, so there is no need to place pathnodes redundantly near patrolpoints, etc..
Paths should in general be placed at intersections, making sure that they have the maximum visibility in all potential directions. Paths need a line of sight to each other, clear to the width of the maximum width (2 * collisionradius) of creatures which will use this path. You should also place paths on ledges, with a line of sight to paths below, so that creatures can intelligently navigate jumping off ledgest. Vertical line of sight has no extent requirement.
In UnrealEd, look at the Properties menu in the map view window. There is an option to show the path connections. These are best looked at using the overhead view. Note that a connection between two Navigation points indicates that at least some creatures can use this path. However larger creatures, or creatures which do not support certain movement modes (e.g. the bCanJump, bCanSwim, etc. attributes of pawns) may not be able to use these paths.
Creature and thing factories may be triggered by a trigger whose event equals the creature factorys tag, or will trigger themselves if a player touches it. Since zone changes can cause an event, you could for example cause a creature factory to start producing razorfish as soon as a player enters the water. The first creature spawns instantly. Creature and thing factories use Spawnpoints ( a type of navigation point) as the locations to create actors. Up to 16 spawnpoints can be associated to a given factory. Spawnpoints and creature factories are associated by giving them the same tag. If a Spawnpoint has a tag in its event field, that event will occur when a creature is spawned from that spawnpoint. By default, creature factories are covert, which means they will only spawn actors at a spawnpoint no player can see. A creature from a factory has its event set to the factorys tag (so its death will trigger the factory). Thing and creature factory properties are:
All navigation points have a bPlayerOnly attribute. If set to true, it means that only Players (bots) will use this path for navigation. Its not perfect, but if you put two in a row along a hallway with turns, it will probably keep the creatures from going through that hall. Exceptions are if the creature is close behind a player and in hot pursuit, or if he is already very close to the path when he tries to use navigation.
Homebase of creatures whose tag is the same as the Homebase actor. Creatures who fear the player will flee to their homebase if they have one. There, they will turn and fight. When a creature reaches its homebase, it will face in the direction specified by the homebases orientation. Also, it will check for nearby ambushpoints whose tag = the creatures tag, and if any are found will go to them.
See Ambushing orders.
Automatically inserted during PATHS DEFINE to identify location of inventory (for bots.
See Thing and Creature factories.
See Patroling orders.
Place this Navigation Point at the spot on a lift you want the creature to stand while using the lift. Its LiftTag should be set to the tag of the lift it is on.
LiftExits should be place at the spots you want creatures to wait before getting on a lift. Their LiftTag should be set to the tag of the lift they are associated with.
Alarmpoints are designed to be used in conjunction with the alarmtag to cause creatures to perform complex actions upon seeing a player. If the Alarmpoints event is set, it will trigger all creatures with that tag when the alarm creature reaches the Alarmpoint. The attributes are:
Creatures may be able to walk over any opening up to 3X their CollisionRadius. If you want something to definitely fall in, or not be able to cross without jumping, make it bigger than this. Also, make sure that most hallways, and particularly intersections and corners are at least (4 x CollisionRadius + 10) of the largest creature you want to navigate it (so that two creatures wont get hung up with each other. Ideally, hallways should be at least 6x the CollisionRadius of the largest creature which may navigate it. Also WarpZones should be at least 70 units deep ideally to allow the AI to handle them properly.
Creatures that have not engaged an enemy can be triggered by a trigger whose event equals the creatures tag. Creatures that are triggered will make whatever instigated the trigger their enemy. You can use this to have creatures ignore the player until a certain event happens, such as crossing some threshold (using ATTITUDE_Ignore) - if bHateWhenTriggered is true, the creature will change its attitude to hate the instigator. Creatures will also trigger their event when they die. You can use triggers in conjunction with bDelayedPatrol to cause a creature to start a scripted set of actions when triggered by the player (without noticing the player).
Two new trigger types have been added. TT_PawnProximity will allow any pawn, not just players to use the trigger. TT_ClassProximity will only allow actors of the class ClassProximityType to use the trigger. For example, you might make a certain switch only operable by a Nali. Also, triggers with type TT_Shoot now also have an optional DamageThreshold value. This is the minimum damage required for triggering (instantaneous, not cumulative). The optional attribute ReTriggerDelay specifies the minimum time before a trigger can be triggered again.
RepeatTriggerTime, if set to a value greater than zero, causes the trigger to send out its event at an interval of RepeatTriggerTime seconds while the triggering actor remains within the triggers radius.
The EarthQuake keypoint can be triggered to shake the players view for a specified duration, as well as possibly tossing players around. It has no effect on other actors. To simultaneously toss around other actors, use the ThrowStuff keypoint. Earthquake attributes are:
The ThrowStuff keypoint can be used to cause actors whose tag matches the ThrowStuff keypoints event to be tossed using the vector specified in throwVect. If Numthrows is larger than 1, the actors will be thrown again after the specified interval. If bRandomize is true, the throwVect will be randomly altered for every toss. Having Numthrows > 1 and bRandomize can be useful for making stuff get tossed around during an earthquake. Other potential uses for a ThrowStuff keypoint include launching a creature in a specified direction when triggered by the player, or turning the physics on of actors when a brush they are on tips and you want them to slide/fall off (in this case, use a ThrowVect of (0,0,0), and they will just be set to falling).
When triggered, this keypoint makes all Nali in the level friendly. This is useful for cases when the player may have scared the nali previously, or to set up situations where the Nali will reward the player after he does something (such as killing a skaarj which was threatening the Nali).
When triggered, this trigger makes the triggering creature jump in the direction it is pointing. It can be limited to trigger once only, or to only affect a certain class of creatures. The Jumper trigger has a JumpZ variable which specifies how high the triggered creature should jump (giving you control over where it lands).
This trigger causes creatures to avoid an area (not perfectly).If you use this, make sure there are also no paths going through the area you want them to avoid. The FearSpot keypoint has a bInitiallyActive attribute, which can be turned on and off by triggering it.
Two new booleans have been added to Movers. bUseTriggered indicates that the brush is activated by a player doing a use (exec grab) on it. BDamageTriggered indicates that damage to the brush will trigger it. The optional attribute DamageThreshold specifies the minimum (instantaneous, not cumulative) damage needed to trigger a bDamageTriggered brush.
Mover bump types are now supported, specifying which types of actors can trigger a mover by bumping it (for movers which are activated by bumping).
By default, all the movers with the same tag will return or stop if one returns or stops because of encroachment. To prevent all the movers with the same tag from acting this way, you can divide them into sub-groups using the ReturnGroup attribute.
The mercenary has several special sets of idle animations accessible through the following attributes - bButtonPusher, bTalker, and bSquatter. If one of these attributes is set true, then these animations will play whenever the mercenary is stopped (waiting, or stopped on patrol, etc.). Note that for bTalker and bSquatter, the mercenary should be talking to teammates (so that the conversation will be synchronized).
bHasInvulnerableShield, bCanFireWhileInvulnerable, and invulnerableCharge are parameters which can be used to adjust the Mercenarys invulnerability capabilities.
The Skaarj has a special set of animations accessible through the attribute bButtonPusher, which work in an analogous fashion to the mercenary bButtonPusher animations. Also, bFakeDeath tells the skaarj to remain laying down until a little after he sees the player. Note that skaarj using bFakeDeath should be placed slightly above the floor, so they dont adjust out of the floor on first seeing the player (thereby giving away the fact that they are not really a carcass).
The Krall has a special set of animations accessible through the attribute bDicePlayer. Krall using these animations should be teamed with several other Krall and closely arranged in a circle. The bSleeping attribute will make a Krall play a sleeping animation and be very un-alert while waiting.
A Nali with orders "Guarding" will play his praying animations. A Nali with orders "Ambushing" will play his meditating animation.
The bNeverbow attribute should only be used with Nali who have a homebase (and only in well tested situations). When enabled, the Nali will not stop and bow while retreating.
Although birds are flockpawns, they are added individually. They have several different selectable behaviours. By default, they will fly around randomly in an area whose size is
determined by their CircleRadius attribute. Note that this area should be relatively free of obstructions, as birds are not smart. If bCircle is set, they will soar around a circle with radius CircleRadius. If GoalTag is set, they will not move until triggered, and then quickly fly to their GoalActor. Birds are now unlit by default. If you want a bird to show off cool light/shadows, then set its bUnlit property to false. Birds that you dont see no longer cost anything. However, be sure not to use birds in big open areas where they can be seen from far away, as the full cost of rendering their mesh still exists, even if they are smaller than a pixel.
The bStayClose attribute (on by default) specifies whether the creature will wander around within its WanderRadius, rather than wandering randomly anywhere.
Pupae can be placed and rotated onto any wall or ceiling initially. When they see the player, they will drop off the wall/ceiling and go at the player.
The bTurret attribute when true will make the Brute stay in place and just fire at the player.
The Mutilating orders are for hub one. The Warlord has a new attribute, bTeleportWhenHurt, which causes him to teleport away rather than dying.
The bNonAggressive attribute when true will make the fish ignore the player. BiterFishSchools have a fishcolor attribute. 0 to 6 makes all the fish in the school the same color, while a value larger than 6 gives them a random mix of colors.
You can add permanent creature and player carcasses (they are a subclass of decoration). If a creature has multiple death animations, you can select the death pose by changing AnimSequence in the Display properties.
Carcass management note: Carcasses are destroyed more quickly in zones that already have reached their limit of carcasses. In less cluttered zones, carcasses will never disappear or change forms before your eyes. The MaxCarcasses attribute of zones sets the limit for "uncluttered" carcasses in a zone. The default is now 3, which should be optimal for most situations.
The ZoneTag is used to tag a zone which is to be triggered by a ZoneTrigger. WarpZones can be triggered to sequence through an array of destinations specified in their properties. Other zones will toggle bPainZone when triggered. The ZoneFog and ZoneFlash properties in ZoneLight allow you to change the players display color/fogging for a given zone.
The ZoneTerminalVelocity attribute changes the maximum falling speed of players in the zone.
There are now also EntrySound, EntryActor, and ExitSound attributes for zones. Zones with bWaterZone set will play these as pawns enter/leave the zone. These are modified for special water zones, such as lava or slime.
When a player enters a TeleporterZone, he is teleported by the associated teleporter (specified by the TeleporterZones TeleporterTag).
There are two components used to create screen flashes. ViewFog is used to color the screen. It is a vector whose components are RGB values between 0 and 1. As ViewFog increases the brightness of the screen, you need to use ViewFlash to keep it from over-brightening.
ViewFlash is a vector whose components should be between 0 and 1 (for example (-0.5, -0.5, -0.5). It reduces the brightness of the screen. Typically, all the components will have the same value, which should have a magnitude about the same as the average magnitude of the ViewFog components to keep the screen from changing brightness.