View source for 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)

Forgot how slow this can go. :-/ I've been trying all day to record some new statistics using the Robocode means for saving file to disk, but I'm getting really bizarre version issues. I've been updating my robot version with each change -- 12.8.1, then 12.8.2, then 12.8.3. Each time I clear robot cache, package the new version, clear the old stats file that was saved from the prior version (as in, physically delete it, so I know the old stats are gone), and then run a new challenge with the new version. However, I keep getting garbage from older versions coming out in the results. Sometimes mixed, like it's randomly running different versions.

I've started trying to record the version information to the stats file each battle. I keep seeing this in the saved information:

Old: xander.cat.XanderCat 12.8.1*; New: xander.cat.XanderCat 12.8.7.

What that means, is it thinks the last battle was run with 12.8.1*, even though the entire challenge was run with 12.8.7. And that may actually be sort of true, because I'm getting some info in the stats file that I removed around version 12.8.4 but it shows up again, like it ran an older version for one or more of the prior battles.

At the moment, I'm totally confused by it. I'm not even sure how to debug it further at the moment.

As sometimes happen, writing about it made me figure it out. What was happening, that I didn't realize, was that the newer version of Robocode has an option to include the data files in the packaged robot, which is checked by default. So it was packaging data from an old version of XanderCat that I had run from Eclipse, which was totally screwing with my robot frameworks attempt to manage the robot data.

If you want to save any persistent data to the data files, make sure you uncheck the option to include data when packaging the robot!

Can't believe how much time I wasted figuring that out today.

I spent some time working on a system to pool frequently used objects in an attempt to mitigate the first round garbage collection problem my robot suffers from. My first attempt had some merit, but the changes involved are a lot more significant than I would like. I'm just not happy with it.

Recently, however, I came up with another idea that may be much simpler and effective. However, I still need to test out the idea. Instead of managing object pools, what if I just dump old objects into a "waste basket" that hangs onto those objects and releases them at a controlled pace -- probably slowly at first and releasing them faster as the rounds progress and the waste basket begins to fill up. Or perhaps empty the waste basket at safe times, like the end of a round or at times when XanderCat has a solid advantage already. This would use more memory overall but may be far simpler and less error prone. I'm going to sideline my prior pooled objects work and try this route for XanderCat 12.7.

That might work, but I have my doubts. Unless you're calling System.GC() all the time it seems likely that the garbage collector will wait for a bunch to pile up and do it in bursts regardless of how controlled of a pace you release your references at (and calling System.GC() all the time would also likely cause it's own issues). I'd say the real solution needs to involve just plain not using so many tiny objects in the first place.

(It's kind of one of my pet peeves about Java, that the language encourages extensive object use, yet if you use it "too extensively" the code will have performance issues to due excessive allocation/deallocation overhead. In some languages (such as C++) one has the option of combining multiple objects into the same block of allocation, but because all object instances are references in Java there's no such luxury, ironically meaning that high performance java code needs to use simpler/fewer OOP structures than high performance C++ code in order to match the performance)

Also a pet peeve of mine about Robocode at this point. It has a really strict time limit per turn with a programming language that doesn't give you much control at that small of a scope. And even if it did, a rolling average would be soooo much nicer, and skipped turns are such a burden to deal with.

Automated garbage collection is about getting the job done faster/cheaper. Machine code always has more potential for performance than any language and/or paradigm. But in practice, due to overwhelming complexity issues, lower level languages tend to deliver worse software overall.

If you want high performance Java, increase the size of the heap, and/or change the ratio between regions, which solves 99% of garbage collection issues.

We could make it standard in RoboRumble to have a heap optimized for real-time. Using "-Xmn511m -Xmx512m" or "-Xmn1023m -Xmx1024m" in roborumble.bat would do the job very well. Not as fun as programmatic object pooling systems though.

Starting a new thread to discuss my efforts to deal with the skipped turn issue that is apparently related to garbage collection eating up allowed run time. This was previously discussed in thread "Shielding Success Rates Mystery", for anyone who wants to see where it all started.

I purposely did not contribute to the rumble over the last few days after the pairings for XanderCat 12.6 were lost. I originally ran many of the original pairings on my PC that does not have the skipped turns issue. Most of the re-run pairings were likely run by Voidious, whose system does exhibit the skipped turns issue.

The difference between the two is quite significant. With clients that don't exhibit the skipped turns issue, XanderCat achieved an APS of 87.7. With clients that do exhibit the shipped turns issue, XanderCat achieved an APS of 86.5. The difference -- 1.2 APS -- is quite significant. With the current rumble participants, it makes the difference between 5th and 8th place.

Most of the difference is due to the skipped turns causing the bullet shielding system to fail much of the time. But likely the skipped turns in general -- ignoring the bullet shielding -- also contribute a small amount.

I had previously fixed a few performance bottlenecks to make XanderCat run quite a bit faster (v 12.3), with much lower turn time peaks, but this only achieved a marginal improvement. I now need to shift to figuring out how to reduce the amount of garbage my framework apparently creates. This is not a real easy problem to address, because it is a very unique Java problem that rarely ever needs to be addressed in the real world, so there is not a lot of information or research available online to help on this.

I think one thing I can do is to eliminate as many intermediate local variables as I can. For example, variables with only method scope that are used to break something into multiple easier to maintain steps. These extra method scope variables may be contributing to the garbage collection, especially in the first round. Eliminating them may help to fix the problem, but at the expensive of either combining multiple lines together into more complex lines or making the variables have a wider than necessary scope (declaring them as part of the class), thus eating more memory overall but eliminating the possibility of it triggering garbage collection.

