XanderCat's Future

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.

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.