I posted the same topic over on i3d. That is more of a modder base, and this is more of a player base. I'd like to hear the point of view from as many as possible.

I'm looking to develop a rather extensive bot, with the goal of being as human-like as possible.

I thought I'd put the questions out there... what do people look for in a bot to make it really distinguish itself as being more than other bots they've seen, something that can truely impress and make you doubt you're playing a bot, and give the illusion of being human.

In short... what do YOU think makes a good bot?
What are some bots that you've seen that do these things well as examples? It can be anything from features to specific behaviours.

This also doesn't need to necessarily be limited to existing bots in any way. What do you think you'd like to see in a bot that you haven't yet?

On the other end of the spectrum, what sucks and is obvious a deal breaker?

Be as detailed or as vague as you like (but if it's vague to the point where it doesn't make sense, expect me to ask for more info )

Bots never seem to spam . like throwing grenades at spawn points or entrances.
some artificially set hit-% would be nice, so u can have a bot with 30% shaft.
Bots don't speedjump or trickjump much.. Should be possible to "record" trickjumps for the bot that it can emulate.
Kind of like ppl did in old days with ultimate online.. record some mouse movement/click/keyboard sequence for automated procedures.

Should be possible to have different styles of play. So you can play a very aggressive dominant bot, or a camping bot.
Could perhaps emulate certain player strategies so you can play against a Milton bot for duel practice =D

I always liked the bots with personality ... that would say stuff in the chat in certain situations. It's always fun when someone whines, so ofc. some bots should be whiny fucks when they get raped =)

All excellent points and most already planned in my ai so far

Some points of interest for spam (I think)... places we could see the enemy last, known areas where people have died lots (bot will be in a way constructing an internal kill/death map, so that it knows hot spots for both... helping it know effective places to be or fire at/keep an eye on), last place we saw the enemy from, tele destinations, spawn points.

Hit percentage is a little hard to artificially ensure. Even a bot that is meant to have 100% accuracy could in theory miss. I'd prefer the accuracy of around 30% for LG for example to be the result of a heap of parameters, including the bots reaction time, sensitivity, and the enemies ability to dodge and knock them around throwing their aim off.

Trick jumping is VERY tricky (just as general navigation). Haven't put much thought into this at this stage, but it's definitely something that needs to be explored. I'm all for doing the physics properly, no artificial velocity boosts (*gives cpma bots an evil look*).

I've already got the recording component mostly complete for special moves. These are the kind that can't be waypointed and require very specific moves to pull off, the bot would have no way of detecting these automatically, especially considering the original mappers would most likely have not known about the moves in the first place.

Personality files are a definite must too, agreed. By setting up a bunch of characteristics, you should be able to create a similar playstyle of people you're familiar playing with in ways, whether that's more aggressive, more prone to a particular weapon, camping a lot, hogging items in TDM and not sharing. There's quite a fair bit should be able to be tweaked. No it's not needed, and I'll be including a heap of bot personality files with the ai, so people can't just use those if they like.

Skill settings are then relative to that file. So a skill 50 bot of ProfessorX for example, who has awesome aim, will still be able to aim a bit better than a skill 50 of StevenHawk who has poor aim.

Chat is something I'd like to explore a bit, but I really can't justify spending the time on it at this stage, it really is about getting something playing and being believable. I'd like to be able to spectate them first person and have a difficult time spotting if it's a human or a bot. If I can get to that point I know I've done a good job

I must say a few words about bot speed/trickjumping. Some time ago i did some little things to emplement it.. but my enthusiasm just exhausted. Jumps can be recorded to simple qwd file, then processed by LMPC, and i wrote a very small utility that grabs only necessary information about that jump - coords, and orientation of a player. Also Tonik pointed me that there is a feature in KTX mod .. trx_rec trx_play, that could be modified to use that data.. if someone really want to emplement bot speedrunning it wouldn't be very hard..

The thing that annoys me most in FBCA is the air movement of the bots - when you shoot them up in the air with a rocket, they will do some absolutely crazy move there which humans are incapable of doing, land exactly where they need and meanwhile they are still shooting on you quite precisely. Human players do not control their movement in the air that much, maybe only when it's a movement they have intentionally started. But when it is a consequence of enemy rocket, there is no time to think about "where should I fly, where should I land" etc.

