View Single Post
Re: United Bot philosophy and roadmap.
Old
  (#21)
Pierre-Marie Baty
Roi de France
 
Pierre-Marie Baty's Avatar
 
Status: Offline
Posts: 5,049
Join Date: Nov 2003
Location: 46°43'60N 0°43'0W 0.187A
Default Re: United Bot philosophy and roadmap. - 25-03-2004

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:
Code:
// 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
Quote:
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 -



RACC home - Bots-United: beer, babies & bots (especially the latter)
"Learn to think by yourself, else others will do it for you."

Last edited by Pierre-Marie Baty; 25-03-2004 at 11:42..
  
Reply With Quote