Talk:XanderCat

Congrats on breaking the 50% barrier. Seems that you have the planning of your bot on scheme, now it's just the translation into the right code. One small remark: You don't have to have 'zillions of versions' present in the rumble, the details of older versions still are available when not in the participants list anymore. Comparisons between two versions are quite easy to do like [1] . Just click on your bot in the rankings, then the details and a few older versions are shown. Good luck with your further development! --GrubbmGait 08:37, 25 May 2011 (UTC)

Thanks GrubbmGait, though I'm not sure how much praise I deserve for being officially average. :-P I'm trying out a slightly revised version today, version 2.1. No major component changes, but it modifies the bullet firing parameters, driving parameters, some segmentation parameters, and has improved gun selection. Skotty 20:43, 25 May 2011 (UTC)

Version 3.1

Interesting results for version 3.1. No real change in rank from 3.0, but using an entirely new drive. I've done away with the borrowed wave surfing drive from BasicGFSurfer and replaced it with a drive of my own design.

Despite the new wave surfing drive (which I will call a Stat Drive) which I crafted almost entirely from scratch, I think it shares a lot in common with other wave surfing drives. It's just naturally where you end up when working out the best way to drive. I really haven't tried to tweak the segmentation yet, so I think it can be further improved with a few parameter changes.

Here is what my new drive does (you will likely see a lot in common with other drive strategies out there):

• Segmentation - Much like other wave surfing drives, my Stat Drive supports segmentation. I can't remember what it is actually segmenting on right now (don't have the code in front of me at the moment). I'll add that detail later. It is very easy to change the segmentation parameters. The Stat Drive relies on a seperate component to determine the segment or combination of segments, and the segmenters can be swapped in and out easily.
• Tracking danger - Each segment has a fixed number of "buckets" or "bins" that represent the danger at a particular "factor", where a factor represents an angular offset of the robot from an original bearing of the bullet wave origin to the robot at the time the bullet was fired. When a particular factor is determined to be more dangerous, a value is added to the corresponding bin or bins around that factor. Initially when I wanted to add danger, I just added to one bin. One thing I did steal from from the BasicGFSurfer wave surfing drive was the manner of adding danger to all the bins, trailing off sharply from the most dangerous bin. I don't know why I didn't think to do this initially. Once my eyes glanced over it, it was obvious it was what I should have been doing from the start.
• Bullet Hits - The most dangerous of events -- actually getting hit by a bullet. When hit by a bullet, the Stat Drive records danger of a certain amount (lets say a value represented by the variable d) to the matching bin of corresponding segment. One tenth that amount (d/10) is currently added to all other segments, though this is just experimental; I may modify or remove that effect as I tune it a bit more.
• Wave Hits - When a wave hits (but not necessarily a bullet hit), the Stat Drive currently records one fifth the amount of danger (d/5) for the matching bin of the corresponding segment. Thea idea being that the opponents gun, likely being a "Guess Factor" gun, might be more likely to aim for that bin next time, so lets try to avoid it. This also probably needs some fine tuning. Part of the same experiment as with bullet hits, adding one tenth of that amount (d/50) is added to all other segments.
• Wall Avoidance - While I wrote it from scratch myself, wall avoidance right now is doing pretty much the exact same thing as the "wall stick" approach. I have some ideas that would be fancier, but the "wall stick" approach works for now.
• Rolling danger - Rolling danger is the idea of removing danger previously added from bullets or waves that are over a certain age. The Stat Drive is not doing this right now, but I'm planning on experimenting with the idea.
• Figuring out where it can get to - One of the first steps to avoiding a bullet wave is determining how far you can go in each orbital direction before the bullet hits. At first I used some crude approaches to this with the Stat Drive, but they just won't cut it if I want to be really competitive. I now have it predict our position into the future, taking pretty much everything into account (turn rates, acceleration/deceleration rates, wall smoothing, etc) to make the prediction as accurate as possible.
• Figuring out where to go - once we know how far we can go, we have to decide where in that range we want to go. I'm experimenting with a few approaches. For now, it looks for the bin with the lowest value and heads there.
• Figuring out how to get there - Once we know where we want to go, we have to figure out how to get there. This seemed simple enough, but one problem I ran into was overshooting the target and being in the wrong place when the bullet arrives. This problem turned out to be significant in my testing. So I had to do additional work to ensure that if I will reach my target before the wave hits, I slow down before getting there so I land right on target. This sounds easier than it actually was to implement.

