server-side bots

[quadz]

Hola,

Can anyone recommend any server-side bot modules for Q2 ?

Is there anything similar to Q3 arena, where a server could have, say, 5 server-side-bots on it by default, but when a real player joins, one of the bots disconnects?


Regards,

quadz

[QwazyWabbit]

Phlem<WOS> was working on a FEAR SDK based server side bot system for use with LOX. He has not shared the code yet and the project was side-lined recently due to pressing home matters. Here's what he wrote in our board in July.

Anyway, I had earlier found an AI framework called "F.E.A.R." (not related to the later game of the same name) that is pre-wired to work with Q2. I have been dabbling with some of the sample "animats" or animated creatures provided in the FEAR SDK. I have all but one of these working on a local server that still allows multiple "real users" to connect. The one flavor of animat from the SDK which is not working seems to just be missing some type of config file from the SDK (which is now about 4-5 years old and out of maintenance).

I think this is what he was referring to:
https://blog.itu.dk/MVAI-E2009/fear-platform-demos/

[The Happy Friar]

i think eraser kicks when someone joins.

the only bad part: no mod support
other bad part: people don't like playing bots when they can do it @ home.   

[peewee_RotA]

i think eraser kicks when someone joins.

the only bad part: no mod support
other bad part: people don't like playing bots when they can do it @ home.   

As long as the bot code in question has released it source, aren't most of these features a trivial change? I'm not sure which ones are open source though.

As for mod support, I've always assumed that that was an unrealistic goal for quake 2. From what I understand, it's not possible to load a server side bot as well as another serverside modification. So the bots would have to be built into the executable that the server uses. This opens up a big can of worms in my mind.

(and at that point wall-fly starts to change his whole purpose. bots now, terminators tomorrow)

[QwazyWabbit]

It's not that big a deal to cascade mods. I run GameCam and Q2admin over the LOX mod, and each is a separate DLL and no "special knowledge" is needed in each DLL to accomodate the others. (Well, each one has to be coded to load the next DLL in the chain, but this is trivial.)

There was a mod dll called cascade proxy or something like that, which would allow any number of gamex86.dll's to be cascaded in this way. I think I still have a copy of it.

I think a desirable bot mod would be a separate DLL that would allow it to be used with every modern mod. (some older mods we no longer have sources for might be incompatible.)

[The Happy Friar]

that's a good point: q2admin's dll points to a "real" dll for the mod.  A bot mod could do the same thing.

But peewee, we've got other plans now!!! 

[Slayer :D]

Another problem would be making the bot compatible with the new features the mod offers. In Lithium, the bots wouldn't hook or use the runes. In WODX/LOX the bots wouldn't know how to use the bonus weapons. Personally, you would probably end up having to integrate the ACE bot or something related into the mod's code. I know that some mod authors have added an editted version of the ACE bot code into their mods to make the ACE bots play that mod and use the new weapons.

[The Happy Friar]

the bot could be modified so that it's told what sub-mod it's running & use the appropriate routines for that mod.

But still: i don't think people want to play vs bots, they can do that @ home.

[peewee_RotA]

the bot could be modified so that it's told what sub-mod it's running & use the appropriate routines for that mod.

But still: i don't think people want to play vs bots, they can do that @ home.

Not on a specific mod. Imagine CTC, DDAY, Actionq2 teamplay, gloom, or even CTF with bot players to fillup player slots.

No matter how the bots are made, they would definitely have to be programmed specifically to handle each mod.  So no question it is a TON of work for anybody to undertake. I would say that inserting a bot into individual mods would be a bad course of action because any updates would have to be repeated over numerous source codes.

My best suggestion is to rip apart something like ratbot and include that in the servers executable to just fill up slots, like wallfly. That way any bot would be "able" to play any mod because they can at least spawn in, move around, and fire. Then they could be specialized one mod at a time.

It also wouldn't have to run in the server executable, you could have a separate application running that connects to multiple servers with multiple instances of a bot.

The only advantage that you have to including bots in the mod, rather than connecting as clients, is that it eliminates incompatibilities in anti-cheat as well as risks of people exploiting the new bot application and security exceptions.

[The Happy Friar]

