gametechmods
Robot Arena => Discussion => Topic started by: System32 on November 26, 2011, 04:52:16 PM
-
Over the years, AI has been a major breaker for immersion. With exeption of some games, AI within games across all platforms has been retarded at best. In RA2, this has been noticable with the prelevance of AI that seems to boxrush constantly and win. Gigafrost has made an attept to curb this, with the plow AI, which attacks from the side instead of W+Spacebar attacks. It took me a while to think about why this is so effective, but I've figured it out. AI in RA2 is effected by at least two factors: 1) No risk management. 2) Small arenas compared to real life counterparts. I will explain these factors and solutions in this essay.
The first factor is there are no risk management AI's. The most common AI cares less about how healthy the bot is, and more about how healthy the opponent is. This is unrealistic. Noy only this, AI where it would be more effective to retreat, regain speed for weapons and attack again don't, because the AI doesn't have this ability coded.
http://www.youtube.com/watch?v=lyytZzWrPs4# (http://www.youtube.com/watch?v=lyytZzWrPs4#)
Note how Both bots retreat after decent hits and attack when an opponent exposes themselves. If this was an RA2 match, both bots would have forgotten that their weapons exist. All bots in RA2 are rammers with spinny things attached. There have been some advancements in planning for AI. Madiba's Arrowhead.py allows for a retreat whenever the robot is underneath an opponent (A bad place to be) and click's TrueOmniRam.py allows for HS and VS to retreat and spin up their weapons for more effective and bigger hits. This is the beginnings of creating AI that put themselves before the outcomes of the matches.
The second factor in poor AI in RA2 is the lack of large arenas. Octagon, Combat arena and the BBEANS arena's are entirely too small for robots larger than LW's to have battles where non-boxrush AI win.
http://www.youtube.com/watch?feature=player_detailpage&v=ntVtGYfFmtE#t=338s (http://www.youtube.com/watch?feature=player_detailpage&v=ntVtGYfFmtE#t=338s)
Compare the Robot wars arena in proportion to its HW's. Then look at Stock and DSL HW's compared to the Combat Arena. See the difference in proportion? I do. Larger arenas mean holding W and winning is less common, and arenas such as the Starcore official and BBEANS 5+6 arenas are making it so that boxrushing is less noticable.
In conclusion, Boxrushing is currently the most effective strategy in RA2 for AI and humans alike. Only when there is a greater variation in the intelligence of AI in self preservation and larger arenas that prevent box rushing will the AI of RA2 itself improve.
tl;dr read last paragraph.
-
so are you proposing to make a new .py that makes more variable in the strategy of AI battles ? Because yes, boxrushing does seem to be the most effective way of winning. (which makes watching matches quite boring)
-
Nice observations, and very true. Makes me want to rethink the .py I use for my VS.
Thanks for that :)
-
Nice observations, and very true. Makes me want to rethink the .py I use for my VS.
Thanks for that :)
The sad thing is that not many bots use it. it's pretty compatibe with all Omni.py bots.
-
also where do you find trueomniram.py and arrowhead.py ?
-
also where do you find trueomniram.py and arrowhead.py ?
BBeans AI pack.
-
There are lots of fancy AI .py's for making 'smarter' AI (the one that comes to mind is my SpinupOmni.py, which actually measures RPM of spinning weapons and doesn't attack until the weapon is up to speed).
The big problem is, most people only have a very basic understanding of AI, or none at all, and they leave the AI'ing up to the host of whatever tournament they're entering. The host, burdened with dozens of bots to AI, doesn't want to spend time tweaking every one to its optimum strategy, and usually ends up slapping Omni.py on every one they can and calling it good. (And I'm not accusing anyone of anything here; I am guilty of this as well.)
The other big problem is that the AI can effectively only move straight toward the opponent or straight away from them. Maneuvering to the sides, avoidance tactics, waiting for an opening, all those would be ridiculously complicated and would likely backfire as often as they succeeded. (Just try maneuvering around to Neglected Waterbug's side and see how hard it is... now imagine telling an AI to do that.) Plus there's the fact that you would want different tactics for different opponents--sneaky maneuvering for wedges, and box-rushing for spinners, and there is simply no way for an AI to identify a bot's type.
I'm not saying it's impossible to make better AI, but no matter how advanced it gets, it will never be as smart as a human driver.
-
The best AI is the one that
1. Moves toward enemy bot
2. Attacks
Why? Because it is consistent.
Hard code AI is bout to be stupid because they can't adopt to enemy bot or learn. You make it smarter 1% of the times and it becomes ridiculously stupid 99% of the times. All advance retreat/maneuver AI tactic is dumb because you are not ensure to have the fastest bot in the game. Up against a faster bot your bot will just keep retreating and getting killed. Up against HS/SnS/FSS and all the flanking is worthless. A real person can easily tell what the enemy is and adopt accordingly. AI by contrast can't.
Likewise, all battery conservation/wait for weapon to spin tactic sucks for the same reason. Better consistently deal damage for the critical first 40 seconds then any hiccups in the AI. The "smartest" AI would be something like popup.py because popup can actually afford to wait for the chassis before firing 99% of the time.
-
While I agree in principle that smarter AI would tend to emulate "realistic" combat robotics more accurately, this is pretty much a self-evident truth. At this point, it's pretty obvious that human driving is better than AI driving because humans have the ability to adjust tactics and strategies on the fly as they see fit. In itself, AI isn't realistic al all because no real combat robot relys entirely on AI when fighting. So, in order to emulate a real-life situation, you are correct to say that AI would have to emulate a human pilot as closely as possible.
But, as any scientist studying AI will tell you, this is far easier said than done. To my knowledge, the only place where human-level AI exists is in the mythos of a science-fiction universe. How then can you realistically suggest that we develop our extremely rudimentary AI system to fictional levels? It simply can't be done.
Also, I don't see how that first video you provided shows an example of "risk management" AI at all. The HS simply recoils after every hit, leaving itself open, and the drum can't immediately attack because the forces created by its weapon destabilize it if it turns too fast. Other than that, both bots are either entirely on the attack ("rammers with spinny things attached") or allowing their weaponry to spin up (as TrueOmniRam.py allows).
I also disagree with you regarding bigger arenas limiting the effectiveness of box-rushing and the benefits of self-preservation, but I'm losing coherency (very tired) so I'll save those discussions for later.
-
123 + click: See my point on arena size for a secondary fix for your points.
Also, I'd like to state there is a third, final factor, but that one will need a discussion all on it's own due to the subject it entails.
Robo: You are correct. There are better examples out there to show risk management, I'll admit.
-
No, it doesn't matter if you use an huge arena, even infinite arena. Advance AI fails because it cannot adopt base on which bot it's fighting against, it fails the moment it isn't in their ideal conditions. You can't "retreat and flank" a bot faster than you, or a HS/SnS/FSS. Having that AI in those matchup almost ensures lose. Having 2 people using those AI and we see circling for the whole match. Real player will say to themselves, screw this, I can do X because enemy bot type is Y employing tactic Z. That is what's beyond the python AI.
That's why the "move toward bot and attack" tactic is the best, because it works best "on average" against all existing bot types. Until an AI exist that can tell the enemy bot type and analyze enemy bot tactics (aka philosophically impossible to hard code), this is not going to change. This is why even rams uses omni.py or pusher.py instead of anything fancy.
This isn't the only game when I play with AI, and the best tactic for all those games is still "rush to maximum range". Anything "smarter" will result in it not functioning outside it's comfort zone. A real person would spot those holes and just abuse the heck out of it.
-
No, it doesn't matter if you use an huge arena, even infinite arena. Advance AI fails because it cannot adopt base on which bot it's fighting against, it fails the moment it isn't in their ideal conditions.
Correct. Large arenas abuse the comfort zone for "press W, hold space, Win matches" AI. Small arenas ruin Complex AI.
You can't "retreat and flank" a bot faster than you, or a HS/SnS/FSS. Having that AI in those matchup almost ensures lose. Having 2 people using those AI and we see circling for the whole match. Real player will say to themselves, screw this, I can do X because enemy bot type is Y employing tactic Z. That is what's beyond the python AI.
Correct. The Speeds of the Robots will be addressed in a later topic. The AI, like all AI, Only go on what they know. What do they know about the opponent? Flipper AI know they aren't invertible. That's it. Humans, on the otherhand, learn more and more about the opponent while playing, they'll know not to pointlessly zip about with a faster opponent, and be patient, not to rush headlong into powerful flippers and so on. If we added a small string to an AI, that allows for one bot to learn the bot type of another, we could start to see more and more complex AI by gradual inclusion of strings labeling other details. These values wouldn't be needed for the bot, but based on trust of the AIer. A Popup will know if they are fighing a VS or a HS, A Rammer will know the difference between a Popup and a Hammer.
Alternatively, these values would not be hardcoded in, but adjustments to the tactics could be changed Seism 16 style.
That's why the "move toward bot and attack" tactic is the best, because it works best "on average" against all existing bot types. Until an AI exist that can tell the enemy bot type and analyze enemy bot tactics (aka philosophically impossible to hard code), this is not going to change. This is why even rams uses omni.py or pusher.py instead of anything fancy.
I've stated my solutions above
This isn't the only game when I play with AI, and the best tactic for all those games is still "rush to maximum range". Anything "smarter" will result in it not functioning outside it's comfort zone. A real person would spot those holes and just abuse the heck out of it.
Well you play games with poor AI then. TF2's bots, for all their stupidity, actually hold back and wait for pushes and can retreat as well.
-
Well that's where you confusion lies. You assume identifying a bot takes a tiny string. This isn't a game with predefined units, there are no key to identify anything. Therefore it's actually impossible for an AI to identify bot types accurately, if at all. That is why the "cat vs dog" problem was such a big issue in earlier AI until development of self learning systems.
If you think it's so easy, then write the logical algorithm for it. You don't need to know any programming language to write out the logical commands that can identify a HS from a VS from a Gutripper.
This isn't the only game when I play with AI, and the best tactic for all those games is still "rush to maximum range". Anything "smarter" will result in it not functioning outside it's comfort zone. A real person would spot those holes and just abuse the heck out of it.
Well you play games with poor AI then. TF2's bots, for all their stupidity, actually hold back and wait for pushes and can retreat as well.
Yeah and like all timed AI gets abused hard once the player figure out the hole in it.
-
If you think it's so easy, then write the logical algorithm for it. You don't need to know any programming language to write out the logical commands that can identify a HS from a VS from a Gutripper.
*Sigh* "If you think it's so easy, YOU run the country/build a rocket/cure cancer/bring would peace/something stupid."
#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,) }) )
Basic idea of how the bindings will look. There would be an edit to the Tactics.py or alternatively, new tactics hard coded into the AI itself. flipper.py looks into opposing files.
I'm not a coder in python, and my main attepts involve butchering code and shoving it together like a goddamn ork while screaming "WAAGH!", But' I'm farly certian such an AI can be done. I'm not looking into a 100% human AI, just a little more complex than what we have.
-
Nobody is telling you to write codes. Just provide the logical framework to identify 1 type of bot from another.
In short, if you can't see a picture of a bot, what kind of questions would you ask about the bot to identify it.
-
I didn't read the thread after the first post so forgive me if this has been mentioned.
The AI is smarter in a sense that there is microscopic reaction time compared to that of a human. IRL, a bot like NWB could make a mistake and you would be able to flank it. However in RA2, NWB knows exactly what your robot is doing the second it is doing it, and a well tuned AI (even Omni) will track the bot down with no mistakes.
-
Nobody is telling you to write codes. Just provide the logical framework to identify 1 type of bot from another.
In short, if you can't see a picture of a bot, what kind of questions would you ask about the bot to identify it.
Did so with the bindings. look.
-
Nobody is telling you to write codes. Just provide the logical framework to identify 1 type of bot from another.
In short, if you can't see a picture of a bot, what kind of questions would you ask about the bot to identify it.
Did so with the bindings. look.
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.
-
Building on 123's point, can you tell me the difference between these two bots, just by looking at their AI lines?
1) list.append(("----","Omni",{'invertible':True,'nose':math.pi/2,'range':30,'radius':0.1,'topspeed':99,'throttle':130,'weapons':(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30)}))
2) list.append(("----","Omni",{'topspeed':99,'throttle':130,'radius':0.1,'range':99,'weapons':(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23)}))
Besides some very rudimentary stuff (# of weapons, nose orientation), it's impossible to tell that these two bots rely on completely different strategies to defeat their opponents. So, an AI, seeing only "Omni.py" will adapt how? Will it know that the first bot is completely different than the second? By the way, these are bindings lifted straight out of Starcore v4.0. The first robot is Spin Doctor, the second is NWB, but there is no way you would have known that because there are no discernable markers in the AI that would tell anyone the difference in approach a "smart" AI would need to take in order to gain a tactical advantage.
While the idea of looking for markers is good in theory, it's a nightmare in practice, because it requires a complete standardization and codification of all types of AI in order for the proposed "AdvancedOmni.py" to even have a hope of functioning. It would require all rammers to be AI'ed with a Rammer.py, all gut-rippers with a gut-ripper.py, all spinners with a spinner.py, etc, etc, just so advanced AI's can see this and devise tactics accordingly.
And what if you have two advanced AI bots fighting one another, like a pair of rammers? Surely, the best tactic for rammers is to flank and attack the hopefully unguarded sides, so both rammers would theoretically just try to outflank one another, leading to a stalemate. I'd be willing to argue that not attacking one another for the duration of the match is even more unrealistic than charging headlong into one another. And what if one rammer is slower than the other? Getting into a flanking war, as tactics would dictate, means death by stupidity for the less fleet bot as it would inevitably be outflanked. As humans, we can see this, and devise a strategy to compensate in an instant (here, having the slower rammer taking a defensive stance as to avoid being out-flanked), and continue to devise strategies and counter strategies ad infinitum. Hard coded AI (with a finite number of coded tactics) can't do this, so you're always going to wind up in situations where you either a) smash straight into each other like you would have anyways or b) enter a tactical stalemate since neither competitor is smart enough to devise new tactics on its own.
I'm not saying that having "advanced" AI is a bad idea, but I am saying that it won't work within the framework of RA2. We'd all like our bots to behave more intelligently in tournaments, but it's worth putting into perspective that this game has existed for the better part of a decade now, and we've only ever seen one AI with the capacity of altering a bots strategy (Seism 13 in BBEANS). Even then, this was no more than "if A) happens, then fire B)," it was highly specialized and written for use with that one specific bot, this adjustment had to be made post-match, and it didn't actually alter the tactics that the bot used. It's also worth noting that some very smart and code savvy guys have spent heaps and heaps of time playing with the AI code in RA2, and have yet to produce more than routines that have bots function like "rammers with spinny things attached." If it was really practically do-able, don't you think that someone would have pounded out the framework to something by now? I mean, it's not as if nobody's ever thought of having complex AI before.
---
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.
-
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.
If you looked closely, there's a seemingly useless text file of some sort in the main folder or the AI folder (I forgot which). Python can overwrite/concatenate stuff into a file and can read from that said file (although I have no idea how as I haven't learned Python yet). I'm guessing the .py launches itself every match so I'm guessing the file contains the current state of the wedges and an indicator on whether it has been outwedged in the previous match or not.
Also, I think the AI does manipulate the file mid-match when it's outwedged, but that doesn't matter for the remainder of the round because the .py only reads the file at the start of every match.
-
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.
-
aww, I was convinced this was an actual AI. dammit.
-
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.
-
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.
-
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.
-
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
-
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.
-
A Human opponent? I'll have to think about that.
-
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.
-
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.
-
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'.
-
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.
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.
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]
-
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.
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.
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,