mikeBot's Ability Summary





This is a summary of currently implemented and future plans for mikeBot. The different sections are:

Navigation
currently implemented
Independent Movement
mikeBot can move completely independent of where he is looking, like Stooge Bot. This means his navigation and firecontrol systems don't have to "talk" to each other. (Well, not entirely true; navigation can get firecontrol's current target) It also means that firecontrol can always be active, no matter what navigation is targeting.

Lava Avoidance
mikeBot has low-level lava avoidance, which does the following: his projected movement vector is extendend 128.0 quake units into the furure, and a line is intersected from that point down to max level coordinates in Z (-32700) and if that line intersects lava, mikeBot stops moving. Nothing fancy, but it stops him falling into lava most of the time...

Player Targeting
When targeting a player, mikeBot runs at a point which orbits the player 96.0 units out, at an adjustable speed. This effectivly means mikeBot weaves toward players when they are far away and circle-strafes around them when he's close. Very hard to hit him, now :)

Projectile Avoidance
mikeBot detects whether a projectile will (potentially) hit him by checking the angle between the projectile's facing and a vector from the bot to the projectile. He also checks to see that the projectile won't hit a wall before getting to him. mikeBot then targets the closest projectile which may hit him and avoids it by moving orthogonally to the projectile's facing. He chooses either + or - along the orthogonal vector based on which direction makes him further from the projectile. By orthogonal I mean the cross product of the projectile's facing with the Z-axis.

BSP-based navigation
I am currently working on this. mikeBot makes directed graphs of the levels in the following manner: if he moves from leaf A to leaf B without going over lava, and if leaf A and B both contain "floor" polygons, then a link will be added from leaf A to leaf B. The directed graph is unweighted. I was working on (and still am) preprocessing the level completely, but this method is easier and more "natural"; makes mikeBot more human...To navigate, mikeBot finds the shortest path from his leaf the the leaf containing his target. If there is no path, he navigates as he used to and runs straight for the target. To follow the path, mikeBot goes to the center of the current leaf and to the origin associated with the link, then the center of the next leaf, then the origin of the next link, etc. untill he reaches the target leaf, at which point he can just run straight at his target (and be guarunteed of hitting it; every leaf is guarunteed to be convex).

problems: the leaves are way bigger than I originally thought; I will have to come up with a completely different method. I am thinking of linking together the floor polygons in some manner (the polygons are all convex, too). I would like to avoid a straight waypoint system since this would limit mikeBot severly; the above two methods allow him to create paths as long as there are links along the way...(if you get my meaning...)

solutions: I am going to re-do this with polygon-based navigation; mikeBot will build paths out of the floor polygons in the BSP leaves and follow them center-to-center.

Low-level reactions
I have now made some "reaction" behaviours for mikeBot: these are always active, but do not always have control of the navigation facing. Higher-precedence reactions can suppress the output of lower-level ones (the order in the list is from high to low):
Avoid Lava
This will stop mikeBot if he is about to hit lava (as detected by looking straight down 128.0 units in front of himself). He will also jump if he is over lava (effectivly makes him swim to the top or jump out on e1m8).

Avoid Wall
mikeBot has three bump-sensors; forward, left and right. The forward bump sensor is triggered if mikeBot is stopped (and wants to move) or if there is a wall within 96.0 units ahead. The left and right sensors look for walls at 45 degrees plus and minus from straight ahead at a distance of 48 units. mikeBot will turn away from walls if the front bump sensor is on. The left and right ones control which way he turns. I have also experimented with turning away from walls if the left or right sensors turn on, but this makes him get stuck in rooms with small doorways.

Random Direction
If mikeBot has not moved for at least 5.0 seconds, he will choose a random direction. This rarely happens, however.

Move Toward Target
This turns mikeBot toward his current nav target, be it a player, ammo/health, or a high-level-nav waypoint.

These reactions are always active, and help mikeBot at least roam around a little. Note that the only time he stops is for lava (at which point the front bump sensor is activated and he will turn away from the lava) so now he will roam around the level even without a nav target. Also, he can move with a small modicum of intelligence on level for which he doesn't load the BSP files (I have limited space on my account) because the front bump sensor activated when stopped.

future plans

genetic targeting codes
mikeBot will use a GA (genetic algorithm) to determine good (optimal...) targetting formulas for each item. Read the description in the nav section. I may also include support for dynamic switching of codes, based on input from various systems.

Better Projectile Avoidance
I will also add prediction to projectile avoidance and intersect the projectile-vector with a bounding box surrounding mikeBot, instead of using the dot product. He will also "intelligently" move away from the projectile, deviating from his optimal course by the minimum needed to avoid the projectile (if possible). I will also add better enemey line-of-sight avoidance. I will also probably change the way mikeBot avoids things: instead of targeting them and deterinting how best to avoid it, he will not target projectiles at all, but there will be a "path-bending" system which will be allowed to change his facing angle (by as little as possible) to avoid projectiles. I will probably also switch lava avoidance over to this, too (instead of just stopping).

