United Bot philosophy and roadmap

[Pierre-Marie Baty]

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:

[botman]

This has been discussed before, but little or no work was actually made publicly available. I think part of the reason behind the "failure" of early attempts was that, if nothing is ever released, everyone will lose interest.

I suggest that, as a group, you spend only a small amount of time designing what the template should be then, spend a little bit of time building an EXTREMELY simple prototype and release it to the public (with the understanding that it will constantly be improved upon).

That was basically what I did with the HPB bot when it first came out. The first HPB bot couldn't shoot, couldn't navigate around intelligently, couldn't handle specific jobs (like planting a bomb, capturing a flag, etc). But the important thing was that it was AVAILABLE for anyone to download and begin working with (even when there were problems getting bots to spawn properly in Counter-Strike, which was fixed by DaTa from the old Android bot).

So my suggestion is, don't spend 3 or 4 months designing something and then spend another 6 months trying to have a completely finished and fully functioning bot, because everyone (including the developers) will lose interest in it before it is available to the pubilc. Do something simple just to prove the concept and then keep constanly making improvements.

I have quite a bit of knowledge in the Unreal world now and would be a good resource for providing information and code in the Unreal engine (perhaps I would take on the task of "Lead Unreal Developer").

More disussion...

[botmeister]

I wrote most of this late last night, and some of it will add to what botman has already said above ...

The UB project can be made into something that is very complex, and complex tasks tend to take a long time to complete. If the time to complete is too lengthy, then there will be a lot of developer turnover, which will delay things even more, and the project may drag on for years. A long development cycle should be avoided right from the start.

How we are organized is of great importance. Those of us who have worked on software teams before will know what to expect, so let's deal with the inevitable challenges right from the start.

The development team must be able to make difficult design choices quickly, therefore we'll need a "Project Leader" to help facilitate the decision making. I suggest that we look at the how Bots United is structured for some ideas on how to structure the development team, or at least get the ball rolling.

The bot template concept with plugins was proposed for some very important reasons that everyone should understand:

The bot must be very flexible and allow multiple developers to add their own ideas on to it without much restriction or tight collaboration.

We do not have to actually build a fully functional bot, we only have to build the template, and this will save us a significant amount of time. It is the template that will allow developers to add their own plugin functionality without having to build an entire bot from scratch.

The template should keep things as simple as possible by only providing services that the various plugins and "game engine drivers" connect to. The template should not be a functioning bot by itself. It becomes functional as a bot only after a suitable collection of plugins are assembled together.

Getting to the point where plugins can be added will be the first major achievement. I suspect that we will want to add a few demonstration plugins to get the plugin devlopment ball rolling. The UB template will automatically help facilitate collaboration across plugin developers because it provides a consistent standard to work with. For the first time, we'll see developers working on building a common bot, but at the same time not actually working on the exact same bot! We'll also see for the first time users gathering up the right mix of plugins to make their own "flavor" of a bot, and perhaps people will be encouraged enough to learn C++ and tinker with modifying plugins to suit their individual needs better.

I propose we break the project down into "phases". Each phase should be completed relatively quickly before moving on to the next phase. We won't always know what is needed, but this is expected because a lot of the effort is R&D and we'll be breaking new ground, so we'll be learning and changing our ideas as the work progresses. There will be multiple "phases" of completion which taken together mayl span several months or more, but no individual phase should span more than 3 months or less if possible.

We define what "completed" means for each phase, so that a realistic time frame can be chosen and we will know what the final result is expected to be. For example, the completion of "phase one" will mean far less than having a fully functional bot template that actually works with 20 different game engines. Perhaps all it will do is provide a crude demonstration version of the plugin capability and engine interface.

This project will have to evolve over multiple stages.

I'd also like to point out the UB project will probably differ significantly from the UA Titan project. One difference that comes to mind is that a bot must function in real time without bogging down the game play. An administrative mod is not normally cpu intensive, and the design choices made will reflect this luxury. For the UB, we'll have to pay a great deal of attention to keeping down the CPU usage and making sure that adding multiple plugins does not slow down the game play too much. Ultimately of course it will be the responsibility of the plugin devloper to make sure their plugin does not kill things, however the template interface should be built in a way that helps plugin developers build good plugins that don't bog things down. We can do all sorts of things, including diagnostic tools which identify which plugins are causing bottlenecks or other problems, etc.

