The AI tree works quite good. Using the
nodes to initialize variables and the leaves to give the bot the ability
to perform certain actions is working well. However it is not always possible,
to fully separate the procedure for the action and the conditions for changes
to other leaves. Some leaf change conditions have to be verified before
the action of the leaf is performed. This can result in the bot changing
from one leaf to another without doing anything.
The current tree used by the Omicron bot
could easily be extended with several other leaves. For instance a leaf
for defending an area could be added. Or a leaf to "camp" near an item.
(Waiting near an item until it respawns is often called "camping" in Quake.)
It's quite difficult to create a set of
balanced fuzzy logic functions. The fuzzy logic functions should give the
best result in every situation and that's quite hard to achieve. The set
of fuzzy logic functions used by the Omicron bot works satisfactory but
definitely isn't the best set. With the help of some Quake experts these
functions could probably be optimized.
Waypoints
Storing additional information about the environment in waypoints (point in space) is not such a good idea when the environment changes. For instance when there is an 'item' waypoint near an item that moves. The waypoint is placed near the item in one position. Later the item has moved and it could occur that the 'item' waypoint isn't even close to the item.
Waypoint placement
When the bot explores the environment and walks around a corner, a waypoint will be dropped. This waypoint will be dropped as soon as the bot isn't reachable from the last dropped waypoint. This is when the bot just goes around the corner. The new waypoint will be dropped at the previous position of the bot. When this previous position isn't far enough back the reachability between the last waypoint from which the bot was reachable and the newly dropped waypoint is doubtful. Assume the reachability between the two waypoints is still intact. A next time when the bot follows the waypoints to get around the corner the reachability is determined between the bot and the waypoint. In this case the waypoint around the corner might not be reachable. The end result is that the bot has a difficult time to get around a corner.
Routing
The routing algorithm uses a sequence with
waypoints. In the algorithm the waypoints are simply added to the end of
the sequence. The algorithm could also use a sequence sorted from front
to the end on distance towards the goal from shortest to longest. When
the sequence is sorted the worst case time complexity of this algorithm
will be better. However the sorting consumes time as well. To sort quite
efficient a bubble sort could be used. When a waypoint was normally written
to the end of the sequence the bubble sort is used starting at the end
of the sequence going to the front. The bubble sort adds the waypoint at
the right spot in the sequence. It is also possible to use a binary sort.
A binary search is used to find the right spot to add a waypoint in the
sequence. When the sequence is sorted on distance towards the goal the
algorithm has become a breath first one on the actual distance from the
goal instead of breath first on the number of waypoints.
A sorted sequence isn't used for the Omicron
bot because the current algorithm works satisfactory already. The bot operates
in a realistic 3D environment and the waypoints are placed in a efficient
manner. Because of this, most of the distances along reachability links
are more or less equal. This is why breath first on the number of waypoints
becomes pretty much equal to breath first on the distance from the goal.
The current algorithm doesn't spend time on sorting and in the average
case it is faster than the algorithm that does sort the sequence.
Visibility
The algorithm used for visibility only traces one line with a point. In reality there are many more light rays to verify. The algorithm also doesn't take the presence of light into account, which is obviously not correct.
Reachability
Because the algorithm only traces lines with points instead of larger objects like boxes it can still recognize entities as reachable which actually aren't. For instance the bot might mark an entity as reachable which is located behind bars. A line is traced with a point between two bars by the algorithm but a player is too large to get through. Because only lines can be traced with points in QuakeC there probably isn't a solution without making the algorithm too slow.
Hearing entities
The geometry of the environment isn't taken into account, when the volume of a sound is calculated. This is obviously not correct but in QuakeC there's no solution without losing too much cpu power.
Moving
If the bot finds a non walkable area ahead, when moving towards a nearby goal or in a specific direction, the bot tries to jump over it. Assume the bot has a goal in a trench. The bot will look at the trench as a non walkable area, because it can't walk over it and can't get out of the trench. The bot will try to jump towards the goal. The goal of the bot is actually situated in the trench and as a result the bot will jump into the trench. In this case the bot is jumping down when it could just as well walk off the ledge of the trench. This isn't really a problem, except when trench is rather small. Then the bot has a hard time moving towards the goal, because it's quite difficult to jump exactly into the trench.