I don't know if these steps will help, but I will probably give it a try. I am also not sure if there are other ways to reduce garbage collection, but maybe I will come across some other ideas. I may actually create a second branch in my source tree for this work, something I never thought I would do for Robocode. I want to keep the current version, as I think it will constitute better code and perhaps someday the garbage collection issue will be addressed by changes to Robocode itself; but if my garbage reduction efforts work, for now I will operate off of a garbage reduced branch.

This seems like a really crappy thing to push onto you as a bot author. I do think our time is probably better spent coming up with a proposal to change Robocode itself and submitting that (as idea, design, or code) to Fnl. There could be a very simple and elegant solution that would work, like "allow 10x the CPU constant for the first 100 ticks". (Disabling CPU limits in first 100 ticks seems problematic, since you want to at least interrupt bots that hit infinite loops.) Another idea is having Robocode run its own GC cycle right before the match starts, in case bots are being penalized for GC of the game engine.

I'll try to get to another round of tests and find out how much I need to raise the CPU constant to get normal performance out of XanderCat.

I've had to deal with this quite a bit when writing games in c#. Similar to Java the GC can case obvious stalls. The easiest way is to stop calling the "new" function at run time by using pooling. For instance at the start of a match, or a round create a container object which contains N pooled objects which you know you create often, eg wave objects. At the point you wish to use one, take it from the pool, initialise it, use it, then return it to the pool when finished at any point later on.

Because you have not called new, and then nulled the object, the memory used does not go up, it stays constant, thus no GC is run. It's obviously impractical to pool everything so you just do the worst offenders which are things that you create often and throw away.

That seems like a great approach. And you can even create the pools in a static block, which I'm pretty sure runs before the match starts and won't count against any of your CPU time.

Speaking of static blocks, I've noticed that they get run on Robocode/rumble startup for every single bot, which is partly why it takes so long to start when there are lots of bots in the /robocode/robots directory. I also suspect that code in static blocks isn't subject to the security manager, since it can print to the main console. Does somebody feel like writing a test bot to see if this theory is correct?

Local variables are stored in the stack and not the heap, so they don't affect garbage collection.

You should look after "new" abuse, like Wolfman said. Although sometimes the instantiation is implicit and simply searching for the "new" keyword doesn't always work.

There are heap profiling tools which locate automatically where too many objects are being instantiated.

Local variables are stored on the stack but any time you use new it will go on the heap afaik:

public void MyFunc(Object a) {

  Object b = a; // Variable b is on the stack, pointing at a.
  b = new Object(); // Memory allocated on heap, referenced by variable b on the stack

}

This is my understanding of it. Please correct me if I am wrong!

This is correct.

My understanding of the snippet above is that you have 3 variables. 2 local in the stack (references "a" and "b") and 1 in the heap (Object instance).

Some variables stay in the stack only, like primitives (double, float, int...).

Where would a primitive array like an int[] end up?

Java treats an array as an object, so on the heap.

However, these days the JVM is more intelligent than you guys are giving it credit for, eg. it has Escape Analysis to determine if objects should be put on the stack if they stay local.

Didn´t know about escape analysis.

What I usually do to take in account all optimizations, even those I don´t know about, is to use profiling tools. Measure what is really happening, instead of looking at the code and guessing.

I've actually been debating writing a Robocode simulator to make robot profiling much easier. What it would do is to pretend to run a robot battle with your robot against either another opponent, or perhaps some imaginary robot, using a combination of mock objects and simulation. It would run without any security at all, no sandbox, nor would their be skipped turns, so you would only want to run it with trusted robots. But it would be much easier to run a profiler against. The simulated battle may not be a perfect simulation, but as long as it's close, it should work and be useful.

When I do profiling in Robocode, I run a battle of a bot against itself. Then I filter the results by package so engine data is filtered out and only data from my bots appear in the profiling report.

Yes. However anything that you are creating during a function and keeping hold of for a few frames and then releasing is going to be allocating on the stack. Stuff like "Wave" objects, "Bullet" objects or whatever else you use in your bot will cause GC stalls if you create lots, use for a while and then null. This is where the pooling comes into force. I would definitely recommend pooling objects such as waves etc if you are having trouble with stalls and then go from there.

-wolfman

See, my bot always had a skipped turns problem, and now you're giving me a possible solution. You're drawing me right back in to wanting to start Robocoding again, dangit! *laughing*

Yes, yes, come to the dark side, make your code ugly but fast, like mine :-p

Although its more likely that the stall is caused by your code running too slow rather than blaming it on the GC imho. Can you use eclipse to profile execution and memory of robots? Anyone know? If so a wiki page would be lovely :)

Arrays are objects in java:

public void func() {

  int[] myArray; // myArray variable on the stack
  myArray = new int[5]; // Array object allocated on heap, referenced by myArray variable on the stack

}

Note that member variables of objects are obviously going to take up memory on the heap not the stack - eg if you have 30 primitive member variables (ints, doubles etc) of a class and call new on that class, it will take up more memory allocation than a class that has 1 primitive member variable.

However allocating 30 local primitive variables during a function call allocates those primitive types on the stack alongside you local member reference variables.

While I am not the saddest person here that this has happened to you (as my robot is right above yours in the rankings with only a little APS between it and yours). But I know I would hate it if this happened to me. However I have tried to design things from the ground up in more recent robots to limit object creation and destruction.

At one point I even reused old objects (aforementioned pooling) instead of creating new ones. That didn't make it into the current version however.