That suggestion was raised by botmeister and a couple others. The idea is to build a bot AI template, that would be cross-game, and cross-platform.
- Cross-platform: the bot must be integrable to a broad set of game engines. Examples include Half-Life, Half-Life 2, Battlefield 1942, Quake III, Unreal, and others. An API must be defined as the input to the core center of the AI template, to which a "game driver" will be able to talk, translating back and forth the engine calls from the game engine to the AI template and back. Not two game engine behave in the same way, and not many of them provide as much facilities as the Half-Life engine does. Defining the core AI template API and its needs for supporting a particular game engine is part of the United Bot project plan.
- Cross-game: the bot must be easily integrable with different modifications of the original game available on a certain platform. The most known example is Half-Life and the diversity of its mods. Given a set of configuration files (preferred), or at worse, minor code changes, the end user will be able to have his bots either capture a flag in CTF mods, hunt for a prey in others, work in squads in another one, make a certain action upon a certain entity in order to win the round in some other one (e.g, "plant" a "bomb" like in Counter-Strike) ; this assumes that all possible behaviour for First-Person Shooters environments are already integrated and working in the core AI part of the template. Defining the list of featurable behaviours and their configuration needs is also part of the United Bot project plan.
- Template: the bot must feature a core AI center and a great number of APIs into which third party bot makers could insert plugins. Example: you are not satisfied of the aiming of this bot, download the aiming plugin made by Mr. X and plug in into your bot. You want your bots to be more stealthy and take always the safest routes, download the pathfinding plugin made by Mr. Y and plug in into the bot. You are not satisfied with the weapon usage of the bots, download a plugin that will make the bots use the burst-fire better. Defining the list of possible plugins and their respective API is also part of the United Bot project plan.
We need to evaluate and examine a roadmap for each of these three points.
1. Cross-platform Core AI.
1.1 - To define the needs in terms of game engine integration for the United Bot to support a game engine or not.
In our opinion, at least:
. - To have the ability to hook on each video frame and execute arbitrary code.
. - To have the ability to read, interpret and process the game data, either through engine facilities, or directly from the game files on the disk, translated by our means.
. - To have the ability to parse, bind and retrieve data from the game's list of "entities", "things", "moving objects", "elements". Notably their position, velocity, size and mesh (model reference).
. - To have the ability query the engine for testing visibility from point A to point B in the virtual world.
. - More (open to discussion).
1.2 - To define a game driver API.
. - To elaborate the prototypes for each "virtual" engine call.
. - To write wrapper functions that will dispatch these calls into more CPU-efficient engine calls for engines that provide the more facilities, and
. - To write wrapper functions that will emulate the missing calls for the engines that provide the less facilities, given a minimal set of availability.
2. Cross-game FPS AI
2.1 - To define the interfacing differences between games and to solve them. To define the needs for each mod in terms of interoperability between at least:
. - Network messages (if the game engine features it)
. - Round start event (if the mod features it)
. - Goal entities (if appliable) or situations (idem)
2.2 - To define and implement in the driver API the virtual facilities used in this process:
. - To distinguish a player's team by ID (forethink of an alliance system)
. - To distinguish a player's class (abstract this data so as to make it portable)
. - To locate and query the state of a goal entity or situation.
.
Abstraction is the key word.
2.3 - To define and implement an abstraction method for the weapon data. Which weapon does light damage, which one has a radius effect, which one is tossable, which one is missile, which one is instant hit, which one is a disabler (flashbang/freezer/whatever), etc. Taking the example of the RACC AI weapons abstraction layer:
. - To forethink for each weapon the number of rails (ex: primary rail = sub-machinegun, secondary rail = grenade launcher)
. - To forethink for each weapon a class (ex: grenade, primary, secondary or melee weapon)
. - To forethink for each weapon a set of properties: (ex: waterproof, disabling effect, radius effect, missile, heavy/medium/light damage, automatic firing capability, buckshot firing capability, scoped, zoomed, silenced, homing, toss effect, needs placement).
. - To forethink for each weapon a best effect distance range that will be useful to the AI. Debatable point: let the/a "weapon usage" plugin decide of this instead.
2.4 - To define and implement a configuration file syntax for all this (XML or .ini file).
. - To separate the configurable data into several databases,
. - To define a syntax for each configuration file,
. - To implement a parser for each file.
3. Template.
3.1 - To define the list of plugins that will be featured in the United Bot, and their API. This will be a static list. It can't be otherwise. The question is to determine what part is "pluginnable" and what other is not.
. - Aiming algorithm,
. - Pathfinding algorithm,
. - Obstacle avoidance,
. - General combat behaviour,
. - Weapon usage,
. - Squad manoeuvers behaviour,
. - More to be proposed.
3.2 - To define an API for each.
. - The aiming algorithm relies on at least 3 data: the ideal angles (the angles the bot is moving its crosshair to), the current view angle, and the crosshair movement speed within the current frame time.
. - The pathfinding algorithm relies on a more complicated set of data; must be included the danger of each waypoint/navmesh face/node on a per-bot basis, the reachability of each link to be matched with the bot's movement capabilities, the path timing, etc. A fixed pathfinding algorithm must be imposed: I suggest A*. Then, the API can be constrained to an heuristic function and a cost function, given the availiability of enough data.
. - The obstacle avoidance must at least make available an engine visibility test facility (TraceLine) and also the velocity of the bot, as well as its movement input keys.
. - The weapon usage part must make available the whole weapon database, as well as the bot's current ammunition and equipment.
. - All of them must make available a standard set of tools to be defined, such as the server time, the bot position, angles, speed, forward/right/top direction (3D orthonormal referential). More to be added on request.
End of the project plan/roadmap.
Gentlemen, discussion: