United Bot philosophy and roadmap

[Pierre-Marie Baty]

holy shit botmeister, you're setting us up a monster! o_O

I believe we should start MUCH simpler, for a start. Keep your scheme in mind as it will certainly be implemented later (although I'm not fond of some of the features you proposed, such as having plugins call directly engine specific functions, or hook over UBE functions. I believe the safest way is always to pass only DATA back and forth)

Even botman's code is above the minimal simplicity... I'd have thought rather of something like:

// main loop
for all bots in game
{
	// plugin calls in each of these
	UBE_BotSense (Bot)
	UBE_BotThink (Bot)
	UBE_BotAct (Bot)
}
 
// sensing part (PreThink)
UBE_BotSense()
{
if (VisionPlugin.is_plugged)
	 (*VisionPlugin.BotSee) (Bot);
else
	 UBE_BotSee(Bot); // fallback, default algo
 
if (HearingPlugin.is_plugged)
	 (*HearingPlugin.BotHear) (Bot)
else
	 UBE_BotHear(Bot); // fallback
 
if (ObstacledetectionPlugin.is_plugged)
	 (*ObstacleDetectionPlugin.BotSenseObstacles) (Bot)
else
	 UBE_BotSenseObstacles(Bot); // fallback
}
 
 
// thinking part (Think)
UBE_BotThink()
{
if (TeamworkPlugin.is_plugged)
	 (*TeamworkPlugin.BotProcessTeamIntentions) (Bot);
else
	 UBE_BotProcessTeamIntentions(Bot); // fallback, default algo
 
if (StrategyPlugin.is_plugged)
	 (*StrategyPlugin.BotSelectGoal) (Bot)
else
	 UBE_BotSelectGoal(Bot); // fallback
 
etc.
}
 
 
// Motile part (PostThink)
UBE_BotAct()
{
// same layout as the others:
// - press movement keys + weapon usage keys
// - move crosshair
// - send audio and text chat / communications
}

The UBE does not have to wonder about the quality of such or such plugin, I believe it must trust them blindly. Since the P-APIs will be fixed for each plugin, and since there will be a data standard for each, as long as the plugin is plugged, just call it. Else, fall back on a dumb algo, just to prove the concept works, HPB_template style

Hence I don't quite agree with your drawing of the P-API, botmeister, to me it's rather like

GE <-(arbitrary API)-> GD <-(GD-API)-> UBE <-(PluginX-API)->Plugin X
______________________________________<-(PluginY-API)->Plugin Y
______________________________________<-(PluginZ-API)->Plugin Z

(consider the _'s are spaces, this stupid forum software eats them otherwise)

The only API that will be unique and fixed, is the GD-API that will allow the United Bot core to talk to the game driver.
Since what is "pluginnable" is known (or at least to be defined, but that's the point), there is one P-API for each category of plugins. One API for all the aiming plugins, one other API for the obstacle detection plugins, one other API for the weapon handling, etc. These are not the same APIs.

Since we can't put together an unlimited amount of plugins, I believe it would be a waste of time and an useless expense in complication to unify these APIs into a generic one.

more discussion -

[stefanhendriks]

holy sh*t, its a lot of reading when ur offline for a long time.

Okay. This sort of thing (a game-independant bot) was already 'thought over' by Tub, and he sort of explained his concept to me. he HAD a working version btw. Simplw alking bot. using a 'layer' between the BOT and the GAME dll.

So simply said, probably said already:

game.dll (any game)
translation/layer.dll
bot.dll

the translation dll should provide information to the bot dll so the bot dll can blindy rely on this information and act.

so in short:

translation dll converts data into workable (for bot dll) information (and backwards).

I also think we need a 'seperated entity list'. The translation dll should make sure that all usable entities are generalized so the bot dll can work with them. E.g simple said you can have entities called 'door', 'window' 'breakable', 'goal'.

More concrete example would be to translate vectors. Some games use different vector formats (e.g. x, y,z or y,x,z).

There are a lot of things to think about.

I'd say begin with the general concept , i think we all pretty much agreed on a sort of translation dll and a bot dll.

I think PMB's example is already to in-depth. its more about the bot.dll layout and that does not matter much at this point (at least not that in-depth). I sort of suggest:

translation.dll

function hook_into_game()
{
 // does all hooking, and retrieves information
}
 
function frame_handler()
{
 // called by the game , then passes this to the bot dll
}
 
function vector(x,y,z)
{
 // passes through the vector information if needed
}
 
function look@vector( vector )
{
 // makes entity look at vector
}

bot.dll

void main()
{
 loop through all bots
  - retrieve status of bots
  - run plugins (movement, combat, etc)
  - send output to translation dll
}

Perhaps it is a bit vague, the bottom line is you have a simple IO system. Bot dll gets INPUT , changes things (according to plugins), sends OUTPUT and translation dll makes sure the bot 'does what it does'.

I think a simple command 'struct' will fit the job:

entity info / script:
 - current vector
 - current facing
 - current health
 - bit flag (buttons)
 - bit flag (ground/air/water/etc)

most info is used for handling information, however, when sending information back you just change the vector for moving/facing.

Somehow i got the feeling this post became one spaghetty bs. Gotta run for class now.

[Terran]

How about this:
Instead of having only one plugin for a function at the same time we could support multiple plugins of one kind at the same time. This could be use to create bot personalities not only by parameter but also by different plugins. The actual bots would read some kind of configuration for their personality and use the plugins defined there or use random plugins (this selection process could be a plugin too). If no special plugin is defined for some funcions, use the globally defined plugin and if there is no globally defined plugin use the default/buildin functions.

[@$3.1415rin]

about botman's enemy selection / weapon selection / whatever stuff : I think it's not ok to have those stuff seperated like this. maybe we should go a similar direction like parabot does with it's goalfinder ( or joebot xp ), to avoid contradictory actions by different plugin. the goalfinder system of parabot and the joebot xp system which is very similar( http://www.lampel.net/johannes/joebo...XPDoc-beta.pdf ) are working nice, although it should still be extended, as anything we are working on but it produces resonable results and even a hirachial task system shouldnt be very difficult to implement here.

and as PMB said, keep things as simple as possible. and already think about dual use data, that's simplifying a lot of things ... like general data about entities and their specifications in a game, like zones in cs are not drawable, but perceptable and stuff.

back to reality, gotta go visit my grandma in hospital now

[botman]

"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'm not aware of any 3rd party bots for Unreal or Quake III since both of these games come with bots included. I'm thinking that since the developer of these games included bots with them that very few people would have the desire to create their own bots for those games.

Also, a comment about entities in the game. I don't think it's a good idea to try to abstract the game engine data (entities, the data structures for the world geometry, etc) since every engine will handle these differently. There should be no need for the bot core code to know anything about what's in the world. The core code should only be concerned with calling a predefined set of functions that are geared toward getting the bot to do a specific task ("see things", "hear things", "select a weapon", "fire a weapon", etc.). Each individual bot function should have the engine specific knowledge about how to get things from the world and how to interpret those things. This obviously means that all of these functions are going to be engine specific.

If you try to generalize things too much up front, you will quickly find that there's lots of special cases for each engine that don't fit the generalization model that you've chosen. Also, MODs for each engine will have there own brand new, unexpected types of entities that can't have been planned for in the generalized design.

There's nothing wrong with having engine specific code in each of the bots functions. There can still be generic code that all the bots use to handle common tasks (such as an A* path finding function, some function that generates a navigation mesh based on a list of polygon vertices, a function that provides realistic human-like weapon aiming, etc.). But none of the generic code should make ANY assumptions about things that are engine specific (such as what entities there are in the world, how a weapon fires its ammo, whether a bot has the ability to fly or not, etc.)

botman

[Onno Kreuzinger]

Hi,
i just wanted to "anounce" that i'm with you, i.e. im willing to support you in any way, i.e. tailor a common development enviroment, operating cvs & bugzilla, build testing, release packaging and the nasty QA stuff ;-)

cheers

[botmeister]

@PMB

If I understand what your are saying, you are proposing that there is no function calling API betwen the plugin and the UB Engine, instead there's only data structures which the plugin can interface on to. I assume this means that in your view the the UB engine will abstract the game world into something standardized for the bots to interface onto. Is my assumption correct?

@Everyone else

I agree we *have* to start off with something *very* simple, however we should at least have something for a "big picture" in mind before we go off writing reams of demonstration code.

I think I can see already 3 different perspectives on how a UB should proceed. Let's experiment with these ideas a bit more so we can settle on some kind of consensus.

I think we'll soon have to get organised with a development team structure, although throwing around our respective ideas is fine for now.

[stefanhendriks]

agreed. So how do we get started?

[botman]

I've been doing some research into adding a non-UnrealScript bot in UT2k3/2k4 and it doesn't look like there's any way to use C++ code with an Unreal MOD. You used to be able to do this with the old Unreal Tournament, but UT2k3 doesn't have the .h header files necessary to create your own DLL files from compiled C++ code.

Any bot code created for UT2k3/2k4 will HAVE to be written in UnrealScript (which limits you to what types of world geometry you have access to) and UnrealScript is about 20 times slower than compiled C++ code.

I was going to investigate how much was possible with Quake III as far as replacing the bot code with your own code, but I can't seem to find my copy of Quake III Arena (I can download the Q3 demo, but the demo doesn't allow MODding). I did a Google search for alternative Q3 bots and didn't find anything except discussions on ai-depot.com about someone trying to find an open source Quake III bot (which there was none). It's been a while (5+ years) since I did anything with Quake, but I do remember that all Quake II MODs had to be written in Quake C. I know that with Quake III, DLL file support was added, but I'm not sure if MOD makers would create their own DLLs or if they were still limited to Quake C for their MOD source code.

Knowing these limitations, it will be next to impossible to create a bot with any amount of shared code that will work in Half-Life, UT2k3, and Quake III.

botman

[Pierre-Marie Baty]

@botmeister: yes, completely. I agree it's a lot of work, but IMO that's the way to go to achieve the maximum independency.

@botman: can we at least make external code communicate with QuakeC code or UnrealScript ? If a simple translation layer is still doable, perhaps that's just what's needed ?