View Single Post
Re: fakeclientless bots
Old
  (#23)
DrEvil
Member
 
DrEvil's Avatar
 
Status: Offline
Posts: 142
Join Date: Jan 2004
Location: Los Angeles, CA
Default Re: fakeclientless bots - 09-08-2006

My bot is essentially what United bot was/is supposed to be. I was excited at the prospects of united bot when it began its conceptual phases so long ago, and when I got done with classes and wanted a project to work on it was clear that United bot wasn't really getting anywhere. By no means is this meant to be disrespectful to the BU team, but there has been all kinds of talk about UB, and very little actual progress toward its realization. For that reason I started my own game/mod independant bot.

Started with ETF, which is a Team Fortress mod for Enemy Territory, then ET, which is same engine different mod. And have since moved to support Quake4, HL2M(as much as possible given server plugin limitations), and currently working on the bots for Fortress Forever. Omni-bot has been in constant evolutionary change, as I discover better ways to do stuff and refactor systems as needed. It's not perfect by any means, but it is a mod/bot independant framework. My philosophy from the start though hasn't been to support every FPS game out there, as I am not at all interested in hacking dlls and stuff to try to add bots to a game which doesn't support them already. This is a waste of time and IMO a large reason for the UB lack of progress.

That said, a few things I've learned in the 2.5 years of working on Omni-bot. It simply isn't possible to make a bot for a game without some sort of interface layer between the game. Game data has to be translated into bot messages/data at some point, and the only place you have that sort of access is the mod code, or in cases like HL1 you can get most things out of network messages in an intermediate dll between engine and mod. Regardless, there is still an interface layer that is per game, per mod. This isn't a huge deal, as much of the interface code for a single game can be shared. The parts that are different are the parts that are specific to the mod, like the specific weapons, special goals, etc...

Originally when I first started Omni-bot I had things set up so that the interface layer requested the proper game to be created. For example, the HL2M interface would load the bot dll and initialize the HL2M bot support, ETF would load the same dll and initialize it with ETF support, etc... It worked great for a while until it became apparent that this universal dll was not only going to get bloated with each newly supported mod/game, but it was going to be a pain in the ass to deliver updates for seperate mods, basically requiring updates to be simultaneously released for all supported mods, which isn't very realistic when the people working on something do it in their spare time. In addition to this, the universal dll wasn't a very compatible solution considering I was also planning an SDK so that others can add bot support to a new mod or help with an existing one. At that point I decided to split it into per mod dlls. It was a rather simple change, which now results in mod specific dlls that are much easier to manage. omnibot_et.dll omnibot_ff.dll omnibot_hl2dm.dll omnibot_q4.dll, etc... This makes for a much easier to update setup.

A client side bot is not a project I would be willing to undertake. It's a prime project that would likely be targeted by the developer to shut down and make incompatible, since if you could implement a client side bot that means there is potential for significant cheating to happen by the same techniques. IMO server side bots are really your only option, and even then only for games that support bots. Currently this includes HL1, HL2, Doom3, Quake4, FEAR and hopefully will by extension mean Prey and ET:QW assuming they release SDKs. Unreal probably could with a TCP communication channel to a seperate bot process. Any deeper hacking than this is IMO not worth it. In the case of Unreal, it not only already has pretty good bots, but implementing bots in Unreal Script is rather easy and it would be a mis-use of resources to attempt to externalize that. I think Unreal is the single game that has bot support way more than any other game, simply because they are easy to do. Most mods for Unreal ship/work with bots. You don't see the same thing with other engines with real source code based SDKs. I don't know what's possible with Halo PC in terms of modding, but I was disappointed to read long ago about its lack of support for bots. Sounds like possibly some figured out how to hack some AI into it, who knows, bots may be possible now.

So I guess the point is that a truely universal bot just isn't going to happen unless there was somehow an industry wide bot interface implemented into every game from every developer. Since that is unlikely to happen, our option is to support the few game engines that do support bots. Fortunately these fewer engines are the main ones that most of us care about most, so it's pretty good to be a bot developer. It should get alot better if/when valve fixes the HL2 server plugin interface, giving us a path back into bots supporting mods we dont have the source to.


Omni-bot AI framework
http://www.omni-bot.com

Foxbot - for Team Fortress Classic
http://www.foxbot.net


  
Reply With Quote