Why Design FlexBot for Half-Life?
The FlexBot is a system designed to work with the first-person shooter game Half-Life for the PC. The FlexBot allows "bots," or simulated players, to participate in a multiplayer game along with humans or other bots. Half-Life is an attractive platform for these purposes for a couple of reasons: First, an open-source SDK for using the Half-Life engine has been available for some time. This means that not only is the code available for use, but there is also a moderate number of programmers world-wide who are already familiar with the SDK. Second, Valve Software built a "fake client" option built into the system that allows non-player-controlled participants in a standard multiplayer game controlled by code on the hosting computer. As far as other players are concerned, this NPC is treated exactly like another human player. As a result of this ability, a small community of bot programmers has sprung up around Half-Life and its related modifications (Mods).
Brief History of Half-Life Bots
While the Half-Life bot programming community has spawned some fairly impressive bots, there are few unique approaches to the art. Because the SDK was released by Valve with virtually no documentation, it took quite some time before anybody was able to actually make a bot. Eventually, a programmer going by the online handle "Botman" was able to develop a method of doing so. Since that time, Botman has periodically released increasingly sophisticated templates for building Half-Life bots. More recently, Botman developed a method of writing bots for MODs such as Counter-Strike. The vast majority of the bots available today are built on this template and most also use very similar approaches for everything from navigation to weapons use. These bots look, navigate, and aim essentially by following vectors within the environment (e.g. there is an enemy at this vector from the bot, so move along this vector).
The Traditional Approach To Bot Navigation
Navigation was the greatest challenge facing the early bot programmers. While many techniques were experimented with, the most successful proved to be extensive use of waypoints. Maps were "waypointed" by having human players move about the map, placing navigation waypoints every few steps in order to tell the bots where "good" places to move are. Bots were then set up to load the waypoint information and use A* searching to find the shortest path between their current location and the eventual destination. While this allows the bots to navigate with a fair degree of competence, it also leads to a high degree of predictability. A human player may take a completely different path in two separate trips to the same destination, but waypoint-following bots will always take the same path. Any attempts to vary the path inevitably lead to far less efficient search algorithms. Such bots also have trouble dealing with obstacles (such as other players) in the desired path. Waypoint navigation remains the most common navigational technique for bots today.
The FlexBot is a unique approach to bot behavior and navigation. Rather than simply manipulating vectors, the FlexBot implements a group of sensors, which obtain information about the world around the bot, and a group of actuators, which cause the bot to move or behave in general terms (e.g. turn left with speed x) rather than in specific, coordinate-based terms (e.g. move along vector [0, 342, 17]). FlexBot is also unique because, unlike other Half-Life bots, all bot behaviors are modular. While a standard bot has virtually all of its behavior characteristics built into the source code, the FlexBot does not have any behavior characteristics built in. The FlexBot release module contains all of the code to obtain information from the sensors and to make the actuators function. The actual behavior code, however resides within a separate module called a "FlexBot Behavior." A FlexBot Behavior is a DLL that accesses the sensors and drives the actuators provided by the FlexBot, thus making the bot's behavior completely modular and customizable.
A primary feature of the FlexBot is that the user can customize the bot's behavior. Since the main FlexBot module is treated like a "black box," the behavior programmer does not even need to have knowledge of the inner workings of Half-Life. Because behaviors can be loaded dynamically, many users can develop FlexBot behaviors on the same machine at the same time. There can even be many FlexBot-controlled bots in the same game at the same time with completely different behaviors. Another advantage to the FlexBot is that its design lends itself well to use with circuit-like control systems such as GRL. Programs written to control robots in GRL can be adapted to control a Half-Life bot with minimal modification.
There are several disadvantages to the FlexBot's approach to bot control. The most apparent limitation from a behavior programmer's perspective is the fact that all sensors must be explicitly defined and exported by the black box. Users do not have the freedom to write their own sensors. Any information not explicitly provided by the FlexBot is off-limits. The FlexBot's modularity can also cause a bit of a performance hit. Due to the manner in which the sensor mechanisms and the "brain" are separated, there is an extra layer of code through which the system must work. It is also important to note that if a user is employing a circuit-like approach to behavior development, system performance can be adversely affected (albeit in a consistent manner) if the user does not take care to limit expensive sensor polling (see "Technical Notes" at the end of this document for more information on this topic.) In its current form, the FlexBot does not support MODs such as Counter-Strike. This is because FlexBot was developed as a MOD itself and therefore cannot easily interact with MODs developed by other authors. Adapting the FlexBot to do so would require a significant overhaul of the underlying architecture.