[Pierre-Marie Baty]

Very good. And botman has a very good point too.

I agree completely with him and I agree not to spend much time to planify things to the detail. And as botmeister says too, we need short milestones.

First off, WHO IS INTERESTED ? (outloud)

Then, once a core team is made, dispatch the responsibilities.

Then, assign a first milestone (e.g, have a bot to spawn in HL and Unreal using the same API),

and finally, switch the nerd mode on and CODE.

I think we can count botmeister, botman and myself in the project already.

Stefan was saying the other day that he'd like to join too, but I'd like him to come and apply himself. I think we can count on Aspirin too, but same thing. (ot: why not start writing drafts in the wiki ?)

Who else ?

[dead bwoy]

Is there any way someone like myself could observe the development process? I know I could keep up with the progress in the forum or wiki, but I'm interested in learning to code (C++). So is there any way I could just check out the files? like cvs on sourceforge? then, once I get a feel for the process, I can start contributing.
OR, if you guys don't mind dealing with a noob, can I be an apprentice on this project? ...

[Lazy]

Just dropping off an idea...

I think you should implement a small scripting into this. In addition to allowing plugin dlls, let people create and use plugins in a safe and easy to learn language (maybe basic like?).

This way, you get more people and ideas making good plugins using the easy language and C, C++ developers get to keep the power of their languages.

Just an idea though since virtual machines do take up a bit more work than native code, or maybe just compile into native code to begin with?

Just a thought, unless I completely mis-understood what you were saying.

[botmeister]

Originally Posted by dead bwoy

Is there any way someone like myself could observe the development process? I know I could keep up with the progress in the forum or wiki, but I'm interested in learning to code (C++). So is there any way I could just check out the files? like cvs on sourceforge? then, once I get a feel for the process, I can start contributing.
OR, if you guys don't mind dealing with a noob, can I be an apprentice on this project? ...

Some of the development process may be made public, perhaps all of it. We'll have to first wait and see what development process is decided on.

Not all the challenges will be C++ coding issues, a lot will have to do with software design issues which are program language independant. Usefull input can therefore come from people do not have any C++ knowlege, but I expect you will have to have a deep understanding of programming concepts in general.

As for being an "apprentice" you'd have to find people willing to do such a thing. Many of us are already bogged down at work during the day, and there's never enough hours at night to work on all the fun projects we'd like to be working on - some of us are going to bed at 2:00 am ... for some reason PMB comes to mind

[botmeister]

Originally Posted by Lazy

Just dropping off an idea...

I think you should implement a small scripting into this. In addition to allowing plugin dlls, let people create and use plugins in a safe and easy to learn language (maybe basic like?).

This way, you get more people and ideas making good plugins using the easy language and C, C++ developers get to keep the power of their languages.

Just an idea though since virtual machines do take up a bit more work than native code, or maybe just compile into native code to begin with?

Just a thought, unless I completely mis-understood what you were saying.

I'm sure scripting of some form will be talked about once we start defining what the UB will do and how it will be structured. At the very least a scripting component could be made available through one of the plugins, or through a plugin-like module.

[dead bwoy]

I spend an average of 3-4 hours a day, either playing the game, or messing about with server plugins. If you do make the source "browseable," (non-editable) I think it would be a good idea to see a well commented (or remarked) source, telling the "browser" what certain portions of the code actually do. That way anyone who wants to can learn can read about how. I basically want to learn how to code plugins for mods, for CS16 AND CZ. I can't wait to check out CZ! I like lazy's idea too, about an "easy" language for people who don't feel like trying to tackle c++ to write a plug-in. Just my thoughts...
===========================================

I am willing to do beta testing for WIN32, CS16 STEAM / DOD / CZ!!! (if needed)

[Terran]

I agree with the assumption that people could be easier attracted to this project if they have some "toys" to play with. Some may have good ideas for parts of a bot but are afraid of other parts, e.g. the navigation. Through this proposed plugin system they could concentrate on their part and don't have to worry about other parts. In the end this should result in a larger development community.

Possible first goals:

• spawn a bot with the same API in more then one game engine (as PMB suggested)
• concentrate on ONE game engine and start with the design of some of the plugin interfaces, e.g. for an aiming plugin.

I should start to derust my C++, havn't used it much in the past years...