System32 Discusses AI and improving it.

[System32]

So you want the other guy to list their bot type in the binding?  And for your bot's AI to be able to read the other bot's binding?

Aside from the whole "a person might be driving", the next issue is how do you standardize bot types.

    #list.append( ("Generic Popup", "AdvancedOmni", { 'radius':1.2, 'nose': math.pi, 'bot':"Popup", 'Speed':"Fast", 'wep':"Top", 'topspeed': 12.0, 'turn': 20, 'weapons': (11, 12, 13, 14,) }) )
    #list.append( ("Generic ThirtySix", "AdvancedOmni", { 'radius':1.2, 'nose': math.pi, 'bot':"HS", 'Speed':"Slow", 'wep':"All", 'topspeed': 12.0, 'turn': 20, 'weapons': (11, 12, 13, 14,) }) )

Since today is type stuff without reading day in the americas, I'll link to the bindings.
 
Notice the addition of 'bot', 'speed' and 'wep' to the bindings? What, no? Well then read my posts.
 
Here is a description of these three additions:
 
'bot': The bot type. Features the 5 main bot types ("Rammer", "HS", "VS", "Popup", "SNS") and a value for other unusual or less used bot types like FS/poker hybrids and such ("Other"). This is vague for overlap (In DSL, Sheck spinners and HS overlap).
 
'speed': A series of five speeds: "Vslow", "Slow", "Medium", "Fast" and "Vfast". Comparisons of speed to prevent 123stw's example of bots circling retardedly.
 
'wep': A Judging of how the bot attacks.
 
"All": Damage caused everywhere, most HS and crawlers are examples.
 
"Top": Popups, TS and jugglers attack from the top, necessitating avoiding being out-wedged.
 
"Front": FS, most VS, Rammers and such attack frontally.
 
"Bottom": The robot can cause damage if an opponent is below. Flying guillotines and Hammers are examples.
 
"Side": Bot attacks from the side or attacks the sides. Side hammers and Trapping HS are examples.
 
 
The AI compares the bindings of the opponent and the bindings of itself, and assigns a strategy regarding it. (Slow HS with no weapons o the rear vs a fast Popup? popup goes for the rear, HS backs against a wall and charges if the popup shows a flank.)
 
Needless to say, there would be safeguards, like one to see if ANYTHING at all has happened recently.
 
Robo: There would be little standarisation at all, as the marker bindings are vague enough to be decided on the spot without vigorous testing. Consider Popup.py's timer which allows the bot to attack if it cannot find a chassis while something is in the smartzone. The AI would be tailored to the best matchup, and gradually devolve into the basic "charge and prey" AI.

[Badnik96]

aww, I was convinced this was an actual AI. dammit.

[Naryar]

Adaptive AI ?

Yeah, that's gonna be difficult. As said before, it's mostly the gigantically large amounts of code that run at the same time and all the functions that need to be calculated every second. Also, .py size is gonna be multiplied by ten.

Ever seen how an only mildly complex AI (FBSPlus) lags the game ? This will make the game lag to death.

Too bad though because this is an awesome idea.

[System32]

Adaptive AI ?

Yeah, that's gonna be difficult. As said before, it's mostly the gigantically large amounts of code that run at the same time and all the functions that need to be calculated every second. Also, .py size is gonna be multiplied by ten.

Ever seen how an only mildly complex AI (FBSPlus) lags the game ? This will make the game lag to death.

Too bad though because this is an awesome idea.

FBSplus constantly runs the large code though. Adaptive AI won't, as the desicions are mostly done at the start. It'll be as laggy as Snow.py at worst.

[Naryar]

So if the decisions are done at the start... what if the other adaptive AI is an hybrid, loses one weapon and starts acting like another bot type ?

Though it can probably be worth it to sacrifice real-time updates of the code.

[Enigm@]

So basically we went from "lets try and not make AI pushing bots with spinny things" to "lets try and make AI as humanly realistic as possible" ?
inb4SKYNET

[Clickbeetle]

But what do you do against a human opponent?  Human bots don't have bindings.
 

Ever seen how an only mildly complex AI (FBSPlus) lags the game ? This will make the game lag to death.

FBS.py and its derivatives only lag because they use a shorter tick interval than other AI (or in other words, they perform more operations per second).  I released a modified version a while ago with a slower (but still faster than normal) tick interval and it fixed the lag problems.  It's basically impossible to seriously lag the game because the .py is "too complex".
 

