United Bot for HL2?

[DrEvil]

Bots are so easy to implement in unreal, most mods support them anyways. Plus, it was brought up at Unreal University(from a question to the developers about exposing engine functionality for a guy to develop an AI toolkit) that they wouldn't allow external programs to link directly into the engine without possibly licensing fees and approval, because they don't want you to have access to the engine. If someone has found out how to do it, don't be surprised if it gets shut down. What else does that leave? Q3 engine bots? Battlfield 1942 doesn't give source access either I don't believe, I think you have to do alot of the modifications to that through scripting as well, though its been a while since I looked into it so I could be wrong.
IMO it would be time better spent making a united bot that supports halflife 2 and all its mods, especially considering its looking like valve is porting all their mods to source. Redfox and I would like to head up the Team Fortress Source aspect, assuming TFC is one of the mods they port, which it appears it will be.

It would be nice to cooperatively put together a rock solid framework with which mod support can be built on top of for all flavors of HL2.

[Whistler]

but if there's offical bot in HL2, I don't think anyone would use this bot (just like Quake3 - have you heard of any 3rd party bot for Quake3 ?)
And that's quite possible since I have heard it's Michael Booth that is working on CS2.

[DrEvil]

Other than the CS bot, I highly doubt they are going to make official bots for any their mods.

IMO the reason why you didn't see quake 3 bots is because in order to do them they had to be built into the mod source, and since most Q3 mods didn't give a flying shit about bot support none of them ever did it, so you pretty much had to do without.

Oh how I would love to create a bot for Quake3 Fortress, but that'd mean getting my hands on the mods source, which most mod teams will not do. Halflife is the exception, since bots can be made independant of the mod dll, though this is potentially dangerous and can lead to abuse. Hopefully this functionality is still in HL2, so bots can evolve independantly of the mods.

Botman, any idea of the bots will still be set up as they are now, or will they need wrapped up and compiled with the mods?

[botman]

"Bots are so easy to implement in unreal, most mods support them anyways."

Using the existing Unreal Script bot code is easy. Replacing that limited Unreal Script bot code with something more complex (like something that doesn't need PathNode actors) is MUCH more complex since you don't have access to the engine or level data.

"Botman, any idea of the bots will still be set up as they are now, or will they need wrapped up and compiled with the mods?"

My understanding is that HL2 will include some interface similar to metamod (since Alfred, who created AdminMOD now works at Valve). Bots will, more than likely, be written as plugin modules and you can run multiple bots at once by just running different bot plugins at the same time. Valve hasn't officially announced any of this, so this is purely a guess on my part right now.

botman

[Pierre-Marie Baty]

That's where my point is, but let's not be fooled by our experience!

To me (the usual weirdo) there is absolutely NO difference between the metamod interface that Will Day and Alfred Reynolds came up with, and the DLL hook method that botman first imagined for the HPB_bot, which, let's say it again, WAS a crafty hack. The goal was exactly the same, in extenso add bots to an engine/game DLL pair to none of which we had the source code!

Today we are so much used to Half-Life, Counter-Strike and Day of Defeat because of years of experience with our bots that we could almost rewrite these MODs from scratch without a single look at their source code - which we never had a chance to look at anyway. Isn't that true ?

When we'll start with HL2, but ALSO when we'll start with Unreal/QuakeIII/Far Cry/insert-your-favourite-game-here, we'll be at the SAME point where we were a few years ago. The only thing we know are techniques of AI coding. But the way these games work, their internals, how to hook them and how to force them to do what we want, will be completely sibyllin to us.

We'll have no idea on how to get the polygons from the HL2 map files to build a navmesh either.

We'll have no idea on how the new entity system will work.

We'll have no idea on how a particular MOD will make its clients interact in the client-server relationship.

We'll have no idea on how to hook on sounds

All this WITHOUT the MOD's source code

In this regard, excuse me but I don't see how writing an advanced bot for HL2 will be easier than writing one for Unreal, one for QuakeIII, one for Far Cry, etc. ?

Please enlighten me here.

[Huntkillaz]

um...here's something about the source engine valve's gonna use ..not sure if it's any help though

i guess u'll know what can be done when sdk kit comes out

http://www.valvesoftware.com/sourcel...nefeatures.htm

[sPlOrYgOn]

Originally Posted by Pierre-Marie Baty

We'll have no idea on how to get the polygons from the HL2 map files to build a navmesh either.

We'll have no idea on how the new entity system will work.

We'll have no idea on how a particular MOD will make its clients interact in the client-server relationship.

We'll have no idea on how to hook on sounds

All this WITHOUT the MOD's source code

http://www.hl2source.com/
read the interviews
hl2 will be using BSP still

[Pierre-Marie Baty]

and the point would be ... ?

I don't care at all whether they are sticking to BSP or not, the fact is that the structure of their files WILL change, and unless we get the SOURCE CODE of their new BSP compiler, we won't be able to extract the vertex coordinates out of these map files easily at all! Keep in mind that IF with HL1, botman's bsp_tools, all the third-party BSP viewers, and our bots' navmeshes have been made possible, it was because we had the source code to Zoner's compilation tools!

[sfx1999]

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.

[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