ok, if that's done what's to stop q2admin/anticheat from seeing a bot connecting?  IE how does it differentiate from a "good" bot & a "cheat" bot.

[yahoo]

I think a good bot would be named Wallfy and a cheat bot probably is named razor.

[peewee_RotA]

ok, if that's done what's to stop q2admin/anticheat from seeing a bot connecting?  IE how does it differentiate from a "good" bot & a "cheat" bot.

Yeah that's what i mean about incompatibilities in anti-cheat. Whatever exception is set up can also be exploited so it's a pretty big consideration. Building them into the server executable should not have the same problem however since exceptions would be much easier to build and reinforce.

I would just worry about that creating a bigger server load and increasing the amount of processing power/memory required for each server slot. So having a secondary application that runs on a different server and is dedicated to just running multiple bots should address any problems that may arise from that.

I think that both situations are better than maintaining the same bot code on multiple sources. Plus if the multi-dll solution requires editing the original mod source, then a bot app that connects would not need the original source.

[QwazyWabbit]

As for good vs. cheat bots, a good bot is normally clientless, the LOX decoys are wimp AI owned by a client and they have pointers in their structures pointing the owner to the bot and the bot to the owner and the decoy doesn't fill his client info, of course this is inside the mod so it's not the same as an external bot DLL.

Enhanced weapon selection in most mods is done from the base weapon, at least in my experience. LOX for example, has special weapon names for direct selection but if you repeat the same 'use super shotgun' command it scrolls thru the enhanced weapons in that class. An AI could be programmed to do something similar against all the weapon classes.

The AI module could use external text configuration files to allow modification of AI behavior per each mod that would not require modifying the actual code. This would allow admins to select what features the AI could use. Decisions about which class of weapons to use could be done by flagging each weapon name (in the config file) with short or long range attributes and suicidal vs. safe. This would allow for some interesting AI actions.

AI in game has always been a challenge to code. The monsters aren't much of a challenge for a skilled player so getting an AI to be smarter about his mobility and skill would definitely need work. But the purpose of the AI isn't so much to be a skilled player in a full server but simply to give users something to do besides wander an empty map waiting for another user to connect. Besides, a single player in a server with 30 AI all carrying rocket launchers and rails might be a challenge.

As for anticheat, it uses client-side inspection of client files to detect cheats, anticheat in the client and r1q2 server cooperate in order to do that. AFAIK anticheat doesn't do anything server side to detect aim bots independently. R1ch can address this issue if he cares to.

I prefer to use AI to mean server side (good) bots and bots to mean client side bots like ratbot or zbot.

This FEAR system is huge, I have not wrapped my brain around it yet and it requires the boost library and the version of boost I downloaded seems to be incompatible as the fear project can't find some of the boost files. I have not tried to run the demo.

[The Happy Friar]

I would just worry about that creating a bigger server load and increasing the amount of processing power/memory required for each server slot. So having a secondary application that runs on a different server and is dedicated to just running multiple bots should address any problems that may arise from that.

i'd say using bots to log on to a server would be more strain vs running them @ the server.  The nyou have client connects with in/out bandwidth.  Not much for Quake 2, but depending on the server hardware, bots running @ the server is a non-issue.

IE D3 tech is the most CPU intensive with bots & I don't cap ~15-20% CPU usage with my server & bots.  When I've run Q2 with bots it's barely a blip on the CPU usage radar.

[peewee_RotA]

I would just worry about that creating a bigger server load and increasing the amount of processing power/memory required for each server slot. So having a secondary application that runs on a different server and is dedicated to just running multiple bots should address any problems that may arise from that.

i'd say using bots to log on to a server would be more strain vs running them @ the server.  The nyou have client connects with in/out bandwidth.  Not much for Quake 2, but depending on the server hardware, bots running @ the server is a non-issue.

IE D3 tech is the most CPU intensive with bots & I don't cap ~15-20% CPU usage with my server & bots.  When I've run Q2 with bots it's barely a blip on the CPU usage radar.

As far as eraser style bots go, you're right. I'm thinking more about a wall-fly that moves.


As a note, QwazyWabbit definitely knows more about what he's talking about than I do. I'm just brainstorming.