sound
I will also be implementing sound interpretation, so mikeBot will be able to navigate toward interesting sounds (eg jump,grunts from players) if he has nothing better to do.

probability-based entity tracking
I plan on having a probability-of-being-there associated with every item in the level. Then, mikeBot will be able to plan paths to items he can't nessecarily see (also, for example, weapons are always present in deathmatch 2, so he can go get good weapons before engaging the enemy).

Polygon-based navigation
As mentioned above, mikeBot's BSP-leaf-based navigation was not as successful as planned...so, I will now base movement on linked floor polygons. All the polygons are convex, so navigation within one polygon can still be straight-line. Once a path of polygons has been made, mikeBot will go to the center of the current one, then the center of the line shared by the current polygon and the next polygon, and repeat until he reaches the target polygon. One big advantage of polygon- based navigation is that all the polygons can be 2D instead of 3D (once the links are made) because I can determine which polygon I'm in be first determining which leaf, then checking all the floor polygons in that leaf, at which point I can discard the Z coordinate.

Firecontrol

currently implemented
weapon selection
mikeBot selects weapons based on range of target (LG has limited range, won't use RL when too close) and current leaf type (no LG under water). He only selects weapons when he is actually targeting someone.

predictive firecontrol
mikeBot calculates where someone will be when nails and rockets will arrive, and fires there...will also adjust for lag, but that is untested.

target selection
mikeBot selects targets from the currently visible players. He rates playres based on hate / distance where hate is the amount of damage that player has done during the current level. distance is how far away they are.

wall detection
mikeBot won't shoot walls, if they block his shot

sometimes-miss
This is now implemented. Firecontrol now calculates a probability-of-hitting number as follows: if the target has more frags than the bot, probability = 100%. Else, the probability is the hate level of the target, as a percentage of the most-hated-player. The minimum hit-prob is 50%. Then, based on this probability a random error-vector of length > 32 and < 128 is added to the target's facing if a random number determines it should be added...This basically means mikeBot will sometimes miss people who have done little damage to the bot and are low on the rankings.

future plans

target selection
I plan on upgrading target selection to include player's frags and weather or not they are actually shootable. (i.e. if a wall is in the way or not)

wall detection
Currently, models besides the level itself are not taken into account (i.e. doors, platforms). Support for detecting whether a line intersects these will be added.

Other

currently implemented
Observer mode
A variable number of observers can connect to mikeBot (currently 4). The first observer has a few impulses at his disposal:
impulse 60
Toggles the status bar (present in .DEMos) on and off. Initially off.
impulse 61
Toggles target particles on/off. Initially off, this makes mikeBot emit particles from his fire and navigation targets.
impulse 62
Toggles locked view on/off. Initially on, this locks the client's view to mikeBot's view, which is the firecontrol facing if firecontrol has a target, or navigation facing otherwise.

If you see mikeBot on a server, type status in the console, and look at the IP (address) beside his name in the resulting list (ignore the trailing :portNumber). Then, type connect <the IP you just read> and you will then be able to view the carnage from mikeBot's perspective.

mikeBotLanguage Cooperation
mbl- messages are implemented and allow other (human) players to give commands and get information from mikeBot. The mikeBotLanguage spec. has the exact commands and meanings, but the coolest one is mbl-cooperate, which makes mikeBot switch colours to yours and stop targeting you (if he's not already cooperating with someone and your hate is < 500). I also plan on implementing "wingman-mode" which will allow cooperating humans tell mikeBot to follow them around, shooting like a madman (or, madbot).

random insults
mikeBot hurls random insults as follows: A number of "verbs" and "nouns" are randomly combined with a player's name. There are both good and bad verbs, which are used depending on the hatelevel of the player (negative hate results in compliments instead of insults). Now, an example:
nounverb
moron is a
dumbass looks like a
So, this example results in 4 possible insults (like -=mike=- looks like a moron.). mikeBot currently has 8 nouns and 8 verbs, yielding 64 possible insults. All insults are preceeded by mbt to distinguish them from the user talking...There are also canned phrases for when mikeBot is damaged (such as Bring it on, -=mike=-). Talking can be turned on and off and the probability adjusted.

future plans

wingman mode
For cooperating players, wingman mode will make mikeBot follow the player at a specified distance, but work the same otherwise (he will break off if in dire need of health...) and shoot other players.

full inter-bot communication
I also plan on implementing the socket portion of the mikeBot Language Specification eventually.

mike warren welcomes your
comments and suggestions

Fully-autonomous
mikeBot Now
client-side quake bot
Best experienced with
Microsoft Internet Explorer
Click here to start.
Proud member of
Bot Author's Guild
The Bot Author's Guild