.:: Bots United ::. - United Bot philosophy and roadmap

.:: Bots United ::. (http://forums.bots-united.com/index.php)

- United Bot (http://forums.bots-united.com/forumdisplay.php?f=46)

- - United Bot philosophy and roadmap (http://forums.bots-united.com/showthread.php?t=1298)

Re: United Bot philosophy and roadmap.

I'm interested in helping out, I have lots of free time which I use to develop metamod plugins or other half-life related stuff.

Known languages ( complete ): C, C++, C# and I'm learning 6502 assembly now ( Though that has nothing to do with anything ).

Re: United Bot philosophy and roadmap.

First things first, before even pointing a finger on a first milestone, we need to get organized.

The people committed in the United Bot are listed here :

http://server.bots-united.com/wiki/i...ommittedPeople

We welcome Lazy in the crew.
Feel free to comment over this list.

Do you think it's enough for a first prototype ? If so, it'll be time to dispatch the tasks.

Re: United Bot philosophy and roadmap.

"Do you think it's enough for a first prototype ?"

I assume you mean prototype of what types of modules there will be. There doesn't seem to be any actual content in any of the wiki pages (like diagrams showing how the modules are intended to fit together, etc.)

Can someone put up the proposed "bot core" code showing how you plan to manage multiple bots in the game and what types of functions will be called for each one? Something like this (in pseudocode)...

Code:

for (AllBotsCurrentlyInTheGame)

{

   Call PreThink();  // do any pre-thinking processing here

 

   Call Navigation();  // do we need to find a path or set up movement (this includes turning/jumping/ducking/etc.)

 

   Call ItemUsage();  // do we need to press any buttons or use any world items?

 

   Call EnemySelection();  // are there any enemies nearby?

 

   Call WeaponSelection();  // should we choose a new weapon for the current enemy?

 

   Call AdjustAiming();  // do we need to adjust our aim?

 

   if (bButtonsPressed)  // does the bot need to press any buttons to simulate player input?

          Call PressButtons();

 

   if (bMovementRequired)  // does the bot need to send movement information to the engine?

          Call SendMovementInfo();

 

   Call PostThink();  // do any post-thinking processing here

}

Obviously other stuff would need to be added, but let's at least start with some kind of "core" framework that can be discussed in more detail.

botman

Re: United Bot philosophy and roadmap.

so i was thinking about the name of the bot last night.
United bot
~appropriate since its named after the forum
Universal bot
~better describes the function of the bot in the name

My suggestion
shorten the name to "UNI-BOT"

Re: United Bot philosophy and roadmap.

sounds cool this stuff. So in fact to demonstrate this is working. We need a project with the simply API of the bot. And then we need a project which does the translation from HL to this bot. Very commented code so other coders can make an own 'translator'.

I think a sort of 'metamod' approach would be nice.

Re: United Bot philosophy and roadmap.

"And then we need a project which does the translation from HL to this bot."

But don't think only in terms of Half-Life. The prototype should work on Half-Life, UT2k3/k4, BF1942, and Quake III as a minimum.

Think in generic terms instead of in Half-Life engine terms.

botman

Re: United Bot philosophy and roadmap.

By the way, botman, would you for a chance have heard of / do you know some basic bot templates for these engines available somewhere to download ? (even extremely basic)

I assume you must know something about this at least for Unreal with your knowledge of the Unreal engine...

Re: United Bot philosophy and roadmap.

should i post botmans posted code above to the UB Drafts in tha wiki?

Re: United Bot philosophy and roadmap.

This would be the appropriate place ;).

Re: United Bot philosophy and roadmap.

Here's some diagrams to get the ball rolling ...

Preliminary Diagrams showing the interface components

GE = Game Engine
GED = Game Engine Driver (custom made for each GE interface)
UBE = United Bot Engine
P = Plugin (supplies a bot component or related service)

Code:

 

|GE-1| <-> |GED-1| <-> |UBE| <-> [P-1, P-2 ... P-m]

|GE-2| <-> |GED-2| <-> |

 

:

 

|GE-n| <-> |GED n| <-> |

Code:

 

|P-1| <-> |P-API <-> UBE <-> GED-API| <-> [GED] <-> [GE]

|P-2| <-> |

 

:

 

|P-m| <-> |

Here are my rambling thoughts for discussion ...

The UB Engine should only provide a standard set of basic services which allow a bot to be constructed out of various "plugins".

Plugins provide the high level functions, such as combat behaviour and navigation.

Each plugin will use the services provided through the standard P-API (plugin API).

Plugins may communicate with each other, but only through the P-API.

The UBE may communicate with GED's but only through the standard GED-API (Game Engine Driver API).

For maximum flexibility we can allow plugins to directly call GED functions. This way certain game specific functions can be made available that otherwise would not be availble through the UB Engine API. Of course, using non standard function calls leads to driver dependant code which is not 100% portable to other game engines.

Plugins and GED's can replace some of the UBE functions with alternate versions providing "virtual function" capabilities.

Plugins and GED's can also "hook" or "chain" onto some of the UBE functions.

Some of the UBE services will provide status information about each bot, as well as the game environment.

Other UBE services will have to be defined.

The UBE may issue event messages to plugins as a means to trigger events, such as "round start", "team selection", etc.

A sticky problem to solve will be in how to share data between the UBE and the plugins. We don't want a duplication of effort across plugins, for example where each plugin keeps its own duplicate list of bots and associated data.

If data structures are to be shared across plugins, then how is this done? There's more than one way to do this, but some methods are more suitable than others.

How do plugins communicate with each other? Message passing is usually a good method of communications. Messages can be used as event triggers which simplifies the need for constant polling (only the message queue needs to be polled in a generic way).

Function "hooks" can work well as event triggers.

Changes to messages can be made without modifying API's.

more discussion ...