When I was first starting to plan what my bot would be all about I remembered reading in some of the Strategy sub-pages that as we start out, we should try everything. This bot does just that. All in one big mess.
It uses all of these at once moving to the weighted average location of all of them. The weight of each method is based off a simple reward/punishment scheme such that it gives the most effective strategies the highest weight. The other strategies give a highly variable quality to it's movement. It's interesting to watch simply because it's movement is highly organic. It's not the best and definitely needs some tweaking but it's getting there. Mostly the biggest problem now is that ALL of it's movement strategies are somewhat broken. I'm amazed that it's not crippled.
Like the movement it uses these methods all at once finding the weighted average location of all of them. I think the pattern matcher is my best targeting method so far. The accuracy might actually improve if I made it only use this one method, but I wanted to make a bot that used everything, so I had to stick by my guns (pun intended).
This little piece started from StasticalSymbolicPatternMatching that quickly got off topic.
That's not a bad idea. It may be possible to create different movement profiles such that certain movement types (that do not lend well to pattern matching) can be plugged in. For instance, one could create an anti-antigrav targeting system where the bot takes a simplified antigrav system including the most commonly used variables for attraction/repulsion and as the bot observes its movement, it figures out what those variables are. The only issue I see with all of this, is that random movement will still be an issue because the bot won't generate the same random variables as his target. I certainly will take a look at your bot. If SingleTick got me this far, I can only imagine what I can learn from the tuned version. -- Ne
Oh, no, I caused a little confusion there. The Anti-xxx is *my* movement system. So you plug in the enemy's gun & avoid it (and therefore kick the crap out of it). Plugging in the enemy's movement is a *far* more difficult task, because you'd have to simulate all the variables the enemy takes into account for every tick until your bullet hits, including your own movement. That's why I said it was off topic ... -- Simonton
Ah, I see. Targeting is a precise function of a bot's movement whereas a bot's movement is a fuzzy function of several variables. Essentially you're still talking about targeting but it's virtual guns for you enemies targeting you. If that's the case it may be possible to include targeting "definitions" and avoid bullets based on what definitions the enemy is following. They would have to be evaluated based on the same way my GF gun determines accuracy of its virtual guns. You're suggesting to impliment special virtual guns for bots of xxx name. Wouldn't a really good wave surfer be able to accomplish the same thing? Although... not as easily or as accurately against those certain bots. -- Ne
Wave surfers do that very well against head-on & linear targeting as well as GF guns, but they can't predict PM guns very well. Be careful, you can't evaluate the enemy's VGs the same way you do your own. The only times you know where he shot are when you are hit or onBulletHitBullet?. Then you can evaluate your definition to see if he's following any of them. -- Simonton
Wouldn't it be simplier to adjust your own targeting techniques (in a massive VG array) so that you can use the same functions to target your enemy or calculate how your enemy targets you? Essentially VG array uses the majority of targeting techniques. It should be able to find the most accurate method being used and surf around them. The location of the bullet could be based on the most likely bullet trajectory and the distance that the bot revolves around the bullet would be based on the distance the second/third most likely angles are from the most likely. This should ensure that the three most likely angles are avoided. Again though, you could still plug your problem bots' gun code into the array, use it yourself against other bots, and avoid it almost every time when they use it. I'm definitely going to have to figure out bullet dodging and minimum risk movement. I think that's all my bot is lacking at the moment. It's going to take quite a bit of work to recode my guns to work both ways... but it will definitely be worth it. Super-duper-wave-surfing Here I come! -- Ne
You could certainly simulate enemy targeting algorithms, try and figure out which one is closest to what he's doing, and surf the angles generated by your simulated algorithms. (I think I actually made a poor attempt at this long before Dookious was a contender.) However, I'd say it's extremely likely that you will get much, much better results with the traditional method of surfing, in which you are dodging what angles the enemy is aiming at (updated when he hits you) in different situations. In a way, it's almost like a more abstract way of doing exactly the kind of thing you're talking about.
There is also CurveFlattening, in which you also (or instead) update your stats when you don't get hit, to simulate the enemy's learning process and randomize your movement even when you're not getting hit. Many expert movers turn on CurveFlattening if they are getting hit a lot, but it can really blow your scores against lesser bots, since you're kind of "corrupting" your dodging stats. (Way off topic now, maybe we should cut/paste this discussion elsewhere. =))
-- Voidious
Cut and pasted. You're right, that was getting unruly. I figured since I don't have my own subpage for movement (and I can't think of a reason why I would need one), I figured I'd just move the movement discussion here.
In any case, I see what you're saying. I've got to make my bot be able to dodge bullets fired by both smart and stupid bots. The only bots that curve flattening seemed like an obvious defense against was those that used AntiWaveSurfing? targeting. Obviously these bots essentially have GF and inverse GF targeting strategies. The idea behind CurveFlattening seemed to be to keep such bots guessing. In other words, you're suggesting that CurveFlatening? be another movement mode to incorporate. If that's the case, then it is certainly crucial that I figure out a way to discover the best movement profile weights based on all the bots combined as well as the current target and the bots that are targeting me. The number of beasts to add to the Chimera is increasing... as is their complexity. I was lucky to get this far. Seems as if my aspirations are soon turning into a to-do-list. @.@ -- Ne
If you'd like to see an example of using the same code for tracking for your own VGs as well as tracking your enemy's, I will again point you to LifelongObsession (if you can plug your enemy's code, you should be able to plug your own, right? actually, you just create another instance of the same class). When I combined that technique into my own wave surfing, it only helped a very little bit in the rumble. BUT, I still think there is potential. -- Simonton
Actually, I'd kind of look at it the opposite way - CurveFlattening could be useful against any learning gun. Theoretically, if your movement and their gun were segmented exactly the same, you could never get hit if you just had CurveFlattening stats. With regular surfing against a non-learning gun (say, LinearTargeting or HOT), once you learn the angle the enemy shoots at in a situation, you will dodge it forever; against a long-term learning gun, you will dodge them for a long time; against a fast learning (AntiSurfer, basically) gun, they will quickly adapt and start hitting you again unless you try and stay ahead of them with CurveFlattening.
As it turns out, at least in my experience, you're far better off just having quick adapting surfing against the great majority of tanks, even most with learning guns. If your surfing is correctly figuring out where it's safe to be, adding in CurveFlattening will juts put you back in harm's way. But against a top notch gun, it can often make a huge difference - I've had versions of Dookious that would get 54% against Ascendant with normal movement, but 66% if I hard-coded CurveFlattening to be on (and this is averaged over 50 or 100 battles). But I'd be insane to release it like that, because it would kill the rating, and he's in the same boat :) (Oh, and just FYI, I've never found the inverse GF strategy of AntiSurferTargeting to work well at all. Surfers are just hard to hit!)
-- Voidious
In other words, a WaveSurfing/BulletDodging? movement strategy is probably best although a good somewhat random movement is probably more simple to implement. Unfortunately for me, none of my movement strategies seem to work well at all. I'm trying to tie them to my GF gun so that I can figure out how far I should be from my target. I hoping to turn my own guns back on myself and again, using a weighting system to determine which virtual bullet to dodge and how far away I should attempt to be from it. The real problem lies in the resources required for running my guns. Because they hog memory (and I think I've got leaks) I only use them a few ticks before I can fire my gun. Otherwise, I just keep my gun aimed right at the target. I can't imagine running those complex algorithms every time a bot fires their gun, that's just insane. I would have to do some serious optimization in order for that to be feasible. -- Ne
Hey, don't feel bad Ne, I seem to have a bad habit of implimenting the slowest and most inefficient versions of whatever I create. Take my best bot, Seraphim for instance, its almost classifiable as a slowbot, though it uses a 'theoretically' faster method of targeting and dodging things. Then again the movement is also more broken then a pane of glass dropped from orbit. --Chase-san
Heh, it probably doesn't help that my bot is extremely bloated and probably full of vestigial functions that should have been pruned by now. Wouldn't a pane of glass vaporize as it enters the atmosphere? Wow, that's some narly movement. The main problem that I seem to have with my movement now is that it tends to get stuck near the walls and vibrate. I think this has to do with my buggy implementation of antigravity movement. I've actually got it set to increase the weight of the agrav movement based on its proximity to other bots and to the walls. Once I get that little bug fixed, I'm going to attempt some wave surfing and bullet dodging. Because I'm also trying to make the Chimera a team bot, I could work in a system for dodging bullets that does not depend of waves. Essentially it will contain a bullets power, speed, origin, angle, and suggested distance to keep from it. My enemy waves will feed that data and my own team bots will feed other bots the info on their bullets so that I can remove my LineOfSight FirePower? muting or else only use it when other teammates have no chance of dodging. So far, I haven't focused on the team strategy mainly because I'm still tweaking the individual aspects of the bot. I've got to make it work well in OneOnOne and Melee battles before it can be competitive in Team battles. I'm not too bad in Melee and I'm actually fairly bad in OneOnOne. I've got a lot of work to do and this is a SpareTime? bot. -- Ne
I can't believe this but I actually released 1.0 with COMPLETELY faulty aiming system. It was supposed to be choosing the firing angle based on how much each targeting method "pulled" the gun towards it. The more accurate the targeting method, the higher it's weight. However, I had the weight of EVERY method adding up to the same thing so that every weight was equal... and very high. This made my gun very inaccurate, especially at long distances. I didn't notice because many of the most predictable bots (like spinbot and walls) tend to have several targeting methods arriving at the same (or very close) conclusions. I can't believe I did something so silly. In any case, the bot should perform much better now... hopefully. I also tweaked the movement... mainly the AntiGravity movement which seemed to get the bot stuck near the walls. I actually had the walls set as attractive forces... but didn't realize it because my GoTo? method makes sure that I don't get any closer than 50px.. and movement strategies are punished for requesting locations too close to the walls and for making the bot stand still for too long. Damn these multiple redundant features... things are broken but I just don't know what because the rest makes up it! @.@ --Ne
In any case, I'm suprised I was doing so well. However, what I'm most glad about is the fact that my specialization index is WAY down. Before it was 25.5 and now it's 6.6. My rank only jumped 10places... my rating only jumped 18 points. I think my greatest accomplishment is getting that specialization index down. I wanted this bot to do pretty well against most bots. I'm on my way. I think now that I've got the targeting bugs fixed, I might focus on the movement (which is where I know I need the most improvement)... but targeting is just so much fun. I've got at least two more GF guns I want to add to my array (One that segments on lateral velocity and one that segments on both distance and lateral velocity). I'm thinking that having multiple GF guns (when combined with the VG array picking the best gun) that the less segmented guns which tend to learn faster but be more inaccurate can start getting the hits in while the more highly factored guns gather information. --Ne
Oddly, my OneOnOne game has seriously suffered because of the last update... I can't imagine why. And my specialization index has skyrocketed up into the triple digits! That's really strange. It has to be my movement. Now I'm confused, those bugs helped my performance in OneOnOne battles but hurt my performance in Melee battles. That's very confusing. --Ne
If you check your results, you see quite some 'strange' results. I can't imagine Chimera would score only 68% against ad.last.Bottom for example. Seems that a client has been running that did not like your bot. Maybe your bot is using 'setAllColors?()' or so, an older client (1.0.7) can not handle that. It will correct itself, but that can take quite some time (and I am testing teambattles right now). -- GrubbmGait
You're right. Looking over some of the supposed ProblemBots I ran a few battles of my own to see what the problem was. For instance nexus.Prototype_1.0 is a RamBot that I cream every time... but for some reason I score a 22.6 against. Something just ain't right. I'm not so worried now... Still... the results are skewed. That's just not nice. -- Ne
I'm running into an interesting problem now... I'm trying to add the ability to save data files to this beast. I managed to use Kawigi's compressed read/write code. I am reading and writing bot objects easy. However, I know that where I to upload this into the rumble I would need a way to delete data files of the weaker bots. I could easily write a function that figures out who the weakest bot is... but I can't figure out two things: how to load every bot that is stored in the data file for comparison, and how to delete data files. I thought about making another file that contains only the data needed for the comparison that is essentially an index for all the data files... but I can't seem to get that to work. It would be relatively simple for me to make it where the bots aren't written to file when the quota is full... but that's not what I want to do. Any suggestions? I can't seem to find any documentation on the wiki about deleting data files. -- Ne
Dookious saves gun data on its opponents and deletes a data file randomly when it's near quota (I know, how sophisticated!). Here's the code:
![[Home]](/images/RoboWiki.png)
long quotaAvailable = robot.getDataQuotaAvailable();
while (quotaAvailable < 2500) {
File[] robotFiles = robot.getDataDirectory().listFiles();
int randFileIndex =
Math.min((int)(Math.random() * robotFiles.length),
robotFiles.length - 1);
quotaAvailable += robotFiles[randFileIndex].length();
robotFiles[randFileIndex].delete();
}
Frankly, I didn't see a simple way to really figure out who I should keep the gun data for, so I just delete randomly. I can fit about 250 bots in my 200 kb (using WikiTargeting style and writing straight binary) and I don't save on opponents where the AntiSurfer gun is much better, so I figure I've still got at the very least a 50% chance of having data on an enemy I've faced before. But it certainly could be helpful to use some actual logic to decide which ones you delete.
-- Voidious
I may just resort to using that instead... because I would imagine loading every single bot into a hashtable in order to compare might become more than a little computationally intensive... and after a certain number of battles, this would result in slowing down drastically at the end of the 1st round of every battle (to the point of possibly throwing errors). Your solution is certainly much more elegant. I like the idea of not saving data on bots that follow certain profiles. For instance, there is absolutely no reason to save data on any of the sample bots... or any other bot that can be hit with high probability with the more simple targeting methods. So perhaps I could work in a function that does just that, does not save data on bots that are exceptionally easy to hit (a preimptive deletion if you will). Thanks! -- Ne
On another note, my ratings seem to be droping VERY quickly. I can't imagine why... unless a slew of new (and good) bots have been introduced in the last week. I wonder if this has anything to do with the newest version of robocode and it's compatability with the rumble. -- Ne
I started my client last night, but it uses version 1.1. I have not monitored your rating, what means "VERY quickly"? New good bots won't effect your rating noticeable, it just drops when your score vs new bots is lower than expected. Your rating gets relatively stable at about 1200 battles, how many battles were fought up to the drop? --Krabb
I fought somewhere around 2000+ battles. I set my client (running 1.1.3) and it ran for a good three days straight. After being gone for a week, I come back to see my bot has gone from a rank of 70 (momentum of 2) to a rank of 109 (momentum of -39)! I can't imagine that my bot suddenly got really bad out of nowhere. This version of the bot is not saving files yet, so there couldn't be any performance issues that build up over time. I know that I occasionally get disabled in 1.3 for array out of bounds exceptions. Other than that, I can't think of anything else. As you can imagine, I'm quite confused. I would like to figure out what's going on. If someone is running a client with a version that has my bot performing badly, I would like to test my bot in that version so that this doesn't keep happening. -- Ne
Well, this is actually a "feature" of Java, something you just need to know about to make use of correctly. If you want to make a new copy of an object but have separate objects afterwards, the convention is to use object.clone() to return a new instance that is identical to the original. An object variable is actually a reference to an object, not an object in and of itself. So (like you said) obj1 = obj2 = obj3 = new Object() will set those 3 objects to the same value: a pointer to a certain object in memory. If you later made all three of those Object references point to other objects, that old unreferenced Object would be picked up by the garbage collector later on. All of this can be useful if you know to use it correctly, but painful if you don't (as you've just found out). (For what it's worth, I think we've all made this mistake at some point - at least I have.) -- Voidious
I always use (at least I think and hope so) the setLocation method of a Point2D, I will scan through my code though, you'll never know. -- GrubbmGait
I can see how that would be a useful feature. I should have realized that using that method connected things instead of copying data. I use the same robot tracking method as SnippetBot if I'm not mistaken and somehow the target object seems to stay right in sync with the data in the hashtable. I just hope that similar mistakes are not sprinkled through the rest of my code. On the upside, this newest version is doing very well, the ability to save data between battles is super helpful. I really need to learn how to chop bots up and just program better. This monster is starting to be a handful... all in one file. In any case, thanks for all the help, I REALLY should have gotten on here sooner... perhaps then it wouldn't have taken me 3 years to make a decent bot! -- Ne