(about my previous post) The harder thing is to get bot back on rails after he got shot - bring him to starting point of a known jump sequence.. if you want to do it and not to break the physic laws

I'd just like to see them acting more human-like. I remember Frogbots being pretty much useless in anything else than dmm4; they just stroll around their simple waypoints and never do anything unexpected. I'd like to see the bots actually sneaking and denying you access to stuff, and every once in a while they could act differently in an identical situation.

If the bot movement is problematic how about a different model for a bot? Some kind of hovering orb, ie. the one Luke Skywalker is traning his lightsaber skills against? FFA mod with monster-bots, ie. shamblers would be awesome 8)

!! Bot's that are able to be on multiplayer ffa-server to fill playerspots are ESSENTIAL for the QW-scene !!

So, Electro PLEASE do that kind of a bots and I'll crown you the King Of Quakeworld, because I've the power to do that.

I Agree with ParadokS. And prediction rockets (spam rockets) would be awesome aswell, especially if bots do them as accurate as humans, ie. they are ~50% accurate.

Good teamplay.
Example: the q3 arena bots had pretty good teamplay for CTF (same author wrote omicron bots I think). They would elect a captain that then would send others on attack/defence depending on their spawns like 3 on def, 2 on attack in 5v5. The bot captain adjusts his team by parsing frag messages/team messages iirc. There's a pdf out there about how it was achieved ("The Quake 3 Arena bot" by Mr. Elusive IIRC) that you most likely know.

aim: Should be kept in a realistic frame (maybe +10%). Maybe the bot could auto-adjust to opponents aim he expierences through a match? A common mistake that the more advanced q3 bots have in common (spiterbot, cpma bots < 1.40 release) is that their aim is not weapondependent. 80% rail, ok, but 80% plasma?
The ability to knock them off their aim with good rockets etc., something thats also missing in current bots, like others have mentioned.

Realistic and good movement, maybe again auto-adjust to his opponents ability. If he can learn trick jumps from users, it would be cool to have an online database where he can download the latest and greatest tricks.

Good understanding of sounds.

Maybe the bot could learn by writing down his experience to a log file and analyse it on start up? That could help him to adjust to his human opponent over time.

If at all possible, no wallhacking or other hacks to make the bot more "challenging". Those kill the human-like approach instantly imo.

As others have mentioned, personality. (loaded frikbot or some other some days ago, typed 'impulse 100' and the first thing the bot did was to write "LAG!!", really funny

wow, lots of good stuff in this thread.
there's many things a good bot should do, if you are sucessful in doing a bot that does the things described on this thread, you have my vote for the king of qw 2011! =)

example: battle in dm2 bigroom, dogfight between bot and human. human is almost dead, he retreats and runs to low rl. imo, the bot should go after him or revaluate his condition (get health/armor first)? what about ammo? are 2 rockets enough to kill? =)

Pleasing to see this thread as has been some time since any serious bot development was done for QW (probably in part because of how good FBCA is). Quake bots are in some sense my passion, because that is how I learned Quake before I got an internet connection, and when I got online I was very active in the botting community (botboard.telefragged.com)

Anyway here are my thoughts about what FBCA does well:

-Item timing, good example is ztndm3 RA, they compete very well for that.
-Aiming with all weapons
-General movement that doesn't involve speedjumping (relative to other bots I've seen, not humans of course)

Things I'd like to see in bots moving forward:

