UbGameDriver API

[Pierre-Marie Baty]

In order to start developing the bot, which includes

• testing the universal bot frameworks we have (PIA, etc...)
• providing a testbed for an eventual implementation of UbScript
• providing a testbed for different possible implementations of the bot itself
• do the actual coding

we need to communicate with a game engine.

We agreed to stick to HL2 at the moment, at the expense of making it as portable as possible. We also agreed that it would be wise not to touch the concept of "game driver" that we agreed on initially. But if we want to start developing the bot, we need at least to make it work in HL1 in order to test our frameworks and our ideas. That's why it's high time to define the UbGameDriver API.

This API will make the UbCore and the game engine communicate. By "game engine" we assume all that makes the game, be it the engine module BUT ALSO the game DLL itself. That means, for example, that in HL1 we will see the two sides of the interface, i.e, engine<->hook dll and hook dll<->game DLL, that is, in this example, both the g_engfuncs and the g_OtherFunctionTable functions as ONE interface.

We can either provide, as interface :

• functions only
• functions AND data

This needs to be decided.

From then on, WHICH functions and WHICH data ?

I see a few, minimal, requirements, if I look at the UB game driver from the engine's side and point of view. As the engine, I would need to provide the game driver with :

1. a way to get arbitrary code executed each frame
2. a way to get a hand on a particular entity's data
3. a way to search for a particular entity
4. a way to spawn a fake client
5. a way to CONTROL this fake client (movement, client commands)
6. a way to test visibility between 2 points in the world
7. a way to test collisions and get distances from a point to another
8. a way to hook on certain network events

Please add those you think are mandatory that you believe are missing. I don't believe I miss many, since all the rest can be "emulated" from these basic ones, meaning that any engine that features these minimal facilities could be used with the United Bot - charge to the game driver of emulating the missing "extra" facilities (at the extreme, one can say that even the fact of "playing sounds" can be emulated by tracking the players behaviours and the interaction they make with the world).

Now from the bot core, if I look at the game driver, I may see a much more complete list of facilities. These I would need to know which ones you want.

• One approach is to start with what we're familiar with, i.e: HL1. This approach would aim at creating a sort of "HL1 API emulator" in the game driver (simplifying the parts we don't care about, such as the separate interfaces between engine and game DLL). Every HL1 bot code could then be easily used as a basis for the United Bot core framework.

• Another approach would be to enumerate precisely every single facility we want, possibly getting into higher levels of abstraction than, say, the HL1 API. I would need your contribution A LOT for that.

Discussion :

[stefanhendriks]

i don't have much time, so i will try to reply as constructive as i can:

I'd say we need functions and data; but data in its simplest form. What i mean is that ie in some games the X,Y,Z (3 dimensional) system is not the same. Ie in Half-Life the dimensions are a bit different compared to Quake 3 for instance.

If you want a bot to work with multiple games, we should have a data interpreter that could 'translate' all data in one form so we can rely on that. So , my conclusion is a we need to provide data.

The same goes for entities, i'd say we have our own entity in our United Bot. It can have multiple flags and perhaps even additional variables that you can fill in later (depending on which game you use). The game driver can translate this information from the real entity data into the UB Bot entity data and the BOT driver simply reads in its own data structure. Working with this ensures we always have the same information and we don't have to care about how an entity is called in game X or Y.


Minimal requirements for a GAME driver, i agree with you PMB, and i don't have any other thoughts that should be added at the moment.

About the BOT core, i don't know yet what to say. Its huge compared to the GAME driver. I think we should have 2 seperated threads about this , one about the GAME driver (the technical side, since we already discussed things about it) and the BOT driver.

I see the BOT driver hooks into the GAME driver and has its own set of functions. I think partially they overlap, ie like "CreateBot" is done in the GAME driver.. to actually create this fakeclient and interact with the GAME itself. But on the BOT driver we have to set specific variables too (initialize BOT var, etc).

Perhaps its nice to go through all BOT specific functions you need. Hence when thinking of it, i also use a GAME class and a BOT class that are interacting with each other in the CS game. I can post a few function names here.

[Pierre-Marie Baty]

Sure.
I believe here is the place to discuss about both sides of the interface anyway. Opening another thread would not be a wise idea IMO. What you call "GAME" driver and "BOT" driver are in fact the 2 sides of the same module, the UbGameDriver.

[Pierre-Marie Baty]

