Engine Independant Layer / Wrapper?
 

Although we are not ready for this yet, i suggest to start a thread about it. I have read JOE's pdf file lately and it introduces a few interesting things. However, i think it is wise to introduce a standard we all use and some code that is easy to implement.

In the days when Tub was with RB, Tub ran a project MEMM. Multi-Engine Multi-Mod compatible system. He already got bots loaded in CS, but he never worked on it again as far as i know.

Perhaps i can start with a little concept here, later on a official document and source code can be written about this. I just think it is wise to discuss this subject intensively before writing a single line of code.

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?)

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

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.

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.

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

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 ;)

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 ;)

Re: Engine Independant Layer / Wrapper?
 

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


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


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.


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.


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.


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 ?


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

Re: Engine Independant Layer / Wrapper?
 

I may be the only one that thinks developing an engine independant system isn't all its cracked up to be.

As has already been said, implementations from engine to engine vary so widely even after heavy abstraction there would be alot of changes required to use the bot in another engine.

Halflife is the only engine that supports such easy bot development, by allowing the bot to be a pass through dll basically. You want quake bots? Last I checked you either built them into the mods themselves or you're SOL if the mod authors decide not to care about bot support, which so many of them do. Unreal engine is out of the question too. Unless you become a licensee, you're not getting access to the source code. What's that leave us? Next to no engine other than halflife with this sort of ability. Engine independance is a fairy tale in my opinion, and effort should be put more towards a strong framework by several bot devs. I don't expect many if any at all future games to have halflifes level of access either.

I certainly think that a strong framework should be built for halflife bots, one that is preferably object oriented and once developed can be expanded easily to other mods with ease, and different programmers can work on different mods simultaneously.

I think lessons could be learned about the design of Unreal. Ever noticed that like 75% of the mods released for UT2003 come with bot support, while some pathetically small amount for halflife and quake come with it? That's due to the brilliant OOP design of the bots in Unreal. I think effort should be made to do something similar. Everything in Unreal Script is classes. Want a new type of sniper rifle? Derive a class from sniper rifle, overload the necessary properties and functions and you now have a new weapon. Same for bots. Got a new game type? Derive from the existing bot type, override the necessary functions to get the bot to do your gametype specific actions. It's practically a no-brainer for people and bot support to their mods.

Anyways, back on track, just wanted to give my opinion on the matter. I't sure would be cool to have a bot that is engine independant, but looking at it realistically leads me to think that you're still going to be pretty much completely restricted to halflife/halflife2 still.