-Interpreting sounds, for example using pickup sounds to work out where players are. Whether or not the code actually uses soundcues or not is not that important, it just needs to behave as though it can hear things (e.g. armour pickup sound - spam exits near that armour, or evaluate decision whether to attack based on opponent armour vs self armour)
-Spamming places where it has seen/heard players recently note this should ideally include teleporters in the equation e.g. if the bot 'knows' I am at dm4 RA it should spam teleexit
-Delay in reaction time when the player suddenly appears i.e. not able to instantly zap players with hitscan weapons when they come round a corner if they are 90 degrees to away from there, it should take a few frames to adjust aim
-Hitscan weapon aim should be more 'erratic', not necessarily locked at 30% but much more varied, e.g. sometimes they should completely miss with shotgun.
-Better prediction of likely player actions ideally 'learning' cycles that players use against it. Currently bots don't teach players good practice because they don't punish predictable behaviour, whereas a human opponent will start to pickup on your tactics if you repeat them too often.
-Conversely, bots sometimes are a bit too predictable; going back to item timing one thing I noticed is that frogbots love the RA so much they go there all the time, even on dm3 where it can take a long time to get to. You can literally just wait around at RA mopping up all these lemming bots that come charging into RA with just SG, putting themselves at a massive positional disadvantage against a player with RL.
-'Cutting off' players would be nice to see, e.g. in a situation where the bot should 'know' that you are weak (after a fight, after a respawn) it could be a lot more aggressive in preventing you from reaching items you are likely to be pursuing (health, armour, weapons). Oftentimes bots are too passive and fall back to default routines of cycling armours, which doesn't make sense if the opponent has 0/100/sg and could be easily killed again rather than being left alone to stock up.

Ultimately the main, insurmountable issue with bots is that because they lack the intelligence of humans the only way they can be competitive is by being given superhuman powers in other areas (typically aim). If you try to make a truly realistic bot, it will be too weak because it shares all the weakness of humans (erratic aim) but not all their strengths.

As a point of interest, can you link the i3d thread please so that we can eavesdrop on the modding conversation?

Way-point based bots = fail by default. AAS is a way to go, that is used in Q3 in 1999? Actually it even used in Q2 by gladiator bot by Mr Elusive and later Elusive (and his AAS) was acquired by ID Software in Q3, IMO. But it is shit load of work.

Regarding what makes bot/player GOOD opponent => sensible unpredictability, well, with bot even some random behaviour whould be OK :\ . Since it is quite annoying to see how bot all the time doing same move and dies on spam grenades and such, at this point you clearly see that it is AI and you wasting your time on fighting with ROBOT, which is BORING.

Ouch at last what I'm longing to hear since long time ago! Someone trying to develop a new bot. I use to play with fbca almost every day and I like it very much, but many things it does just pisses me off like hell! It can instantly distinguish sounds from team and enemies, some times when it got quadded, seems like it chases you throughout the map very acurately, in level 20 I could notice some rare bizarre behaviors, I use even to see the bot "jumping physic space" or moving like light-speed in a ridiculous attempt to get rid of the threat. Not to mention the total control of items time spawning and air moving in the map. And furhtermore, well, ok I'm going nuts now but, some times the bot seems someway to lead you to commit errors, like if it would hipnotize you. Ok maybe I'm playing frogbot a little too much, never mind. But the idea of a new bot is exciting, the bot from quake3/CPMA mod I think it's very nice and human-like, speed-jumps and stuff...I would love if a quakeworld bot would rise up with such good things. Please continue!

I agree with luchten - NO Hypnosis features in the bot!!!!1111

