AI Misbehaving

So far, the few bot tutorials that I've seen have seemed to consist entirely of:

• Run BSPC on your compiled .bsp to create a bot navigation (.aas) file.
• The End.

Ah, if only it were that simple.....

Unless you are extremely lucky or your map is one box with a rocket launcher and a spawn point in it, the bots will probably play really dumb. Worse still, you may encounter 'bot stutter' - an uneven framerate caused by CPU overload on the bot AI. Now its very easy to say "well, this map is designed for human players anyway so I'll leave it" but the sad fact of the matter is that its quite unlikely that your map will end up on any servers, so its worth making the botplay as good as possible. Happily there are several things that can be done to improve matters, and this tutorial is here to tell you what they are. However, before we start there are a few things bots will never, or hardly ever, do:

• Bots will not usually shoot at a shootable trigger or button.
• Bots will not press a button voluntarily (although you can make them using an item_botroam - but these are not conditional, so the bot will carry on trying to activate the button even if it isn't necessary, and/or won't go for it above anything else when it is necessary)
• Bots are pretty rubbish at working out jumps and even worse at working out rocket jumps and strafe jumps. If an area of your map can only be reached by jumping don't be surprised if you can't get the bots to use it.
• Bots will only try to get floating items (those flagged as 'suspended') by using jump-pads and launch-ramps. They won't jump or deliberately fall off a ledge to get a suspended item

K, now that's out of the way, download a copy of Q3map2Toolz if you haven't already got it (makes compiling the .aas file self-explanatory) and let's get on with the optimisations:

Simplify the collision hull with playerclip, weaponclip and botclip

Bots like simple blocky shapes to maneouvre round. They especially like blocks which are axial (parallel to the gridlines). Of course, you could just build your map out of axial blocks, but it would probably look a bit pants. This is where our various kinds of clip come in.

Weaponclip blocks the movement of players, bots and weaponfire. Playerclip blocks players and bots, but allows weaponfire through. Botclip only blocks bots.

Important note: Bots will fire through botclip, but seem to view playerclip as impenetrable.

The good thing about botclip is that it does not affect a human player in any way, so you can stick great big huge axial botclip brushes round more complicated architecture and no-one will ever know. Except the bots, who will like you and your map a whole lot better. Oh, and BSPC which will compile a whole lot faster too.

Remember that the only way a player will notice a botclip brush is if it stops a bot from being thrown through an empty space by an explosion, or if it is really in the way of a normal route round the level. Otherwise, the bots will just navigate round it and nobody will be any the wiser.

Stick botclip brushes everywhere you can get away with it to simplify the collision hull that the bots see. Prime contenders for clip intervention are:

• Empty spaces above the players that the bots will never be able to get to can be botclipped - for example, in Q3DM4 there's a lot of this because the ceilings are so high.

• Walls/floors/ceilings with lots of architectural detail - this kind of thing should usually be flattened with playerclip because it will probably get in the way of human players as well. Playerclip also acts as botclip - you don't need an overlapping botclip brush.

• Curvy pipes and suchlike - any complex patchmeshes can complicate the .aas file unnecessarily. Make them non-solid and encase them in simplified weaponclip brushes as far as possible.*Any space which cannot be reached in the normal course of play - doesn't matter if it is just about possible to get there, if the bots aren't likely to, botclip it off! Look out for small areas under ledges which the players cannot fit into and things like that

Botclip can also be used to stop the bots doing stupid things like jumping off the edge of a map, or not giving themselves enough forward thrust to make a fall from a platform without landing in some hazard. The latter is acheived by placing a botclip brush next to the edge of the platform as shown below - now the bots will slide down it (as long as it's steeper than 45 degrees) and over the hazard, rather than into it.

Sometimes, you can use botclip to make an area that the bots keep killing themselves in more hazardous, so that the bots will realise it's dangerous and avoid it. For example, bots often think that they can land on very small or narrow bits of architecture over hazards, when in actual fact 9 times out of 10 they miss it and fall to their doom. However, you don't want to stop human players being able to attempt it. In this case you can use another steeply angled bit of botclip that makes it impossible for the bots to land on the offending brush - they would simply slide off. Now the bots should see the danger and stop acting like lemmings.

Where you can't use botclip, use botdonotenter

If after all your botclipping efforts the bots still insist on going places you don't want them too you can try using botdonotenter brushes instead. In theory, these create an area which the bots will avoid unless they are pushed into it or there is a worthwhile goal, such as an item or flag within it. In practice, the bots sometimes completely ignore them, so it's just trial and error really. I used a botdonotenter brush just taller than a player to stop the bots loitering over the trapdoors in my first map:

I think they thought they could get down through the trapdoor to the item_botroam I had placed on the jump-pad below, even though the trapdoor was one-way and only triggered from below. Luckily, my fix worked, and didn't stop them using the trapdoor from below and shooting up through the botdonotenter brush (I guess a trigger_push counts as being pushed into the area...?)

What to do if the bots won't use certain parts of your map

First check that there isn't an error in the .aas file which is causing the bots to see that area as solid. To do this, load up your map in devmap mode and type \bot_testsolid 1 into the console. Now you should see a readout at the top of the screen which says either EMPTY or SOLID. Go to the part of the map where the problem is and see if the .aas file is reporting any empty space as solid. If it is, you will either need to simplify the collision hull in that part of the map or use the -forcesidesvisible commandline switch when compiling your .aas file. This should fix any errors but will take a lot longer and is not recommended.

Another way to test for this kind of problem is to load up the map in a teamplay mode and tell one of your team-mate bots to follow you as you go to the problematic area. If they make it OK, then there probably isn't an error, and its just the bots being stupid.

If there are no errors of this type, try placing item_botroam entities in the area. Item_botroams attract bots in the same way as any other item would, and you can control how much they attract the bots as compared to other items by setting the 'weight' key. It's suggested that you keep the value under 400, but for testing purposes you can go higher than this, so make it 800 or something like that. Then fire up the map and see whether the bots go to the area. If they do, then adjust the weight key so that the bots don't use that area too much - if the weight is too high then the bots may keep trying to 'collect' the item_botroam over and over again, because unlike a regular item it never actually gets picked up.

Important note: Just got this tip from [AF]haste - if the bots refuse to use a jump-pad it may be because the target_position at the end of the jump-pad's trajectory is too close to the floor. On his map, increasing the gap from 64 to 96 units did the trick.