Testing Botplay

Reliable botplay requires a level of playtesting that normal Map Design does not. A complex code of behaviour is being applied to a custom layout and a custom path network. The goal of testing botplay is to find the flaws in the Bot Support system that players might notice. For more information on what the bot's motivations are, see Bot Mind.

Thorough Testing

Proper testing in design requires the widest possible inclusion of all playing styles and settings. Test with and without translocators, adrenaline, super powerups, the WeaponsStay setting, various Arena mutator settings, various Vehicle setups, etc. Test at all skill levels. Test with the maximum and minimum recommended player counts. Test specific obstacles the bots will have to face, making sure doors, triggers, lifts and ladders all work the way they should. Test with various gametypes (like Mutant, Invasion, etc.), if making a general Deathmatch map.

Bot-Only Games

A fast way to test overall botplay is by spectating bot-only games. While spectating, you can use the ShowDebug console command to help see how the bots are performing and how they percieve the environment. By testing with a single bot, you can see how bots react to your layout and path network. This method is used to makes sure bots use the entire layout consistently. This is also a good way to find out why bots regularly get stuck in particular places. By testing with multiple bots, the mapper is able to test more complex issues such as combat effectiveness, proper use of multiple AssaultPaths, and AIscipts.

Incidentally, spectating a bot-only game with the maximum number of recommended players is one of the best ways to judge your map's overall Framerate performance, and to find spots with less than consistent performance.

Using Teammates

Sometimes you need a bot to test a very specifc thing. Rather than watching a bot-only game until the bot happens to try it, a mapper should start a Teamgame of some kind (Team Deathmatch, for example), and using bot orders, command a Teammate to try the test. For example, navigation up a ladder can be tested by calling a Teammate, ("Cover Me."), having them wait, ("Hold this position."), while you climb the ladder and get off it. Then, test by calling the Teammate again. This method works best in larger maps where a single bot on the opposing team won't easily interfere with testing.

Unknown: Alternately, you could disable "balance teams" and "random order" in the practice session dialog and then manually assign the only bot to your team.

SuperApe: I don't think those options are available in UT200x, are they?

Command Reference

Below is a list of commands mappers can use to help test and understand bots in their map.

Bot Orders

In team games, these bot orders can control bot behavior.

Attack their base: This command means nothing except in CTF, BR, DOM and ONS games. In DDOM, this means to attack and hold Domination Point A. (In UT2004, it's actually called, "Attack Alpha".) In other gametypes, bots will simply, "Search and Destroy", or sweep.
Hold this position: This command forces bots to stay close to a particular node in the path network. If this order is given by a leader the bot isn't currently covering or following, the bot may not know which position to hold. A bot will hold the position loosely, leaving occasionally to fight or gather items. Once a bot has died, the position has to be found again, and this might take a while for a bot in Holding mode.
Defend the base: This command means nothing except in CTF, BR, DOM and ONS games. In DDOM, this means to attack and hold Domination Point B. (In UT2004, it's actually called, "Attack Bravo".) In other gametypes, bots will simply, "Search and Destroy", or sweep.
Cover me: This commands the bot to follow the leader, as described in the Squads section of Bot Behavior. The bot will take the shortest route to the leader and stay close to the nodes occupied by the leader. Even after death, followers will seek the leader until given another command.
Search and Destroy: This commands the bot to sweep the map, gathering items and engaging the enemy at will. This is considered the default bot order as it is the same behavior as Deathmatch.

Bot Support Console Commands

These console commands control the game environment with respect to bots.

ShowDebug: This toggling console command causes several objects related to Controller, Pawn, Bot and Weapon status to report information on the screen as colorful readouts. While spectating a bot-only game, you may switch to a bot to see how the bot is acting and what it is acting upon.
showai: A subset of the above. Spectate a bot, and it should plot out their currently planned route through the pathfinding network.
addbots <number>: Any number of bots can be added to the map. (In UT200x, there is a maximum limit in most gametypes, 32. Any gametype that hasn't been specifically modified to accept more bots will have this limit.)
killall bot: This is a specific application of the killall command to remove all bots. In some games, this will result in a win and end the map.
set TeamGame bAdjustSkill 1: This is a resetting of a TeamGame variable using the set command. It will allow the skill level of bots in Team Games to rise and fall, depending on how you, as the player, do against them. You die by their hands: the skill level goes down, you kill many bots: skill level goes up. This function will fluctuate more during the start of a map and settle on an appropriate skill level for the player on that map, because it is based on a ratio of kills to deaths. While this setting is available in the UT2003 menu, it has been disabled in some UT2004 teamgames, and this console command must be used instead.
soakbots: This will display detailed information about botplay, in particular whatever bot you are viewing at a given time. If the bots encounter an AI error of any sort, like if it can't reach a desired navigation point, the game will instantly freeze and the camera view will snap to the offending bot. Relevant data will be displayed on screen. You can hit any key to restart gameplay, but the only currently known way to end soakbot data is to end the match.
ReviewJumpSpots: Exhaustively, automatically tests the jump spots; see Console Commands/Debugging Console Commands. Using this with "slomo 0.5" or so helps to see where things are going wrong.
Note: For this command to work correctly, you need to be a player (not a spectator) and you should not yet have clicked to start the game. If a failed hazardous jump kills the bot, it does not respawn to continue the test.

Discussion

SuperApe: Separating this page from the information in Bot Mind makes this a little less helpful in being a troubleshooting document. I woudn't have done that. This lists the tools you need to test the bots, while the other lists the reasons behind their behavior. Together they could be used as a reference for debugging botplay problems, as I originally intended.

Unknown: (Regarding 32 player limit mentioned in addbots console command) hmm is this limitation 2Kx only? i know i've added huge numbers of bots in original UT without problems.

SuperApe: It's a UT200x limitation.

hellion Zero: is there any known way around this limit!?!?

hellion Zero: i hear that replication is part of the problem

Wormbo: It's about CPU usage and network bandwidth. There are only some servers that can technically handle 32 human players, and bots demand even more CPU power.

Category Mapping

Category Troubleshooting