Making RA2 AI smarter

[Reier]

ok so i have some questions regarding the ra2 AI cause it pisses me off.

I claim right here that I have no idea about AI or programming in general for the most part. I know how to basic AI with bindings, but I have never made a py or anything.
Anyway, everyone knows the ai in ra2 is ridiculously bad. But when i was watching meltybrain SnSs the other day I realized it wasn't so much the bot type that is so dominant - its the AI. Its homing ability exploits its opponent's lack of intelligence. Meltybrain can move and turn at the same time, but when fighting an ai opponent like omni, the omni bot tries to turn and face its opponent before charging, which it can't. Meltybrain removes its opponent's ability to advance.

Which got me thinking. When I fight a meltybrain or any kind of ai for that matter, I can obviously do much better than the ai can. So I made a list of things I do that I would assume that may be possible to replicate in programming.

1. NEVER STOP MOVING
anyone noticed how when 2 omni bots get on top of each other they just sit there? its like it thinks it occupies the same space so it just chills until the timer kicks in. humans would never do that. It can even get robots killed if they are being gut ripped to death but too stupid to move off their opponent. Is it possible to "override" the bindings or make a new py or something that prohibits this stupidity? and if it can't move forwards, go friggin backwards? is it possible to make the robot attempt to change its X-Z position as often as possible or something to force this? I really have no idea. 

2. Moving forward > aiming
aka the reason meltybrain is op. It happens on all pys, but is especially noticable vs meltybrain. Robots that are being flanked will 100% of the time try to face their opponent and THEN move forwards. Do both! not moving leaves you a sitting duck and will get you killed. Humans can move forwards and turn at the same time, can AI not?
2b. variable turn speed?
I know the in bindings you can change the bots turn speed from snail to warpspeed but it seems like it is LOCKED in that speed for all turns no matter what. is there a way to make it turn fast when it has to quickly 180 and slow when it just has to angle a few degrees? It seems like this would solve a lot of oversteering problems fast robots like rammers have.

3. Only reverse as far as is necessary
aka why KOTH arena is dumb. I feel like this wouldn't be necessary if #1 was implemented but just in case here it is. Ai getting out of immobility timer is laughably poor. once the timer starts it tries to back up at max speed for several seconds. If it can't move, it goes forward at max speed. Then it repeats. First, is there a way to set it so the robot judges its "get out of immobility" by its coordinates and not on a timer? This will help prevent many low-power immobilities. second, is there a way to make it move only as far as is required? I can't stand playing on the koth arena with ais because they just suicide off the edge at max speed as soon as the timer starts. Surely there is a way to fix this.

Like I said, I do not know much about AIing and everything I said may be impossible to do. I just thought this discussion could be helpful. I feel like if it is possible to change at least some of these problems ra2 could only be better off, especially in the tournament scene.


Anyway, I'll add more if I think of anything.
Please discuss.

[Pwnator]

The reason why it's so hard to implement the ideal AI is because as humans we make multiple minute decisions that are constructive to the whole battle plan. It's very tedious to implement multiple decision points with the proper thresholds, all arranged by urgency.

A gutripper would love to chill under a opponent when it has the opportunity to do so, but it's difficult to deduce when it's worth it to stay in a wedge lock or squirm out and flank. A hammer might wait until its arm is directly aligned towards the enemy chassis, or it decides to whack away at the fragile weapon systems. A popup facing against a wedgeless VS would actually love to take out the stabilizers before charging onto the chassis.

There are so many variables to take into account, that it would take weeks to code a .py for a single bot that's tailored to cover most of the scenarios it may face. I'm not saying it's impossible, but your time would actually be better spent honing your building skills rather than coding a program to make up for your bot's weaknesses.

[Reier]

yeah and I realize that it is impossible to make a formula that would cover everything. AI will never be as good as human players in this. But the reason I made that short list is I feel that even if just some of those factors were added it would improve the AI drastically, at least in theory.
Like the move forward > aiming for instance. Wouldn't it be possible to do something in a py that says "hey if this robot turns make it go forwards too" or something?

please bring any ideas you guys have,I really want to explore this. There has to be ways to improve this awful ai.

[Trovaner]