VanoZ/leopold:
I've already got a similar thing half done (the recording component is done) that allows players to press record, perform a move, then press stop. This information (essentially keyframes or critical frames that are essential to performing the move) are all that's kept. That's as far as I've bothered to go with that so far. The idea is to then save that information out into an external file, and allow people to share "tricks" to build up the bots knowledge of a particular level. These of course we need to all use the same navigational data set, and each trick would need to to be tied in to the navigational data. Knowing when to abort or when a trick has failed is something obviously the ai needs to handle, as well as meeting the criteria required to perform the trick in the first place (RL + ammo if it requires RJ'ing for example).

JohnNy_cz:
Yeah definitely, I found that ridiculous as well. Unfortunately, the problem there with frogbot is that it's using it's own version of the player physics, so the same thing that allows it to do such unrealistic moves that are physically impossible to the player, also allows it to perform the jump on dm4 from GL to stairs. This is due to the fact that the client air control stuff is very reliant on angle changes with mouse, and well... the bots don't have mouses, so I'll need to see what can be done in that department. My bots will use 100% exact same player physics as humans.

mipa:
Different strategies and a heap of fuzzy logic, check

PEKTOPAHKY:
I want the bots to look as much like human players as possible.

leopold:
Yeah I've got some pretty big plans for teamplay, 2v2 is my personal fav. One thing I have in mind is that the bots will try to spread out and control the map, getting lockdown is so important. They'll also communicate via chat with each other so that human players can see what's going on, as well as guard items for nearby teammates and let them take things, or taking it themselves if they think the enemy is about to get it.

Another feature that I think you'll like is the dynamic skill one. The bots will adjust their skill based on where they're sitting on the scoreboard in relation to others, hopefully creating closer more competitive matches.

Learning beyond that is something that is extremely difficult and hard to cater for. I'd rather make the bot the best I can in as many circumstances as possible than go crazy trying to do something like a really complex neural network that sounds good in theory, but when put into practise just looks like a shit player or that isn't noticeable or doing it's job.

The bot will not cheat at all, at best, based on its skill, it will make approximations to the locations of things. Higher skills will make more accurate guesses on locations of events. They won't know 100% for sure unless they visually see something. I plan to have this wrapped around the whole hearing awareness system.

Everything will be wrapped around the reaction system and everything has to go through that before it's considered validated/true. So if an enemy comes in to view, there is a slight delay until this is "realised".

Bots won't know where someone is unless they hear it, or see it.

I'll have a basic chat system at the very least, for random stuff like that, but most likely at least based on some events going on.

mushi:
Yeah enemy assessment and rating them vs themself is a big deal towards choosing a strategy. The bot will decide whether it needs to chase/flee or continue what it's doing etc. (I have quite a few strategies planned) based on a lot of criteria.

HangTime:
Cool! botboard was awesome, wish it wasn't down Would probably be some stuff in there worth reading through.
Item timing definitely. With the routing system I have, I'm able to make the bots time ANY item, even ammo. Obviously I won't be doing this, and timing ability will be tied to skill and personality.
Cutting off players is definitely something I'd like to try and implement, it really is difficult to know where someone is heading though. Possibly can do this though based on the influence map data I'll be storing (for events such as dangerous areas for explosions/deaths, and good spots to be to get kills/camp) This information can then be interpreted by the bot in all sorts of ways, a bot with a powerup can be far more likely to go into the dangerous zones looking for trouble. These of course would be completely dynamic based on how the game is playing out.

qqshka:
I plan to use a hybrid navmesh/node based system I'm coming up with. Navmesh will need to be hand made, but I'll be making an in-game editor and have some pretty nifty tools in mind (think 3dcoat retopology tools)
Yeah I completely agree, need to make them unpredictable. Going to be hard!

luchten:
Yeah! No cheating! It's filthy.

fed: haha

What I had in mind with learning was something like the brainworks bot for q3 would do: IIRC he would (by dividing fighting into aim down/straight/up) learn from the sucess he had with specific weapons
in specific situations in the past which weapon to choose in fights depending on the situation he is in. This experience would be lost after the game is closed so writing that into a file would be good.
However this maybe too complex, I agree.

The way I see it would be this (in broad layman's terms, maybe not the easiest to code):

1) The bot should have a way of knowing how quickly a player can travel from any location on the map to any item. The simplest way would be to look at distance but this doesn't take into account teleporters or if the route is possible due to the need to gain more height than is possible. Likewise some areas are easier to speed jump in, or have water to slow you down.
2) The bot should evaluate what the player's likely goals are based on current status e.g. get weapon, get armour, get health, powerup spawning soon...
3) The bot should evaluate if the player is likely to seek to engage in, or avoid combat (based on relative strength)
4) The bot combines #1 #2 #3 to guess what the player is going to do i.e. what is the quickest way the player can satisfy their needs.

It may even be possible to hardcode likely player actions for different scenarios rather than risk trying to dynamically calculate them as above. Especially in terms of spawns, on some maps experience tells us as human players what an opponent is likely to do. A guy who spawns nailgun on ztndm3 will usually go for the mega+rl (unless the enemy is stood inbetween). A guy who spawns tele on dm2 will usually push the button and go for high rl etc.

Seems to be this thread: http://forums.inside3d.com/viewtopic.php?t=4218

HangTime:
With the method of routing/pathfinding I'm using, travel times are known, yes. I've already got it in my plans to try and assess what a player would most likely want (even in combat) so the bot can choose to fire at those things directly to avoid them getting it. It really is a tricky topic to try and anticipate where the enemy is going to be heading, and you wouldn't want the bot to always do it either... definitely a very human trait though, would be fun faking them out