Just as an aside, I'm growing increasingly more skeptical of how Seism 13 actually functioned in BBEANS 5, as in why did it have to wait until post-match for it to realize that it had to change the position of its wedges? Also, how was it able to differentiate between being outwedged and simply entering the air from some other event? Would a random havok explosion sending the robot airborn influence its wedge position in the next match? If it did, would the wedge AI have to be manually reset, and isn't manually tinkering with the AI mid-round as not to gain/lose an advantage cheating? SO. MANY. QUESTIONS.

- It didn't wait until post-match to switch wedge configurations; if you watch the videos the wedges move as soon as another bot gets under it.
- It detects when it is out-wedged with a smart zone under the bot, so it is only triggered when a bot goes in the zone (which it will have to get under S13 in order to do).  Flying in the air by itself won't trigger it.
- The wedge AI automatically resets when it faces a new opponent.  It "knows" when it is facing a new opponent by counting the number of components on the other bot and seeing if it's different from its previous opponent.  In theory you could fool the AI with two different bots with the same number of components, but this would be pretty rare in the HW class.

[System32]

A Human opponent? I'll have to think about that.

[wakkydude]

Of course AI can and should be improved, but how easy would this be able to do on a bot-by-bot basis? Making an AI pack based around this idea for example would probably take ages.


No, don't worry about telling me I'm wrong, I've gotten used to that.

[Trovaner]

I've been hanging around the sidelines of this discussion just to see what people thought but I think its time to give some input.

    #list.append( ("Generic Popup", "AdvancedOmni", { 'radius':1.2, 'nose': math.pi, 'bot':"Popup", 'Speed':"Fast", 'wep':"Top", 'topspeed': 12.0, 'turn': 20, 'weapons': (11, 12, 13, 14,) }) )
    #list.append( ("Generic ThirtySix", "AdvancedOmni", { 'radius':1.2, 'nose': math.pi, 'bot':"HS", 'Speed':"Slow", 'wep':"All", 'topspeed': 12.0, 'turn': 20, 'weapons': (11, 12, 13, 14,) }) )

Making an AI that uses generalized bindings such as these wouldn't make the AI any smarter or more powerful, just easier to make. I've considered making something like this in the past but never got around to it (the plan was to use something like this for my Practice Garage so that it can auto AI more effectively).

As Click has already mentioned, we can't look at the opponent's bindings to check their bot type because human's don't need bindings. We also can't use the opponent's components to determine the best attack strategy because (1) we can't tell a wedge from a round extender, (2) we can't tell the difference between similar bot types such as a VS and a HS, and (3) we can't look directly at the opponent's .bot file because we don't know which files are loaded into the EXE. I'm sure many people have considered this before but those three issues are hard to work around.

One idea that I don't think has been mentioned would be to determine the AI's strategy based on a combination of guess-and-check and how the opponent is moving. It wouldn't provide the best course of action in all cases but it would allow the AI to "adapt" to its opponents. The biggest drawbacks would be the amount of coding necessary and the amount of processing that would need to be done per tick. Speed, turn speed, heading, direction, weight, and # of wheels are easy to get so if we keep an eye on them and keep track of when we receive the most damage (front, sides, underneath, above) then we could use that information to determine our best coarse of action. Saving collected data in a text file would also potentially improve performance in sequential fights.

[TeamXtreemer]

I've been hanging around the sidelines of this discussion just to see what people thought but I think its time to give some input.

    #list.append( ("Generic Popup", "AdvancedOmni", { 'radius':1.2, 'nose': math.pi, 'bot':"Popup", 'Speed':"Fast", 'wep':"Top", 'topspeed': 12.0, 'turn': 20, 'weapons': (11, 12, 13, 14,) }) )
    #list.append( ("Generic ThirtySix", "AdvancedOmni", { 'radius':1.2, 'nose': math.pi, 'bot':"HS", 'Speed':"Slow", 'wep':"All", 'topspeed': 12.0, 'turn': 20, 'weapons': (11, 12, 13, 14,) }) )

Making an AI that uses generalized bindings such as these wouldn't make the AI any smarter or more powerful, just easier to make. I've considered making something like this in the past but never got around to it (the plan was to use something like this for my Practice Garage so that it can auto AI more effectively).

As Click has already mentioned, we can't look at the opponent's bindings to check their bot type because human's don't need bindings. We also use the opponent's components to determine the best attack strategy because (1) we can't tell a wedge from a round extender, (2) we can't tell the difference between similar bot types such as a VS and a HS, and (3) we can't look directly at the opponent's .bot file because we don't know which files are loaded into the EXE. I'm sure many people have considered this before but there just isn't any way around those three issues.