Where to go from here?

Performance was roughly equal in the rumble to the BasicGFSurfer drive. I need to tweak the segmentation approaches and parameters. I need to tweak the manner of adding danger. And I need to play around with rolling danger to see what effect that has. Once that is done, I don't believe I will make any more changes to the Stat Drive or it's use in XanderCat.

I may employ other drives in combination at some point using a "drive selector", an ability that is built into the Xander framework. For example, I would like to build a drive and gun built specifically for "mirror" bots that mirror their opponents drive; the drive selector would switch to these components whenever a mirror bot is detected.

Outside of drives, my Stat Gun is still a bit crude. I know I can improve there. And then I also have a few other little tricks up my sleeve I would like to try when I have the time.

It's neat to see you taking such a systematic approach with robocode! If I may a few suggestions:

• If I understand correctly, you add d/10 danger to every bin (except the one that hit you) rather than (in addition to?) adding bin-smoothed danger to each bin. I don't think this will help anything. The bin-smoothed danger should be enough.

• Logging hits from every wave, regardless of whether the other robot hit your robot, will give you a flatter movement; however, you may not actually want a flatter movement, even against GF guns. Before wave surfing was invented, I imagine that GF guns didn't roll their averages very much. Because of this, a flat movement will be worse against these guns. Rather than giving the enemy a flat movement to shoot at (which will make their targeting very close to random), you should move to the same GF repeatedly. When they hit you there, you know there is a peak in their stats, so you move somewhere else, and hopefully they keep shooting there for a while, allowing you to dodge bullets. Did I explain that well?