I'd really like to avoid hardcoding actions per map, hacks just result in messiness and general slop. I'd much rather break down the problem into what is required for the bot to carry out those actions, because it's likely that given a similar situation on a different level, the same tactic can be applied.

Hearing fresh spawns and knowing that they are most likely going to go for the closest most powerful thing to them should be fairly easy to do.. it's then a matter of assessing whether the bot can beat them there (or rather, to a point visible to there so they can attack), and if not or it's close, then would they need to rate the player as if they have those items already and decide whether or not to rush it.

leopold: thanks! with all the other chat that completely slipped through, cheers

I'm (very uninformedly) sceptical that you will be able to get anything approaching humanlike behaviour without an ongoing, arduous detailed analysis of flaws in specific situations, and solutions that embody knowledge that would be too hard or labourious to generalise and be capable of being generated by abstract rules. I presume the best chess AIs would break down pretty bad if you changed the area of the board to 81 or even 49, is this a sane analogy?.

Current bots have no pattern recognition of dodging, avoiding their rockets is about as easy as putting your hand through the path of a 5/4 Hz pendulum. And their dodging is entirely predictable, in fact controllable by where you move your mouse, and it is one dimensional. There is no capacity to anticipate and exploit even the simplest rhythm.

As you noted, acceleration is a function of rate of rotation of the player's viewing angle (offset by right angle to the direction key) and is inversely proportional to speed. If you can describe this function you could in principle make a better mover than humanly performable, how hard would this be?

There are absolutely a lot of cases that some people would think are "special case", but can be handled by a bunch of generalised rules, coupled with flags on nodes informing the bot of any specific actions that might need to be carried out.
On that note, if there's anything you think it'd be handy to be able to try get the bot to do through the influence of node flag settings that'd be useful, that'd be worth knowing so that I can plan for it as much in advance as possible.

Yeah pattern recognition is a big task... something that could possibly benefit things in quite a few situations. It's possibly something that can be looked at later down the line. It would be easier (and cheaper cpu wise) to gather a bunch of stats from dodging in combat and then have the bot use values like that, rather than trying to hardcode any kind of pattern. Each bot with their different profiles will actually result in slightly different behaviour, so it might not be as drastic as you think (or as what is currently available).

What you're describing is very difficult to pull off, if not, impossible. The math involved is probably not even realistically doable at realtime framerates even with todays hardware, let alone with the amount of cpu available for ai to use There are just so many factors to take into account for actual humans with hardware vs simulating them with purely software based solutions feeding directly into engine functions.
To truely simulate something like that, it'd need hardware latency, as well as going via the drivers and OS api's (eg. directx). Meaning that you could actually simulate the movement of the mouse.

For move keys, I'm simulating key presses through bitflags, saying whether or not particular keys are pressed. This is then fed straight into the physics function that proper clients use. In essence, it's as accurate as can be. It doesn't currently have any kind of delay for release/repress like humans would have, nor does it simulate hardware latency (I have no intention of doing this, as it's overkill and not needed as I see it).

For looking..currently I'm setting angles and best I can making acceleration/deceleration using a spring/damper physics model. There's still quite a few bugs to kink out in the turning, but it's going to be quite realistic. As far as the engine is concerned however, this still doesn't feed through the pipeline like a real human does, although it's close. I'm yet to see how drastically this impacts on anything like getting them to perform trick jumps or bunny hopping.. but that's far down the line at this stage. I've got bigger rotfish to fry.

The real question is: When will we see a beta?

I doubt I've anyting to contribute on that. But I (and hope many others) would like to critique your ideas.

