[botman]

"I bet that the format has not changed as much as you would think. It most likely will be some modified version of a Quake BSP format."

That is my understanding also. Since Valve released the HL1 BSP compiler (a slightly modified Quake BSP compiler) with the SDK for Half-Life, it would be a safe assumption that Valve will release the BSP compiler source code along with Half-Life2 (we'll have to wait and see).

The only new map feature that I'm aware of is a true terrain system (which I believe someone at Valve mentioned in an interview, was done with heightmaps). I would imagine the HL2 world geometry consists solely of BSP geometry and a heightmap terrain polygon mesh. If the map compiler source code is released with the HL2 SDK, then it will not be too difficult to parse the compiled .bsp file to extract world geometry data.

There are 3 problems I see with other games:

1) Some games just don't support bots. Period. If the FPS game is based off of an engine that supports bots (like Quake or Unreal), chances are that the game will support bots in some form or another. Sometimes bots can only be accomplished by creating a network application that connects to the server and simulates a human player sending movement commands over the network. There were MANY QuakeI client-side bots that worked this way. Now that client-side cheating has become such a hot issue with gamers, most game developers are encrypting and/or securing the network connection so that fake clients are no longer possible.

2) Games that do support bots do so in a limited fashion. Some games like QuakeIII or Unreal 2K3 have built in bot support and the engine provides a limited set of functions to get the bots to do things that the original game designers thought the bots would need to do. In order to do anything more complex than the original provided behavior (like using a navigation mesh instead of relying on waypoints), you need detailed information about things in the world. Some games don't make this information publicly available. You can spend many, many, many hours trying to reverse engineer the game data to extract the information you need, but if the game has been available for very long, and no one else has been able to reverse engineer this game data to extract things for other uses, you can probably be assured that it won't be a trival task to get the data you need.

3) Games that don't provide a method to use native (compiled) code could have performance issues if you want to create complex features that require significant processing power. If this processing can be extracted from the game and done elsewhere (in a separate application running on the same machine or done on a separate machine and networked to the game machine), this can prevent the game from becoming sluggish during periods when a high amount of CPU processing is required. Games like QuakeIII and Unreal2K3 only provide an interpreted gaming script language. You can't compile this to native code, only to interpreted byte-code. Interpreted code runs much more slowly than native code (usually 10 to 100 times more slowly). You can usually do complex features in interpreted code, but you shouldn't depend on these calculations being done frequently (like during every video frame). If you can find a mechanism to extract these calculations to an external application and develop a communication mechanism with the interpreted game code that doesn't use up a large chunk of CPU time or network resources, then you can bypass the interpreted bytecode issue. Again, this may require some reverse engineering or Operating System specific hack that could take a significant amount of time to implement. Obviously finding source code elsewhere that does something similar will save some time, but such source code doesn't appear to be available for any of the games that have this problem.

The real answer is, "If you can do it and make it work and not cause additional problems (like lower framerates or network lag), then by all means, use that to extend the usefulness of the project". But if you have to spend 3-6 months with each engine trying to see what is possible and what is not, you are using up a lot of time that could be spent doing something else (but, if that's WHERE you want to spend your time, then only you can make that decision).

I'm not trying to say "Give up on every other engine, Half-Life2 is the ONLY one you should care about". I'm simply trying to find out if more people are interested in working on AI code for Half-Life2 than are interested in trying to get common AI code working across several different engines. Again, it's a personal decision about WHAT type of coding you want to do over the next several months to several years.

botman