[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.