[Pierre-Marie Baty]

Originally Posted by stefanhendriks

Compile/Flag switches?
Will the wrapper be coded using a 'detection system' which looks similiar to mod_id in botmans code and therefor executes the proper code? Or will it be 'compiler switched' so you only compile the code for the dll for the game you want to compile it for? (or a combination of both?)

I side with the second option (for code consistency reasons)

Layout
Seen in most games, they work all with a game.dll file. With botmans template we resulted in a engine <-> bot.dll <-> game.dll situation. Here we should ask ourselves, will this remain possible for other engines? Sure i think Quake 1/2/3 will probably get this to work. But if you want to code a bot for Unreal i think it aint this 'easy'.

True. But we don't really need to think this way. The two sides of the interface in our well-known Half-Life architecture can be seen as one. All we need is a way to get into game functions that deal BOTH rather with pure 3D and physics (the "engine") AND rather with the rules of playing (the "game"). If we get only one interface with another engine, the better ! Remember that our bots are server-side bots, and thus we don't need to worry much, if at all, with client stuff, including things such as network message catching : this was just a convenient method in HL we used to avoid cluttering the code (i.e: if I get this message it means that the state of the game changed from this to that, so let's take the appropriate action... BUT we could do that as well by polling for such a change every frame, and then all the network message code would become useless). To simplify it all to the extreme I'd say that ALL we need is a way to:
1. Spawn bots (connect a fake client)
2. Hook on video frames (StartFrame())
3. Get a hand on a minimum of engine functions (TraceLines(), what else...)

Vectors
Although i can't imagine a game using different x,y,z positions (x,z,y, like HL) there should be something you can rely on when coding. Logically there should be a vector definition somewhere in the code that gives enough functionality. Perhaps the current HL vector.h file will do.

Yes, the HL vector class is optimizable though (passing the address of the vectors only would be way faster than passing the 3 floats that make the vectors themselves into each function). But the main concern is the STANDARDIZATION. Each game will use vector distances and orientation. But NOT all games will use the same referential. For example, nothing can guarantee that in the next game the Z axis will not go down instead of going up. And nothing can guarantee that 100 vector units, which make something like 2 meters in Half-Life, won't make 350 meters in another game. We need to wrap every vector measurment too.

Entities
Here the hard part starts. Entities represent everything in the world, from players to world-switches, spawn points to goal/triggers. Question is, what do you need to know about an entity? What is really important? Only that should be in our 'own entity' structure.

This is a question we should make a separate thread for, and only for it. A thread for listing everything we think we need to know about an entity.

Wrapping
I guess this is self-explenatory, but hence: A layout for the whole picture would probably like:
+ layer identifies game (either by compiler or by detection system)
- engine sends message
+ layer recieves message
+ layer identifies message as 'take damage @ entity xyz'
+ layer wraps entity to own entity:

// HL wrapper?
void cWrapper::TakeDamage(cEntity *pEntity, edict_t *pEdict)
{
pEntity->health = pEdict->v.health;
}

etc.

I bet it will be a helluva work to wrap every single thing of a HL specific entity. When you want to make it work for another engine, you should ask yourself what should be wrapped and how long it will take to do so. Perhaps the above is not a to bright sollution, but it gives the idea.

Essential is that the bot only has access to the 'general defined' variables and not the game specific ones.

Don't trust event-based systems. You reason just like the guys at United Admins when they talk about their Titan project. They firmly believe that just hooking some game events (player death, damage, etc.) is sufficient. Not at all. We bot makers need the WHOLE information about the game, so as to be able to tell, through our abstraction layer, at some instant t, WHAT is the state of the game EXACTLY. Visually, auditively ; for each player's point of view. Including bots.

Another point of view
Someone once told me he wanted to code a bot which ran as a seperated EXE file and just logs in like a real player does. It gets connected, although on a LAN server this would be a loopback he was confident he could get it to work. I still have contact with him, but he did not tell me how progress went. The idea however is quite ambitous imo. It would be cool if you just could ran the program and let it connect to any internet game and let it battle for you when you are away

This is a 100% client-side bot. The danger and difficulty of client-side bots is that it can not, by essence, be game-unspecific. Because you have to emulate 100% of the code that runs on the client for use by the bot. In HL for example, you'd have to build a whole sort of hacked client.dll inside your bot code, because the bot does not run on the server, it doesn't have access to any of the server data, entities, stuff : all it knows is the IMAGE of the game that runs on the server, that the servers TELLS IT ABOUT, through its network messages. Realize that ONLY the server has the real game, all the clients have is a very incomplete and inaccurate image of it, and every client has a different one ; because the clients only know of the game by the messages the server sends them, and only them, not any other client else. Do you still really want to make client-side bots ?

Anyway, with this thread i hope to give a start at this subject and to get some things rolling. Before everybody starts to code their own implementations and we all end up inventing the wheel 4 times in a row

It's a good thing to start talking about it, at least