One idea that I don't think has been mentioned would be to determine the AI's strategy based on a combination of guess-and-check and how the opponent is moving. It wouldn't provide the best course of action in all cases but it would allow the AI to "adapt" to its opponents. The biggest drawbacks would be the amount of coding necessary and the amount of processing that would need to be done per tick. Speed, turn speed, heading, direction, weight, and # of wheels are easy to get so if we keep an eye on them and keep track of when we receive the most damage (front, sides, underneath, above) then we could use that information to determine our best coarse of action. Saving collected data in a text file would also potentially improve performance in sequential fights.

Holy s**t it's Trovaner

*seizure*


In topic, why not try edit the 'math.pi?'
maybe other words such as 'N, S, E, W, NE, SE, NW, etc.' or 'F, B, L, R, DL (Diag Left) etc'.

[Trovaner]

I try to be here at least once a day... I just choose not to post everyday.

As for the the 'math.pi' replacement, just stick this in Bindings.py under the "def load(list):" line.

Code: [Select]

    SW, W, NW, N, NE, E, SE, S = map(lambda x: math.pi*x/4.0, range(-3,5))
This basically makes all the abbreviated cardinal and ordinal directions available for use as nose values instead of using radians. These will likely be a problem for you in the future so I'd recommend either learning radians or using the next replacement instead.

The botlab's heading arrow supports 20 different angles. Therefore SW, NW, NE, and SE don't exactly line up with any of the possible in-game angles. If you want everything to be the same, I would add something like this instead.

Code: [Select]

    for m in range(0,21):
        exec("ANGLE_%s = %s" %(m, m*math.pi/10.0))
This makes variables that look like this:
ANGLE_x --> where x is a value between 0 and 20 (inclusive).

The values go clockwise from the the default heading (UP/NORTH) but if you add a '-' before the variable they will go counter-clockwise. Adding 5 to x turns the nose 90 degrees. Just to give you the rough idea, here are the first 6:
ANGLE_0 = ANGLE_20 = 0 radians = 0 degrees = UP/NORTH = default angle
ANGLE_1 = -ANGLE_19 = PI/10 radians = 18 degrees
ANGLE_2 = -ANGLE_18 = PI/5 radians = 36 degrees
ANGLE_3 = -ANGLE_17 = 3PI/10 radians = 54 degrees
ANGLE_4 = -ANGLE_16 = 2PI/5 radians = 72 degrees
ANGLE_5 = -ANGLE_15 = PI/2 radians = 90 degrees = RIGHT/EAST

[warning]Using these instead of radians will cause problems for people that don't have this tweak (namely tournament hosts).
If you are using the ANGLE_x variables, you can convert them to radians by replacing the "ANGLE_" with "math.pi/10*".[/warning]

[TeamXtreemer]

I try to be here at least once a day... I just choose not to post everyday.

As for the the 'math.pi' replacement, just stick this in Bindings.py under the "def load(list):" line.

Code: [Select]

    SW, W, NW, N, NE, E, SE, S = map(lambda x: math.pi*x/4.0, range(-3,5))
This basically makes all the abbreviated cardinal and ordinal directions available for use as nose values instead of using radians. These will likely be a problem for you in the future so I'd recommend either learning radians or using the next replacement instead.

The botlab's heading arrow supports 20 different angles. Therefore SW, NW, NE, and SE don't exactly line up with any of the possible in-game angles. If you want everything to be the same, I would add something like this instead.

Code: [Select]

    for m in range(0,21):
        exec("ANGLE_%s = %s" %(m, m*math.pi/10.0))
This makes variables that look like this:
ANGLE_x --> where x is a value between 0 and 20 (inclusive).

The values go clockwise from the the default heading (UP/NORTH) but if you add a '-' before the variable they will go counter-clockwise. Adding 5 to x turns the nose 90 degrees. Just to give you the rough idea, here are the first 6:
ANGLE_0 = ANGLE_20 = 0 radians = 0 degrees = UP/NORTH = default angle
ANGLE_1 = -ANGLE_19 = PI/10 radians = 18 degrees
ANGLE_2 = -ANGLE_18 = PI/5 radians = 36 degrees
ANGLE_3 = -ANGLE_17 = 3PI/10 radians = 54 degrees
ANGLE_4 = -ANGLE_16 = 2PI/5 radians = 72 degrees
ANGLE_5 = -ANGLE_15 = PI/2 radians = 90 degrees = RIGHT/EAST

[warning]Using these instead of radians will cause problems for people that don't have this tweak (namely tournament hosts).
If you are using the ANGLE_x variables, you can convert them to radians by replacing the "ANGLE_" with "math.pi/10*".[/warning]

You should post, dude, all of the ledgends are dissapearing, and thanks for the reply, I'll be sure to use them when I get the chance,