United Bot for HL2?
 

Since all of the bot developers here have HL1 experience, I was thinking it would be neat to take all that combined knowledge and create a United Bot for the Half-Life2 universe (and not try to support any other engine, just HL2).

Gabe has stated that Valve has ported HL1 MODs to the HL2 engine (TFC, CS, DoD, etc). I imagine the gameplay of those ports will be pretty much identical to the HL1 version except with new maps (possibly larger worlds), and some additional goodness resulting from the new physics system (using Havok), for example, barrels or crates that you can push down on top of people, doors that can be blasted open, etc.

I'm hoping that Valve will also have standard deathmatch with HL2 weapons (like the manipulator gun), but this is yet to be seen.

I can e-mail some key people at Valve to confirm whether HL2 will support fake clients (bots). I'm pretty sure Valve wouldn't leave out this feature since they spent so much time and money getting the Official Counter-Strike bot added to HL1. It would just make sense to port that code over to CS on HL2 as well.

NOTE: I'm pretty sure we won't get the HL2 SDK before anyone else (so don't even ask about that), but there's plenty of generic bot design that can be done before the HL2 SDK and engine is released. I would imagine we would want a navigation mesh type navigation system (since waypoints are big pain in the buttocks to create and automatic waypointing just doesn't do a very good job). We will also need to be able to handle some of the more dynamic things in the HL2 universe (like obstacles being moved around), so there should be some provision for steering around obstacles that aren't shown in the nav-mesh.

Let me know you thoughts on this and perhaps we can simplify the United Bot problem by sticking to a single engine, but supporting the major MODs that show up for HL2.

botman

Re: United Bot for HL2?
 

count me in.

Re: United Bot for HL2?
 

it is a very very good idea! Count me in too. In fact, in a few months when HL 2 gets released (well that is, assuming its end-summer) the HL 1 bots will not work on the updated mods-engines either. And we have to move on...

Re: United Bot for HL2?
 

That is a question that needs a bit of reflection.

If we drop support for various games engines and stick to one but with multiple MODs support, then the bot will not be much different than what I'm trying to do with RACC at the moment.

If we do this, it will also mean that our bot will be tied to the life cycle of this game. As soon as HL2 dies, the bot becomes useless and dies too.

It was furthermore obvious to me that our multi-engine United Bot would support HL2 very early.

Sticking to a game engine allows a more tight integration with the game code, easier access to more facilities, and focus on one representation of the game data. Doing a cross-engine bot is much more complicated for sure, but definitely doable. ALL aspects of a smart bot are doable. Show me one that isn't. It demands more time and sometimes requires crafty methods, but that was the purpose of the game driver.

I honestly don't know what to think. I need to know how YOU were seeing the immediate future of the United Bot before botman proposed this idea.

Botman, which was the diagnostic you had to make of our current situation that led you to submit this idea ?

I'm interested in everybody else's point as well.

Re: United Bot for HL2?
 

but this more engine independant idea isnt bad either, but for this we'd need more time and more coordination ...

( last friday I didnt went to a good party, because i just had to sleep, no way to do anything else ... when this continues like this, i'm some zombie in summer :D )

Re: United Bot for HL2?
 

well, lets say when the United Bot (multi-engine) works with the HL 1 engine, a HL 2 game driver should not be hard to write either? If the concept works then i think we could better stick to that idea. If not, then a HL 2 (multi-mod) bot is the way to go. I don't think HL 2 will die soon...

Re: United Bot for HL2?
 

Exactly what engines were you all planning on supporting with a multi-engine bot?

Re: United Bot for HL2?
 

HL1 because of the knowledge we all have of it

Unreal because of the knowledge botman has of it

Development for these two would have been started in parallel once a reliable method of communication between UnrealScript and a third party DLL had been set

HL2 a short time later

Other FPS engines upon request.

Re: United Bot for HL2?
 

I think its cool enough if the bot just supports both HL2 and most of its mods.

Re: United Bot for HL2?
 

"Botman, which was the diagnostic you had to make of our current situation that led you to submit this idea ?"

It will be difficult to do anything more than a very simple bot for most other engines. Unreal has the disadvantage of only being able to use UnrealScript (which is slow). I have my doubts about being able to pass data back and forth between the Unreal game application and some other application running externally. The biggest limitation in Unreal is the lack of being able to parse the map files automatically (there's no source code available that allows you to open an Unreal map and determine locations of objects and/or polygons in that level). The only way Unreal maps could be parsed is to open the level manually in UnrealEd and save the map out in text format.

As far as any other engines, I have no knowledge about whether bots are even possible in any of them. I've seen some news posts about bots in BF1942. I know that QuakeIII supports bots (but haven't seen any bots implemented outside of the engine's existing bot code). I know for a fact that other games (like Halo PC for example) can NEVER have bots because the engine just doesn't support the concept of fake clients (even though people claim dropping AI monsters in Halo multiplayer maps is bots, it ain't).

I did talk to someone at Valve and confirmed that HL2 will support fake clients (bots). I was told that the Official Counter-Strike bot written for Condition Zero is already up and running the HL2 ported version of Counter-Strike. I was also told that it should be a little easier to work with bots in the HL2 engine (than it was in the HL1 engine).

My thought was that it's better to make a damn good bot for a handful of MODs on one engine (and support every possible feature of each of those MODs) than it is to make a moderately good bot that runs on several different engines (especially if you have to compromise on one engine just to make it workable on several other engines).

botman

Re: United Bot for HL2?
 

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.

Re: United Bot for HL2?
 

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.

Re: United Bot for HL2?
 

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?

Re: United Bot for HL2?
 

"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

Re: United Bot for HL2?
 

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.

Re: United Bot for HL2?
 

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

Re: United Bot for HL2?
 

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

Re: United Bot for HL2?
 

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!

Re: United Bot for HL2?
 

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.

Re: United Bot for HL2?
 

"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

Re: United Bot for HL2?
 

What matters to me personally is writing a bot for HL2. If I can work with like minded bot developers on a united bot to support all the halflife2 mods, then I say lets do it but IMO trying to basically hack other games into letting you run some complex AI routines is both not worth my time, and really not going to get you much in the long run, though if someone wants to do that then more power to them.

Re: United Bot for HL2?
 

I'd say, just write this HL 2 'game driver' (and a HL 1 game driver should also be 'not too hard') to proove this concept works. Once the concept works, writing a game driver for game Z should also work because the bot driver runs on the same functions anyway, its just how the game driver gives them form/input.

Re: United Bot for HL2?
 

Okay. All I wanted to know was whether everybody's opinion was mature enough, because it's quite a switch. Not that I doubted of it, but seeing good points in a suggestion does not mean agreeing with it, and I wanted to know whether you were actually strongly agreeing or not and why.

Okay. I agree too.
Let's make it portable, in this case. :)

Re: United Bot for HL2?
 

I have added a poll to this thread to hear the voice of those who haven't expressed themselves yet. The poll will close next monday. From there on, we'll be able to begin serious talkings :)

HL2 will be coming fast. Things to do:
- reassign the responsibilities
- appoint one or two leaders
- write down all the APIs and agree on as much concepts as possible (discussions ought to be settled FAST!)
- code

Re: United Bot for HL2?
 

maybe we should stick to the game driver architecture, but only develop a HL2 driver for now ... otherwise I fear that porting will then be very much work later on.

Re: United Bot for HL2?
 

CS has kept me busy for 2.5 years, HL2/CS has the potential to keep me busy for a long time. I don't have much free time. Focusing on one platform that we all have a lot of experience on is appealing.

Hey, perhaps with HL2 and a good group of dedicated people, we could get botman involved with bot coding again!

Re: United Bot for HL2?
 

/random nooby coder thought

i was thinking that if u guy's make it so that the bot's basic stuff like movement, personalities, enemy\world\object detection is coded and kept totally seperate from the game engine\PLAY\style

ie..game files work like plugins

then u wouldn't have to do so much work\code for each game

it'll be harder i guess but better in the end since u'll be able to plugin almost any game

(kinda like how metamod plugs in stuff,so metamod is the basics of the bot)

i'm guessin thats whats meant by the game driver archeitecture

Re: United Bot for HL2?
 

i see botmans point here, its going to be _VERY_ difficult to support other games, the HL bot code was obviously difficult to make initially, but i'm sure the HL SDK made this much easier, other games dont have SDKs etc, and conciquently, dont have the same possible bot support. Also, with the complexity of a lot of the games, the main engine will be pretty much empty (except with some common variables, isalive() etc) and the entire game support will be in one DLL, but would probably be easier making seperate bots for each game.

When it comes to HL2, if we follow this 'path' i think we should create a bot for (literally) every mod avaliable, theoretically, its possible, and i'm sure that mod coders will assist us in any way they can.. or maybe make the SMALL / XML systems avaliable, so mod developers can code their own parts of the bots :)

Would certainly proove interesting to see what comes out

Re: United Bot for HL2?
 

I would tend to agree with that. What do you think ?

Re: United Bot for HL2?
 

Sure, that's the natural way to start. You won't be developping drivers for multiple games at once, never ever. Proof of concept works best for one example.

Re: United Bot for HL2?
 

So ! AT LEAST a light at the end of the tunnel ! yay! 8D

So where do we start ? Do we wait in boredom for HL2 to be out (and its SDK) before starting to code anycrap, or do we implement the framework with HL1, or what ? Gentlemen, what do we do ?

Re: United Bot for HL2?
 

maybe we should code the core and code the interpreter for hl1 for now..

Re: United Bot for HL2?
 

No need to wait for HL2. Let's start with HL1, that will reveal potential problems of the design when it's not too late to change it (without having to modify half a dozen game drivers).

Re: United Bot for HL2?
 

Great. :)

Order of the day (well, order of tomorrow for me): define the UbGameDriverAPI and start coding.
Everybody can start brainstorming. Another thread for this would be not a bad idea IMO.