Always snap to grid
In order to act more like free-thinking humans, bots must be given a wide range of options at any point in the map. To understand why bots act the way they do and how to make them act differently, it helps to understand how a bot thinks. See also Bot and Mind Reader for UT.
Bots see the world in two ways: where they can go and what they want. At any given moment, a bot's attention is on their immediate goal (an adrenaline powerup, a gun, an enemy, a flag) and how they plan to get there.
Bots know where all items are in a map. They even know exactly when items will respawn, if the WeaponsStay option isn't used.
Bots know how to move around a map because of a network of Bot Paths the mapper has designed. Bots automatically know which route is shortest and even which paths are blocked no matter where they are in the map.
Distance fog does not affect bot visibility. If someone is in their field of view, they will be spotted no matter the fog density.
Usually "what they want" is the most powerful item that's closest to them. Normally "how they get there" is simply the shortest route. Depending on circumstances such as AssaultPaths, bot orders, AIScripts, weapon preferences or gametype rules, these goals change.
Bots are single-minded and completely forgetful. They approach their immediate goal with no knowledge of what they were just doing, so bots can get stuck doing something, stopping, and doing it again. Their immediate goal momentarily changed, then changed back. This can be observed as a spastic stutter followed by a resting pose and, if the bot is truly stuck, will be followed by suicide so the bot can respawn. This is typically called "getting stuck", and it happens when a bot cannot reach a goal, although the map's botplay design says they can.
A squad is two or more bots controlled by the actions of a leader. Squads are formed when one player or bot calls for backup or a bot volunteers. ("I got your back.") A leader will move and act normally, while the rest of the squad follows the leader no matter what happens. Following bots will fire on enemies on sight, but will not chase them unless their leader decides to. Following bots who are killed will search for their leader immediately upon respawning. Following bots in the middle of a firefight will often retreat to seek out their leader who just died and has respawned elsewhere.
Following bots move to the path nodes nearest the leader, and once there if there is no movement by the leader, feel free to move around a little; to the next node or two, in order to get an extra powerup or fire on an enemy. In other words, following bots still have their own goals in mind, but they simply can't act on them if the leader's actions conflict.
Depending on gametype, bots will be given certain rules and guidelines to follow. These rules often supersede the bots' individual goals. They know that in CTF, "Attack their base." means retrieve the enemy flag and bring it back to our base. In DDOM, bots know that holding both DominationPoints is the key to scoring. Typically gametypes with more complex rules require higher skilled bots to perform well.
At various skill levels, different pre-programmed tactics are engaged. This gives the player a greater challenge for each increase in enemy bot skill level. A mapper designs botplay keeping in mind that lower skill bots have limitations. (The following is a loose description, but it's been checked against the Bot code. Actual limitations are a little technical, but this gives a good idea of what's happening.)
- Run at 60% of full speed, No translocator use, Will not move while engaged in combat unless very weak, Limited perception; field of view 30°, modified by BaseAlertness, Weak aim that can range ~30° off target, Slow to turn (RotationRate.Yaw = 30000, less than 1/2 turn per second, adjusted by ReactionTime).
- Run at 70% speed, No translocator use, slightly higher accuracy. Turn just a little more than 1/2 per second, adjusted by ReactionTime.
- Run at 80% speed. Translocator use. Will move and fire simultaeously. Field of view 40°, modified by BaseAlertness. Turn more than 1/2 per second, adjusted by ReactionTime.
- Run at 90% speed. Can DoubleJump. Field of view 60°, modified by BaseAlertness. Turn more than 5/8 per second, adjusted by ReactionTime.
- Run at full speed. Will dodge enemy fire. Will close in on enemy. Aim "leads" the target. Field of view 80°, modified by BaseAlertness. Turn almost 3/4 per second, adjusted by ReactionTime.
- ImpactJump use. Shock combo use. Will switch target enemies during combat. Will stop to replenish powernodes instead of heading straight for a vehicle. Field of view 100°, modified by BaseAlertness. Turn almost 7/8 per second, adjusted by ReactionTime.
- Will dodge enemy aim. No limits on perception; field of view 120°, modified by BaseAlertness. Will evacuate a vehicle if it is unable to avoid and will be destroyed by an incoming avril. Turn all the way around in less than 1 second, adjusted by ReactionTime.
- All strategies and tactics are engaged. Omniperceptive; they see players and objects even without line of sight. Highest level of accuracy, ranging less than 1° off target. Turn 1/2 times per one second, adjusted by ReactionTime.
Some special events or settings effect individual bot behavior.
Custom attributes are set up for each player model. Aggressiveness, Combat Tactics, Favorite Weapon, etc. are values used as extra impulses to alter the normal goal and path finding code.
If a bot is killed, sometimes the bot will seek out the killer as their immediate goal. They can still be distracted by items or combat. Pawns who have hurt the bot are added to a list of Enemies. The bot will seek them out in the order they were listed until all Enemies are dead (removed) or the bot has died. Players have priority on this list.
Bot paths govern the routes bots plan to take from their position to their immediate goal. These paths are made up of connections between items, like the weapons in the map or nodes added specifically to the bot path network. These connections have limitations of length and by available navigating space. In UnrealEd, these connections will show up as lines that are color coded to indicate the size of available navigating space, whether a path is forcably blocked, or to indicate a special kind of connection, such as a JumpPad destination.
Too many pathnodes in one spot can result in bots getting stuck. Too few pathnodes in your map can result in inefficient navigation. See also NavigationPoint.
PlayerStarts and Items
Bot automatically assume a PlayerStart is a safe place to be, as are spawn points for weapons and items. Because a map's item, weapon, and PlayerStart balance takes precedence, these nodes normally make up the start of the bot path network.
Bot Movement Along the Path Network
The bot movement is actually quite simple. The bot first decides where it wants to end up. Usually a powerup or a weapon, but sometimes it is an enemy flag, ball, ball gate, etc. If that object is not a pathnode itself, it finds the pathnode nearest its goal. If it is a pathnode than the object itself is used.
The bot then finds the pathnode nearest itself. It then traces the "best" path from its goal/goal's nearest pathnode to the nearest pathnode. It then makes a beeline from pathnode to pathnode until it reaches its goal. The bot will interpolate a little bit to prevent it from suddenly changing direction when it touches a pathnode. Note that a bot will generally only make beelines between pathnodes, so you must place a pathnode at any place that the bot is going to have to turn. If the lines connecting pathnodes cross ANY solid obstacle, the bots will probably (but not always) have problems getting around that obstacle.
Bots do not generally seek out other players, preferring to find pickups until the player eventually finds itself within their field of view. If the player runs away the bot may "hunt" it for a short while. During this time the bot has the target player as its "goal" actor.
Occasionally a bot can get "stuck" and moves from one node to another, back and forth. The cause is related to the bot's current goal; a pickup, a LiftExit, etc. For one reason or another, the bot believes the goal is reachable, but it cannot reach it, so it turns back only to decide it should try and reach it again. That behavior can continue on indefinitely in some cases. The are two possible solutions for this:
- Place another node to allow the bot to reach their goal.
- Move things around a bit; either the PathNodes or the bot's goal item.
See also Testing Botplay for techniques to determine bot's goals.
- Bot Support – Main topic
SuperApe: When merged with Testing Botplay, this page was meant to be a helpful reference in troubleshooting problems with botplay. The bot motivations are outlined here, the techniques for testing botplay are there. I wouldn't have separated them, personally.
amitakartok: The bot's aim isn't means where is the crosshair . For example, an AVRiL will always hit the intended target regardless of skill level and Novice bots in AS-Mothership have the same aiming capabilities as a Godlike bot (because the fighter's lasers are ignores all aim modifiers, e.g. Auto Aim; bots' aiming probably depends on this kind of modifiers). I also repeatedly observed that if the player wasn't visible, only the flying drone of his/her SPMA, the first bot seeing it have took it down immediately.