(I had thought of doing something like that but didn't for the reasons described above. It sounds rather similar to YersiniaPestis, but without the adaptive weighting of the flattener.) --AW 19:52, 6 June 2011 (UTC)

Nice job! Implementing Wave Surfing correctly can be a huge undertaking. My first suggestion would be to try just disabling the "every wave" logging of hits. You're right this should make you more unpredictable to learning guns. What most of us have found is that straight dodging from bullet hits actually works better against the vast majority of guns - only against the best guns does a "flattener" (what we call that mode) help. But more importantly, a flattener also destroys your scores against simple targeters.

I see you're getting 80% vs Barracuda and 88% vs HawkOnFire. Those could both be over 99% with no segmentation. My best advice would be to work on distancing, dive protection, and ironing out bugs until you can get that before trying to refine other aspects. Working on other stuff will only make it harder to fix the core stuff, and you may have to re-tune everything anyway once it's fixed. (Just turning off the flattener may go a long way!)

Good luck! --Voidious 20:37, 6 June 2011 (UTC)

Thanks for all the suggestions. I've been intentionally trying to come up with a lot of the ideas and code myself, as that makes it more rewarding for me. On the down side, this has made it harder to learn all the terminology used by the Robocode community. Not until both of your comments did I know what a "flattener" was, though I had seen the term pop up here and there. I hadn't spent too much time thinking about what the effects of it would be against different opponents, but your comments give me food for thought. I actually have my system set up now to run different configurations of my robot against a test base of robots, so I am now at the point where I can see some real results rather than just trying to deal with the theoretical. I'll try turning off the flattening and see what happens. Skotty 22:18, 6 June 2011 (UTC)

I assume by "distancing", you mean trying to keep my robot a reasonable distance away from the opponent. I was thinking maybe try to refine my drive path so that it will move slightly away from the waves if the wave origins are too close, and possibly favoring non-smoothing directions when near a wall and the calculated danger in each direction is similar. "Dive protection" as I understand it is not driving towards the enemy excessively; I don't see how this would happen except to a limited degree when wall smoothing, or on startup before bullets start flying (at the moment, when no bullet waves are in action, XanderCat will just move in a straight but wall-smoothed path, causing it to circle around the edges of the field; I should probably change this to make it move into a more desireable position before bullets start flying, rather than relying on chance). Skotty 17:46, 7 June 2011 (UTC)

Version 3.2

Had a bad night of tweaking where everything I did seemed to make my robot worse. I've turned off the flattening but I don't think I have a proper test bed of opponents to determine what kind of effect it might have. It did increase the score on Barracuda and HawkOnFire, but only to the about 90%. I did, however, finish some new anti-mirror components. PolishedRuby 1 is soooo dead. :-D I haven't tested against any other mirror bots yet, but my tests against PolishedRuby put a big smile on my face. As you might guess, when mirroring is detected, I have a drive and gun that work in tandem, where the drive plots a semi-random route in advance that the gun can process to fire on the mirror of the future positions. Awesome. My framework makes it easy to add it on to any existing gun combinations. It's not perfect, but it gets the job done, and might can be improved a bit more. With the mirror components active, my gun hit ratio on PolishedRuby jumped from something very sad up to a wicked 70%.

I've got my score on Barracuda up to the low 90s, and HawkOnFire up to about 98%. I've disabled the flattening, and I've implemented a new drive that takes command on the first few moments of a round to try and obtain better positioning before bullets start flying. Also, my StatDrive will now change it's angle a little to back away from waves when it deems itself too close to them. I also have the anti-mirroring operational. I was going to try and update my StatGun for this version (3.2), but I think I may hold off on that until version 3.3. I want to see what effects the changes so far have made.

Rumble Results

Fascinating results in the rumble. Despite winning fewer rounds than version 3.1, version 3.2 ranks about 30 places higher. Presumably by beating the simpler robots by quite a bit more than previously. Lots of variations in the PBI. I'll have to play around with some of the ones version 3.2 performed poorly against. I'll probably come up with a way to turn the flattening on and off automatically, which I think some of the other robots do. Only other thing I can think of to do for driving is to put some work into not running into the opponent robots, which is something I have ignored previously. AntiMirror components rocked.

Next version I will update the StatDrive. I know of a couple of ways it could be reasonably improved. And after that? Not sure...

My suggestion is that you need to up your score against Barracuda - there are still lots of points to be gained there. Until you are getting 99+% you are losing points due to not getting far enough away. If you watch your battles against Barracuda note every bullet hit and think about what your bot could have done differently to avoid it, be it reversing, being further away, not being against a wall, etc and then code something to get it to (not explicitly, but generally) avoid that situation next time. I'm not sure how your drive system works but in my bots I modify the desired angle towards the orbit centre proportional to the distance from the orbit centre, so as it gets farther away it moves towards the centre, and as it gets closer it moves away. Anyways, some food for thought. --Skilgannon 08:58, 8 June 2011 (UTC)

Were you looking at version 3.2 or 3.3? Version 3.2 gets about 93% against Barracuda. Yeah, it could be better. Version 3.3 in the rumble only got 80% against Barracuda. I can't explain that. I've run 3.3 myself against Barracuda many times, and it always gets around 93%, same as version 3.2. Ignoring that anomaly, where is that other 7%? It may be from collisions. Right now, XanderCat ignores collisions with the opponent, and can get stuck rammed against them. Also, it may be from getting too close when wall smoothing. I had mentioned the possibility of moving away from the wall in cases where danger each direction is similar in order to not get jammed against the wall as much, but I haven't implemented that idea yet. Skotty 14:21, 8 June 2011 (UTC)

I'd suggest hunting for bugs really. Even 98% against HawkOnFire, is low enough that I think that notable surfing bugs could be likely, (and having a large hidden influence against other bots). It should be possible to get to 99.9% or so if the surfing algorithm is reasonably precise and the bugs of implementation are worked out. --Rednaxela 14:48, 8 June 2011 (UTC)

Version 3.4 moves up the ranks, but still gets 98% on HawkOnFire and 95% on Barracuda. I believe this is due to not having any dive protection when wall smoothing (I do employ distancing, if I understand correctly what this is -- attempting to back away some when in too close -- but this doesn't help if you are getting smoothed into a wall). I'm still working on a good solution for dive protection near walls. I tried a few things when developing version 3.4 but haven't come up with something that improves performance yet. Perhaps for the next version. -- Skotty 17:16, 9 June 2011 (UTC)

A quck note for you in relation to ucatcher. That bot is uses bullet shielding. Basically, the better you shoot at it, the better chance it has to deflect your shot. Not too hard to detect when it happens either, just check the bulletHitBullet event and see if it happens a bunch. If so, don't aim for the center of the bot, but an edge of it instead. --Miked0801 23:31, 10 June 2011 (UTC)

On the heels of Tomcat, with XanderCat I achieved a decent rank, then figured out how to fight the top robots but it dropped my score, then I got my score back up to where it was. I'm happy with top robot performance for now; top 20 in PL score (PL score was 1630 earlier today, but it can fluctuate, as a lot of close calls), only a couple of robots that can make over 60% against XanderCat now, and I finally figured out how to hit Chase's robots (or at least, not miss them as badly) -- and it's not tweaked yet, so watch out Chase! *grin*

However, now I'm a bit stuck. I'm underperforming against some easier and mid pack robots like csm.NthGeneration, janm.Jammy, mcb.Audace, and morbid.MorbidPriest, to name a few. Not always the same problem. In some cases, I should be dodging bullets better; in others, I should be hitting with my gun better (my gun is not handling oscillating movements as well as it should). I've been monkeying with my data system for quite a few days now without making any headway. My top idea involved mixing and matching segmenters, selecting by which segmenter combination is providing the best hit ratio (either high or low, depending on if gun or drive). I still think it's a good idea, but I haven't seen positive results with it yet. Might be time for another break.

Le Gasp! You hitting my robots, nuuuuu, my poor cute little robots! T_T

In other news, I find that most of your gains come from bug fixes and structural changes. Segmentation is mostly there for fine tuning and for base targeting ability. You should focus more on examining how your targeting works and thinking up ways to improve that. Not saying to ignore segmentation, but it shouldn't be your primary focus until you are already doing pretty well with it's targeting.

I've planned out my next steps now. First, I'm going to do a little refactoring of my code to seperate responsibilities a little more for my guess factor / wave surfing code. I'm going to seperate the basic parts out into a hit logger (the component that logs hit and visit data in a tree), hit log reader (the component that decides on what data to select from the tree), and factor array constructor (the component that decides how to use the data). This will make further work easier and allow for improved efficiency in some areas (will be easier to cache certain data). Then I'm going to more closely review my tree code for issues and try a few variations on my selection algorithm that I think could yield good results.

I've got a real KD-Tree running now for my data. It runs faster than my old setup and should be more precise, but to my disappointment, it hasn't really seemed to improve things much. In fact, I've gotten worse at robots that do things like simple linear targeting. Overall APS is down. On the flip side, my data rolling, flattening, and other top robot fighting tricks are working pretty well, my PL score is the highest it has ever been, and only 3 robots in the entire rumble are scoring over 55 against me last I checked. I've carefully scrutinized, and my top robot tricks are not kicking in against easier robots and messing things up on them...something else is amiss...I just can't figure out what.

Robocode results are not always logical. Looks like you have to check against xiongan or timmit.nano.Timdog what is going on.

Good news! I found one, possibly two bugs to fix. One bug has been around for a long time, the other I think just introduced when I switched to a true KD Tree. I'll post the details in my next version notes.

I just barely squeaked into the top 20. I'm happy with that for now. I'm clueless on what to do next, so it will be awhile before there is any chance of further movement. I need to do some thorough bug searching in my data system, and/or do a large number of parameter tweaking tests against a large test bed, and/or get some brilliant new ideas. I don't see any of that happening soon. I'll probably focus on examining performance against mcb.Audace 1.3 first. Audace has a mostly oscillating movement. Most top 20 robots score 90 to 95 against Audace, but I only score 82.

Do you have any 'time-since' attributes in your gun? Like time-since-deceleration or time-since-direction-change? I found they work wonders at hitting oscillators...

Congrats! Well, even if you never work on it again, XanderCat is certainly a bot to be proud of. That said, it seems like I've heard you say that several times before and then you just kept climbing up the ranks... =)

I'm currently playing around with a time-since-direction-change segmentation in the gun, but it's not showing much improvement. I need to examine the data manually to see if there are any bugs. So the next things I'm going to do is to write some new debugging code that prints more information to screen, as well as write debug data to disk, so I can do a thorough analysis. I was also debating writing a painting framework for debugging, that makes it easy to turn debug options on and off and move informational printouts around on the screen. This will take some time to complete. In the meantime, I may set up 10.7.1 to run in the gun and drive challenges. I also want to explore updating RoboResearch to run battles in a different manner -- something I think JDev or someone has messed with before -- to try and reduce the startup times for battles. Currently, when I run RoboResearch, about 9/10 of the time it takes is waiting for the battles to start, with only about 1/10 of the time going to actually running the battles. Which is rediculous.

A thought about the time-since-direction-change - I'm not sure how your gun works, whether you're using discrete bins or raw value kNN type of gun, but remember that the likelyhood of a TSDC being a very high value is quite low, whereas it is more likely to be a low number. Both Rednaxela and I use something like 1/(1 + k*TSDC) in our kNN guns to nicely smooth it out so that all values receive a similar likelyhood of occuring.

I've learned a lot recently about what works and what doesn't against specific robots. I could make one heck of a little black book robot if I wanted to. Unfortunately, I am finding it to be very difficult to build a generic classification system, as I am not finding any easily detectable common threads/attributes on which I can rely upon.

Looking at all the hit ratios, I think my gun system is pretty decent (though always room for improvement). It's my drive system that needs more work. I've considered trying to go back to a VCS drive system. Also, I continue to consider trying some more range-search variations of my DC drive system, which I think holds some promise. I think I'll start playing around with the latter.

For Version 11, I'm experimenting with going back to more of a VCS drive rather than the KNN based drive.

One quick little note about VCS drive versus KNN drive: In my experience, when one implements both, the biggest differences in performance are typically implementation details (how the danger is formulated), rather than anything inherent to VCS or KNN. If one isn't very very careful about how one is formulating the danger as to make it equivalent, then one won't have a fair comparison between the VCS and KNN systems.

I'm not really looking for a fair comparison. Just looking to find out which one I find to be easier to work with. To me, each has it it's own unique advantages and disadvantages. But last time I had both, I was doing better with VCS. Time to see if that still holds.

And I'm not really sure if I really understand what you all define as VCS. To me, when I say VCS, I mean I have a ton of factor arrays, and each data point results in a factor array being updated. At surf time, I pick one of the factor arrays to surf. This being opposed to my version of KNN, where the data is saved in the KD Tree, and at surf time a single factor array is constructed after points are pulled from the tree.

Just curious, were you not using any kind of KD tree before? I haven't done any tests, but I'm fairly sure that Levy's tree is slower than Rednaxela's Gen3 tree.

For several versions now, I have been using a tree to store data, but it was something I wrote myself that was less precise and less efficient than a KD Tree (and it only did nearest neighbor, no distance or range search). I was hoping switching to a true KD Tree would improve both CPU performance and competition performance, though so far, only the former has been true.

Perhaps it is a dumb reason, but I've been trying to stay away from feeling as though I am copying other top robots, which is why I didn't look at any of the KD Tree implementations from other Robocoders. I thought about trying to write my own, but I'm already spending too much time on Robocode to reinvent another wheel just so I can slap my own label on it. Originally, I didn't even want to use a KD Tree, but after digging through my text books and other sources, a KD Tree was the perfect fit for what we are doing, so I couldn't say no.

Now if I could just figure out how to make it work better in my drive...I think I may have to drop to the level of carefully picking apart another open source top robot to figure out what they are doing that allows them to score 95 against robots I can only manage an 80 or 85 on. Those are the ones that are killing my APS.

I just released XanderCat version 9.0. It's not quite complete yet, but I couldn't stand it anymore. I had to drop it in the rumble to see where it's at. It's based on my heavily revised Xander framework. It's missing some features the previous version had, but it also adds some features (such as bullet shadows). Note that I decided to make a slight change to my package naming. My robots for the foreseeable future will now reside under "xander.cat" instead of "xandercat".

With version 9.0.1, I finally passed the 80 APS mark for the first time. Also back over 2000 on Glicko-2. Only other time that happened was way back on version 6.8. Still haven't passed my previous highest rank yet though, due to some tough new competitors since I started (Ixx, Chase, and others). Version 6.8 APS at the time was about 79.6, good enough for #42. Version 9.0.1 at the moment is 80.0 APS, rank #45. I'm convinced I can improve on this further; I just need more time to work on it.

I was here before you started, I just hadn't released any of my advanced (and unfinished) prototypes.

I ran a test, and to my surprise, my guess factor gun works as well as my circular gun and linear gun against circular and linear drivers. I've therefore reluctantly removed the gun array I was using, which included my linear and circular guns in addition to my main guess factor gun. Reluctantly, because I put so much work into developing those algorithms when I first started Robocode, so I hate to sideline them. But they are no longer providing any advantage, and at times are a little problematic. So away they go. However, my linear gun is still used against ramming robots for the time being, so they are not gone entirely.

Nene is pretty good at dodging close range linear targeting.