*UPDATE*

Good news! I've figured out that there's one minimal requirement less.

We don't need this one:

3. a way to search for a particular entity

I have just discovered that it can be emulated. In fact we only need to be able to bind an arbitrary entity by number. The entity comparison/search routines we'll use can be all written later by ourselves.

[Pierre-Marie Baty]

*bump*

hello ?

[Killaruna]

Yep, hello :-) Don't know if this is the right place to say it, but IMHO the interface to the bot should be on a much higher level, that makes it much easier to identify the needed functions, data, etc. That means e.g. no assumptions about engine hooks, since for the bot AI, it doesn't matter how it gets its information from the game. Again as an example the PIA framework: It has its base classes that offer most of the information a bot AI might need and it has access to engine entities via the Perceipt class. Just given this minimal framework, you could write tons of sophisticated, portable bot AIs. For PIA, a game driver would be a collection of subclasses for a specific game, plus the link to the actual game itself, which would probably look similar to something like the HPB template for HL.
This approach does not use gamedriver DLLs, i.e. you have to compile the bot for each game you want to support (which shouldn't be a big problem since you have still got the source portability). But it's so much easier to define what you need and to start working on something!

[Pierre-Marie Baty]

at laaaaaaaaaaaaast one replyyyyyyyyyyyyyyy
pheeeeeeeeeew
'was wondering what the heck I could have said...

So.
You obviously second the alternate method (this one

Another approach would be to enumerate precisely every single facility we want, possibly getting into higher levels of abstraction than, say, the HL1 API. I would need your contribution A LOT for that.

If I understand you right you would want ALL the perception tasks to be the role of the "driver" ? which would provide the bot code with a "list of perceipts" - i.e, much like Parabot (read: identical to ) ?
Am I right ?

That would require then, a precise enumeration of ALL that a bot can perceive (sound, visual, tactile). This corresponds pretty much to how Parabot and the new RACC work, indeed. Do you intend to stop here or also implement the bots' means of action in the driver too ?

Anyway - this is certainly a safe point of view, but as a drawback I would say, wouldn't it be like just redoing 80% of the bot each time we need to port it to another engine ? because there's not much left in the AI once the perceipts and base actions have been taken out. You separate the "brain" from the "body", sort of...

The question is: would people prefer a highly abstracted API for coding the United Bot (providing them with the opportunity of NOT doing 80% of the perception/motion work), or would we prefer a more generic, not so bot-specific, interface, upon which any bot using the UB API could implement its OWN methods of perception and motion ?

In short:

//			 /=================================\
// ........	   ..........	  .............	  .......
// :	  :	|  :		:	  :		   :  |   :	 :
// :	  :	   :		: ---> : perceipts : ---> :	 :
// :	  :	|  :		:	  :...........:  |   :	 :
// : game : <===> : driver :						 : BOT :
// : eng. :	|  :		:	  .............  |   :	 :
// :	  :	   :		:	  :		   :	  :	 :
// :	  :	|  :		: <--- :  actions  : <--- :	 :
// :......:	   :........:	  :...........:	  :.....:
//			 |								 |
//
//			 \=================================/
//					   WE DO ALL THIS
// 
// 
// 
// 
// 
//			 /==============\
// ........	   ..........	  .............	  .......
// :	  :	|  :		:  |   :		   :	  :	 :
// :	  :	   :		: ---> : perceipts : ---> :	 :
// :	  :	|  :		:  |   :...........:	  :	 :
// : game : <===> : driver :						 : BOT :
// : eng. :	|  :		:  |   .............	  :	 :
// :	  :	   :		:	  :		   :	  :	 :
// :	  :	|  :		: <--- :  actions  : <--- :	 :
// :......:	   :........:	  :...........:	  :.....:
//			 |			  |
//
//			 \==============/
//			   OR JUST THIS

Ascii rul3z

What do the others think ?

[botmeister]

I'd say the basic game driver is all we need because with the driver in place, anyone can build an addon "plugin" which provides the remaining high level parts all the way up to a fully functional bot.

In our previous discussions, I we did go over this before, but to recap, the only standard API we need is the basic driver, and a standard method of implementing "plugins" that can communicate with each other so that the bot can be built up from a mixture of various plugins made by various bot authors.

Note: I do not mean metamod plugins - so perhaps a new term is needed for "addon" or "plugin" to avoid confusion.

Holy Technical Difficulties