1. NEVER STOP MOVING
anyone noticed how when 2 omni bots get on top of each other they just sit there? its like it thinks it occupies the same space so it just chills until the timer kicks in. humans would never do that. It can even get robots killed if they are being gut ripped to death but too stupid to move off their opponent. Is it possible to "override" the bindings or make a new py or something that prohibits this stupidity? and if it can't move forwards, go friggin backwards? is it possible to make the robot attempt to change its X-Z position as often as possible or something to force this? I really have no idea. 

This is less of a problem with Omni and more of a problem with the fact that something like 99% of the AI.py files that are currently available to the public use the Engage tactic. With the exception of the MeltyBrain tactic, all of the other major tactics take speed into account so that this sort of lock up situation doesn't take place. The Engage tactic is good for bots that try to pin their opponent or bots that don't benefit from moving away from the opponent. That said, pinning tends to be hit and miss because all of the currently available AI.py files force the bot to back away as soon as the countdown starts if it starts before their opponent's timer (rather than attempting a mad dash at the last second). If we want to create a Engage tactic that doesn't lock up, we would need to somehow figure out a way of determining if the AI bot is currently in control or if it is stuck in a stalemate.

2. Moving forward > aiming
aka the reason meltybrain is op. It happens on all pys, but is especially noticable vs meltybrain. Robots that are being flanked will 100% of the time try to face their opponent and THEN move forwards. Do both! not moving leaves you a sitting duck and will get you killed. Humans can move forwards and turn at the same time, can AI not?

This is probably doable but it would be difficult to code in a way that would work well since it would only be effective in very specific situations and there isn't any easy way of figuring out some of the variables (like the opponent's radius). Turning quickly to face the enemy is usually better than getting flanked. If the opponent would reach you before you got out of the way, it is better to turn quick to face them (since the front usually has more protection and wouldn't expose your wheels as much). You would also need to figure out how far out you want the bot to go and what to do when there are hazards in the way.

2b. variable turn speed?
I know the in bindings you can change the bots turn speed from snail to warpspeed but it seems like it is LOCKED in that speed for all turns no matter what. is there a way to make it turn fast when it has to quickly 180 and slow when it just has to angle a few degrees? It seems like this would solve a lot of oversteering problems fast robots like rammers have.

You have two values in the Bindings of most AI for turning. One is called 'turn' (defaults to 60) and the other is called 'turnspeed' (defaults to 2.5). 'Turn' is the max analog value that you would like the bot to use (humans are limited to 100 but there isn't really a limit for the AI (however, setting it too high could be considered cheating)). The value that you give is used as a multiplier and the longer it takes to get up to speed, the higher this value will become (until the next tick would cause us to over steer). 'Turnspeed' is another multiplier that is used in calculating how quickly we should boost the 'turn' multiplier (once again, there is no limit to this value but you wouldn't want to set it too high because it would cause over steering if set too high). My point is neither of these values are used in a way that would cause the input to be linear and, if your AI is over steering a lot, you should probably hatweak your bindings.

3. Only reverse as far as is necessary
aka why KOTH arena is dumb. I feel like this wouldn't be necessary if #1 was implemented but just in case here it is. Ai getting out of immobility timer is laughably poor. once the timer starts it tries to back up at max speed for several seconds. If it can't move, it goes forward at max speed. Then it repeats. First, is there a way to set it so the robot judges its "get out of immobility" by its coordinates and not on a timer? This will help prevent many low-power immobilities. second, is there a way to make it move only as far as is required? I can't stand playing on the koth arena with ais because they just suicide off the edge at max speed as soon as the timer starts. Surely there is a way to fix this.

I concede that this could definitely be improved. Right now, the default behavior is based on a 2 second timer that doesn't work well for fast bots. That said, I'm not sure what the exact conditions are for the immobility counter so I'm not sure how I would code it.

[Resetti's Replicas]

Do we have capabilities to use rear weapons?  Maybe charging in backwards rather than making a cumbersome 180-turn in certain situations?

[Trovaner]

Do we have capabilities to use rear weapons?  Maybe charging in backwards rather than making a cumbersome 180-turn in certain situations?

IIRC, Click wrote a "ReverseRam" tactic for this purpose (used by BiDirRam.py). Otherwise, I believe there are a couple AI.py files that have built in handling for it but that usually results in the AI.py fighting for control of the bot since the tactic is trying to do something else.

[G.K.]

I think his most recent version was relatively comptent, check out DSL BBEANS AI or AI Essentials (I think)