The bot should compensate for deficiency in feinting, by being able to react instantaneously to the projected position of explosions and choose the best escape or mitigation (which frogbot doesn't do) weighed against moves to more versatile positions (and exploiting enemy rockets for rj, i wish , aggressing to finish or be finished, or retreating if viable.


I'm keen to hear why that's necessary. You can find the approximate max speed on the ground with +forward; +moveleft;+left ; cl_yawspeed 596 (at 154 fps iirc. experiment.) which is 491 u/s iirc and with jumping and given enough area you can get into increasingly faster, very stable (almost-)circles, by adjusting cl_yawspeed downward at each plateau. So why can't you calculate the optimum rate of rotation as a function of speed? It's a simple smooth inverse relationship that doesnt need real-time calculation. And once you've derived the optimum, you can work out the shape of the arcs. And of course the computer could approximate straight line movement by rapid alternation of arc direction better than us.

Choosing a valid safe spot for incoming projectiles will be done, yes. It's a tricky problem, but with the navmesh stuff I have planned it'll make choosing a valid spot simpler, and hopefully even be able to be randomised a bit so as to not be so predictable.

Using enemy rockets for rj'ing hehe.

Turns out I was wrong regarding the mouse stuff. It's all the angles and is still doable. The curves absolutely do need realtime calculation though, there isn't infinite space to move around in, they need to take into consideration safe moveable area that they can arc to, that will then be able to have them arc back towards their desired positions. They'll most likely only do smaller arc movements, but it'll be optimised for minimal path deviation while gaining speed. There's going to be a lot of numbers for me to tweak/balance to get things decent.

This is all far down the line however. There's more important things to do well before any of this.

I would like an improved User Experience and interface for the bots.
Better ways of adding/removing, Customization possibilities etc.

Example: To be able to create a bot named "Haritsoppa", that has NG as his favourite weapon, uses the finnish-whine.txt as his quotes.
And then I would want to be able to add him using "/addbot Haritsoppa.bot"

And a bunch of other UX improvements.

hehe

Currently I have the bots using a common chat file. This is used to read chat messages (to try best guess what topic is being discussed) and reply accordingly.

It'll take extra memory (who cares these days right with gigs of ram available?!) to extend this to be done on a per-bot basis.

Oh yeah nowadays memory is not a problem, at least for qw I think.

Electro I've always heard out there that it's very difficult to build a decent qw bot because of the limitations of the quakeC language.

Is that true?

luchten: yeah there's some truth in that, I'm using quite a few engine extensions which increase functionality.

But I hope you don't consider endowing the bot with trancendental quickness (for its head is of a most amazing thickness) in choosing a safe spot 'cheating' which you vowed to avoid. Though it would probably be quite annoying never being able to land a direct rocket on them, beyond a certain range (when they're engaged in a fight, prepared for dodging)... And unspeakably filthy stair-arsey-ness. But even with this ability I doubt they can be made to feint at the level of a human.


Is it a trifky problem due to subtleties like accounting for current velocity, when to avoid walls and corners, die to aggress, retreat to live, etc? I assume the basic geometry of it would be relatively easy, the destination of the (unintercepted-by a player)projectile would be available on the server at the same frame it's created, right? Then, if it's not possible to get behind cover, calculate the inverse of the optimum path to the explosion, accounting for current velocity. Take idealised case: bot is strafing directly toward the rocket desination. Is it better to decelerate-stop-rreverse or combine moving forward or backward whilst doing that (I think the latter)? In other words, how much of the inefficiency of not moving in what would be the best direction if there was instant acceleration, is offset by the speed boost one gets by adding a semi-coincident movement direction (before it gets resolved into a diagonal and falls back to 320 ups), and the distance one can cover while one would otherwise be decelerating-stopping-accelerating? Could you have the bot start avoiding in the very next frame?


Sorry I didn't mean to say I thought there wouldn't need to be any real time calculation, jkust that the optimum rate of rotation and therefore the shape of the 'optimum' curve for a given speed (and airborne time) can be a given, no doubt there are going to be some hard problems designing the confined movement. Regarding the minimum path deviation, this could be very undesirable - nearly a straight line alternating arcs at 77 Hz, how close will you tie it to what a person could perform? Taking corners and doing composite arcs to achieve approximate lines (at whatever level of approximation) seem to me (for whatt hat's worth ) like they'll be relatively easy to design. I expect taking runups and detours to gain speed to reduce time between announcing oneself aurally and visually is a pretty intractable problem, that must be prebuilt. I don't think anyone would care if the bot did cheaty forward rj, but I suspect all the important rjs would need to be prebuilt.

Very interesting! Not sure I understood it all ;p And a bot that never do any mistakes is kind of annoying. Maybe some rare function could be activated in a, let's say, 5% rate that would lead the bot not to the best movement. Does this make sense? (I usualy have non-sense ideas) =S