Difference between revisions of "XanderCat"

From Robowiki
Jump to navigation Jump to search
m (notes on version .4.7.1 (bug fixed))
(Replaced 12.10 plans for 13.0)
 
(413 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
[[Category:Bots|XanderCat]]
 
[[Category:Bots|XanderCat]]
−
MegaBot based on my [[XanderFramework|"Xander" robot framework]] with pluggable guns, radars, and drives.  XanderCat is the flagship of my robot fleet.
 
  
−
Versions up through 2.1 and from 3.1 onward are handcrafted without borrowing code from other robots. Version 3.0 uses a variation on the Wave Surfing drive from BasicGFSurfer, but a wave surfing drive of my own design is used in version 3.1 and beyond. XanderCat could be made smaller by removing unused Xander components and taking advantage of some of the newer classes like Rules, but it's so far above the next smaller weight class that it doesn't really matter.
+
{{Infobox Robot
 +
| bgcolour        = LightBlue
 +
| author          = [[User:Skotty|Skotty]]
 +
| extends        = [[AdvancedRobot]]
 +
| image          = XanderCatLogo-small.png
 +
| targeting      = [[GuessFactor Targeting|GF]] / [[Linear_Targeting|Linear]] / [[Circular_Targeting|Circular]] / Anti-Mirror / [[Bullet_Shielding|Bullet Shielding]]
 +
| movement        = [[Wave Surfing|WS(GoTo)]] / Anti-Mirror / RamEscape / Ram / IdealPosition
 +
| released        = 2011-5-20 (v 1.0)
 +
| best_rating    = #4/5/6 (v 12.8)
 +
| current_version = 12.9
 +
| codesize        = 58,581 (lol)
 +
| license        = GCWCD
 +
| download_link  = http://www.distantvisions.net/robocode/xander.cat.XanderCat_12.9.jar
 +
}}
  
−
Current Version: 4.7.1
+
== Introduction ==
  
−
'''Best against:'''  Any robot that spends too much time standing still, going straight, going in circles, or doing basic mirroring.
+
MegaBot based on my [[XanderFramework|Xander Robot Framework]] with pluggable guns, radars, and drives.  XanderCat is the flagship of my robot fleet.  It is a multi-mode robot using multiple guns and drives organized into a ''component chain''.  It's main gun is a guess factor gun, and the main drive is a wave surfing drive (GoTo-style), but a number of other guns and drives exist for special situations.  Both the main gun and drive are currently using a hybrid form of dynamic clustering. The drive is somewhat unique in that it decides where it wants to go and goes there directly (no orbiting -- though the path still is somewhat orbital in nature due to MEAs and distancing -- and no wall stick while driving).  XanderCat also makes use of my [[XanderPaintingFramework|Xander Painting Framework]] for development and debugging.
  
−
'''Worst against:''' Varies.
+
(*) As of 2013, version 12.6 was ranked #7 in the rumble, but can rank as high as #5 if a solution for the first round garbage collection problem can be implemented. It is unusual to have a garbage collection issue in Java, but Robocode is an unusual game.  On some platforms, garbage collection in the first round can cause multiple skipped turns on large robots that create a lot of objects.  This is true for XanderCat.  XanderCat is further affected by this issue because it causes the bullet shielding mode to fail some of the time, when otherwise it would have worked.
  
−
'''Drive Tree:'''
+
'''Best against:'''  Generally a good performer; probably most notable for having simple yet effective anti-mirroring capabilities.
 +
 
 +
'''Worst against:'''  Currently DrussGT, Diamond, and Tomcat are still quite deadly to XanderCat.
 +
 
 +
'''Favorite Robots To Beat:''' 
 +
*  lazarecki.mega.PinkerStinker 0.7 - because I don't like it's name.
 +
*  da.NewBGank 1.4 - because of it's name and because it can be beat by a large margin by exploiting a "newbie" bug in it, which is pleasantly ironic.
 +
 
 +
'''Past Version Notes:'''  For information on versions prior to the current series, see the [[XanderCat/History]] page.
 +
 
 +
'''Name Origin?'''
 +
 
 +
Xander comes from my son's name Alexander.  Cat was originally meant to be of the feline variety, as I like cats, have used the term in other software projects, and it seemed appropriate.  Cat could also be associated with the tractor variety, which I think also works (a tractor with a gun), and I'm fine if people make that association too.
 +
 
 +
'''Hybrid Dynamic Clustering?'''
 +
 
 +
XanderCat uses Dynamic Clustering (DC) in the sense that data about past waves is stored in a tree structure.  For each wave, past data is pulled from the tree that as closely as possible matches the current situation, and that data is used to decide where to aim or drive.  However, once the data is pulled, how to use it differs from classic DC.  In classic DC, some form of kernel density algorithm is used to determine what to do.  In the XanderCat hybrid approach, it behaves more like VCS, in that the data is logged into a factor array, and that array is surfed in the GoTo style.
 +
 
 +
'''Surfing Multiple Waves?'''
 +
 
 +
Starting with version 9.5, XanderCat now surfs up to 2 waves at a time.  The general approach is as follows:
 +
#  Calculate the first n best factor angles to drive to for the next wave to hit, each of which must be separated by a given amount.  Each has an associated danger value.
 +
#  From the end points of the n factor angles, continue to predict into the future surfing of the second wave to hit.  For the second wave, only the best factor angle is used.
 +
#  Add the first wave danger value to the corresponding second wave danger value for both the factor angles of the first wave.  Choose which first wave factor angle to drive to by which has the lowest combined danger value.  (Note:  The calculation is a little more complicated, taking wave distance and bullet power into account, but the basic idea is the same.)
 +
 
 +
Note the image below, where:
 +
* a = reachable factor range for first wave
 +
* b = minimum distance that must exist between choices
 +
* c = first choice for surfing first wave
 +
* d = second choice for surfing first wave
 +
* e = current robot position
 +
 
 +
If the sum of the danger values represented by orange lines was less than the sum of the danger values represented by the red lines, the second choice for the first wave would be used.
 +
 
 +
[[File:skotty-2wsrf.png]]
 +
 
 +
'''Saving Data Between Battles?'''
 +
 
 +
XanderCat does save data between battles, but that data is not used by the robot and does not effect performance any.  It is collected solely for my own analysis.  It helps me find problems and decide on where improvements are needed.  I also just like statistics.  Of course, I only get statistics on battles run by my own machine.  Below is an example some data it collected:
 +
 
 +
Key:
 +
# Opponent = Opponent robot name and version
 +
# G1 Shots = Shots taken by the main guess factor gun
 +
# G2 Shots = Shots taken by the Anti-Scarlet guess factor gun
 +
# CD Scenario = Percentage of time the CircularDriverScenario was applied against the opponent
 +
# PD Engage = Number of times my bullet fire power was dropped (see v10.21 notes for what this means)
 +
# Flattener = Percent of total time the flattener was engaged
 +
# My HR = My overall hit ratio
 +
# Opponent HR = Opponent overall hit ratio
 +
 
 +
{| border="1" cellpadding="4"
 +
!Opponent
 +
!G1 Shots
 +
!G2 Shots
 +
!CD Scenario
 +
!PD Engage
 +
!Flattener
 +
!My HR
 +
!Opponent HR
 +
|-
 +
| techdude.kombat.FlamingKombat 1.5
 +
| 8
 +
| 62
 +
| 78.5%
 +
| 0
 +
| 0.0%
 +
| 73.5%
 +
| 3.4%
 +
|-
 +
| test.Fuzzer 1.0.1
 +
| 449
 +
| 13
 +
| 0.0%
 +
| 0
 +
| 0.0%
 +
| 60.6%
 +
| 9.9%
 +
|-
 +
| test.Podgy 4.0
 +
| 465
 +
| 387
 +
| 0.0%
 +
| 0
 +
| 0.0%
 +
| 22.0%
 +
| 7.2%
 +
|-
 +
| throxbot.ThroxBot 0.1
 +
| 747
 +
| 12
 +
| 0.0%
 +
| 0
 +
| 0.0%
 +
| 30.9%
 +
| 5.5%
 +
|-
 +
| tide.pear.Pear 0.62.1
 +
| 806
 +
| 490
 +
| 0.0%
 +
| 10
 +
| 7.0%
 +
| 13.0%
 +
| 11.2%
 +
|}
 +
 
 +
In addition to saving data on each robot, it can save a generic set of data about performance against the field as a group.  As an example, to get an idea of early, mid-game, and late game performance, I log the number of round wins for each round.  Example (to keep the table short, I left out rows for rounds 3 through 31):
 +
 
 +
{| border="1" cellpadding="4"
 +
! Round
 +
! Wins
 +
! % Wins
 +
|-
 +
| 0
 +
| 615
 +
| 88.9%
 +
|-
 +
| 1
 +
| 630
 +
| 91.0%
 +
|-
 +
| 2
 +
| 613
 +
| 88.6%
 +
|-
 +
| ...
 +
|
 +
|
 +
|-
 +
| 32
 +
| 644
 +
| 93.1%
 +
|-
 +
| 33
 +
| 654
 +
| 94.5%
 +
|-
 +
| 34
 +
| 644
 +
| 93.1%
 +
|-
 +
| Total
 +
| 692
 +
|
 +
|}
 +
 
 +
== Multi-Mode Scenarios / Component Chain ==
 +
 
 +
'''Component Chain:'''
 
<pre>
 
<pre>
−
              Ram Escape Selector
+
Default --> Basic Radar
−
          /-------------^-----------\
+
  |
−
  Ram Escape Drive         Anti-Mirror Selector
+
  v
−
                      /-------------^-------------\
+
BulletShieldingScenario -> Bullet Shielding Drive, Bullet Shielding Gun
−
            Anti-Mirror Drive        Active Bullet Waves Selector
+
  |
−
                                /----------------^--------------\
+
  v
−
                     Ideal Position Drive             Leadoff Drive Selector
+
RamEscapeScenario --> Ram Escape Drive, Linear Gun
−
                                                        /-------^--------\
+
  |
−
                                          Simple Targeting Drive    Advanced Stat Drive
+
  v
 +
AntiMirrorScenario --> Anti-Mirror Drive, Anti-Mirror Gun
 +
  |
 +
  v
 +
NoBulletWavesScenario --> Ideal Position Drive
 +
  |
 +
  v
 +
CircularDriverScenario --> Circular Gun
 +
  |
 +
  v
 +
Defaults --> Guess Factor Gun Array, Drive Array
 +
                     |             ______|_______________
 +
                    |            /                     \
 +
                    |  Targeting Detector Drive    Main Wave Surfing Drive
 +
          __________|___________
 +
          /                      \
 +
  Original Gun          Anti-Surfer Gun
 
</pre>
 
</pre>
  
−
'''Gun Tree:'''
+
'''Ram Low Energy Scenario''' (not currently in use)
−
<pre>
+
 
−
          Opponent Disabled Check
+
This scenario attempts to ram the opponent if the opponent is at low energy and has stopped firing bullets.  Should the
−
        /-----------^------------\
+
opponent who stopped firing bullets suddenly fire a bullet at close range during the ram attempt, the low energy cutoff
−
  Head-On Gun              Bullet Shield Protected Wrapper
+
can be reduced further (fool me twice, shame on me).  Also, this scenario will only engage if our own robot is over some
−
                                        |
+
minimum energy level threshold.
−
                              Anti-Mirror Selector
+
 
−
                              /--------^----------\
+
To ram the opponent, the ram drive uses three approach methods depending on distance from opponent.  At far distances,
−
                  Anti-Mirror Gun             Virtual Hit Ratio Selector
+
the ram drive will just drive directly at the opponent.  At short distance, the ram drive uses a linear intercept.  At
−
                                  /-----------/----------^-----\--------------\
+
intermediate distances, the ram drive uses a blending of the two.
−
                            Linear Gun    Circular Gun      Stat Gun*    Advanced Stat Gun                     
+
 
−
</pre>
+
'''Bullet Shielding Scenario'''
 +
 
 +
This scenario attempts to use bullet shielding against the opponent.  The bullet shielding components basically follow the standard approach, except I didn't bother trying to make the bullet lines cross at their segment midpoints, so there may be an improvement to make there some day?  Determining ''when'' to use this scenario is a bit complex, and includes 9 different conditions that must be met for the scenario to apply.
 +
 
 +
'''Ram Escape Scenario'''
 +
 
 +
This scenario applies whenever the opponent appears to be ramming.  At present, this works be simply testing the opponent's distance being under some threshold.  This sometimes happens against robots who are not really ramming -- this can happen due to initial round positioning, or just due to drive paths that happen to run too close together -- but in these cases there is no real disadvantage to using the ram escape scenario to back away from the opponent.  This distance of ram detection will increase the more the ram scenario is applied.  This makes the ram escape scenario kick in sooner and more often against the real rammers who ram consistently.
 +
 
 +
When this scenario is applied, a Ram Escape Drive is paired with a linear targeting gun. At present, this is the only place in which I utilize linear targeting in a gun.  The Ram Escape Drive attempts to drive away from the enemy as much as possible, and uses turning to try and dodge some of the opponents shots (for example, it may change the direction of turn at the moment an opponent shot is detected).
 +
 
 +
'''Anti-Mirror Scenario'''
 +
 
 +
This scenario applies whenever the opponent appears to be using a mirroring drive strategy.  The countering technique is to plan a drive path into the future such that it is known where to shoot in order to hit the mirrored position in the future.  At present, this can be fooled by creative mirrorers that utilize a delay or position shifting.
 +
 
 +
'''No-Bullet-Waves Scenario'''
 +
 
 +
This scenario applies whenever the opponent has no bullets in the air (note: this can happen often with a rammer, but the ram scenario happens earlier in the component chain and thus supercedes this scenario).  When the opponent has no bullets in the air, the Ideal Position Drive takes over and moves the robot directly to what it perceives as the ideal position on the battlefield given the battlefield size and the current position of the opponent.
 +
 
 +
I've attempted to replace this somewhat crude drive a few times, but each time resulted in a lower overall score in the RoboRumble, giving rise to the idea that this drive is imbued with magical powers.
 +
 
 +
'''Circular Driver Scenario'''
 +
 
 +
This scenario doesn't affect overall performance much, but it does two things that make me feel better:  first, it brings back my circular gun, which otherwise would not be in use.  I once spent a lot of time on it, and would like it to be used somewhere.  Second, it makes me feel better when pitted against simple circular drivers like SpinBot, where my guess factor gun still misses quite a few shots, but my circular gun can hit nearly every time. 
 +
 
 +
To make this scenario as effective as possible without degrading any performance elsewhere, it is not enough for an opponent to appear to be moving in a circular path at the time a shot is taken.  The opponent must have been moving (and still be moving) in a consistent circular path.  Furthermore, that path must not intersect any walls before the shot would reach them.  The circular movement path is predicted into the future until the bullet would arrive to check for this. ''(Note:  Using prediction for this is not really a good idea; I should have just checked the bounds of the circle. I will make this change in some future version.)''
 +
 
 +
'''Default Gun Array'''
 +
 
 +
The gun array consists of several guess factor guns.  This is not too computationally expensive because they are currently all using the same cached copy of data.  They just use the selected data differently when building the factor array to use for aiming.  The Anti-Surfing Gun uses a certain amount of data rolling.  This technique was first implemented to counter Scarlet, who at one time was trouncing my robot far worse than any other, and was thus for awhile named the Anti-Scarlet gun.
 +
 
 +
'''Default Drive Array'''
 +
 
 +
The drive array consists of two drives:  what I currently call the Targeting Detector Drive and the Main Wave Surfing Drive.  Both drives are ''direct'' wave surfing drives.  They just differ in what data they use to surf.  I use the term ''direct'' to indicate how the drive moves the robot; the robot is moved at a fixed angle until it reaches the desired surfing factor angle for the current wave, in essence moving there directly in as straight a line as possible rather than using an orbital path.  However, in action, it may still appear to use a somewhat orbital path, as where to move is recalculated for the same wave under various conditions -- such as when the waves are updated due to new bullet shadows, or the opponent moves too far away from it's predicted path.
 +
 
 +
''Main Wave Surfing Drive''
 +
 
 +
This drive uses Dynamic Clustering with a KD Tree for it's data management.  A simple equation is used to determine how many nearest neighbor data points to pull, and those points are logged into a factor array to surf.
 +
 
 +
''Targeting Detector Drive''
 +
 
 +
This drive uses a combination of ''targeting detectors'' that are designed to detect specific types of targeting.  Each targeting detector can add a data point to the factor array, with the data point weight based on how often the detector thinks it is detecting it's specific form of targeting.  This system is designed to improve scores against robots that use predictable targeting (non-guess-factor), something I have had trouble getting my main wave surfing approach to handle as well as other top robots.
 +
 
 +
'''Bullet Shielding Protection'''
 +
 
 +
All main guns are wrapped by my ''BSProtectedGun'' wrapper/decorator class.  It is a different animal from my original version.  My original version shifted the target's position slightly to avoid perfect aim shots, a technique that works well against the basic shielder's such as uCatcher.  However, it was generally ineffective against moving shielders like MoxieBot.  At the same time, my normal aiming technique for my latest guess factor guns is not vulnerable to the stand-still shielders (by chance more than design).  Therefore, the latest incarnation of my BSProtectedGun attempts to handle shielding using a new strategy that does not rely on shifted aims, and focuses more on protecting against on-the-move shielders. 
 +
 
 +
When bullet shielding is detected, the BSProtectedGun will check the energy levels of both robots.  So long as my energy level is more than the opponents, the BSProtectedGun will halt firing and wait for the shielding opponent to fire first, then the BSProtectedGun fires immediately after the opponent.  This ensures that the opponent's shot is not a shielding shot.  It is still possible that the opponent could fire a second shielding shot before the my shot reaches them, but in practice this hasn't been an issue.  This could also fail against perfect shielders where my energy level never exceeds the opponent's, but again, in practice this hasn't been an issue.  If it did ever become an issue, I would keep basically the same strategy, but start shifting target position again like in the original gun.
 +
 
 +
This strategy has an interesting yet not surprising result against MoxieBot.  MoxieBot shields on the move, but the shielding is never perfect, and my robot can usually get the upper hand on energy at some point in the round.  When this happens, my robot stops firing and waits for MoxieBot to fire first.  However, MoxieBot in turn is waiting for me to fire before it fires, resulting in a stalemate where no one is firing.  This in turn results in Robocode activating the stalemate energy drain.  Neither robot incorrectly detects the energy drain as an opponent bullet, so the stalemate continues until the energy drain kills one of the robots.  However, since my robot only stopped firing after getting the upper hand on energy, my robot gets the win.  End result, a somewhat higher score against MoxieBot, and ''much'' higher survival.
 +
 
 +
To improve on this further, I am considering possibly using chase bullets when my energy level is less than the opponent's, which should make it harder for the opponent to shield.
  
 
= Version Notes =
 
= Version Notes =
Line 41: Line 267:
  
 
Note: Best Change and Worst Change are the change from previous version against the given opponent.
 
Note: Best Change and Worst Change are the change from previous version against the given opponent.
 +
 +
Note: Starting from version 6.4 onward in the table, I am ignoring nat.BlackHole 2.0gamma and nat.Samekh 0.4, as scores against them always fluctuate rather wildly.
  
 
{| border="1" cellpadding="4"
 
{| border="1" cellpadding="4"
Line 202: Line 430:
 
| jab.DiamondStealer 5
 
| jab.DiamondStealer 5
 
| 80.6 -> 61.7
 
| 80.6 -> 61.7
 +
|-
 +
| 4.8
 +
| 57 / 803 (76.46 APS)
 +
| 7.1%
 +
| ar.QuantumChromodynamics 1.2.1
 +
| 69.2 -> 90.5
 +
| nat.BlackHole 2.0gamma
 +
| 60.8 -> 42.0
 +
|-
 +
| 5.0
 +
| 70 / 805 (74.37 APS)
 +
| 8.7%
 +
| deo.FlowerBot 1.0
 +
| 53.4 -> 84.6
 +
| kcn.unnamed.Unnamed 1.21
 +
| 79.1 -> 58.0
 +
|-
 +
| 5.1
 +
| 49 / 815 (78.59 APS)
 +
| 6.0%
 +
| ary.SMG 1.01
 +
| 35.5 -> 90.3
 +
| nat.BlackHole 2.0gamma
 +
| 54.4 -> 33.0
 +
|-
 +
| 5.1.1
 +
| 49 / 815 (78.75 APS)
 +
| 6.0%
 +
| rz.Apollon 0.23
 +
| 69.6 -> 94.0
 +
| nat.Samekh 0.4
 +
| 72.7 -> 53.6
 +
|-
 +
| 6.1.8
 +
| 59 / 806 (76.65 APS)
 +
| 7.3%
 +
| cx.Princess 1.0
 +
| 47.8 -> 65.1
 +
| toz.Gnome 1.1
 +
| 88.4 -> 61.6
 +
|-
 +
| 6.2
 +
| 59 / 806 (76.84 APS)
 +
| 7.3%
 +
| nat.BlackHole 2.0gamma
 +
| 42.1 -> 67.0
 +
| stelo.RamTrackSurfer 1.2
 +
| 89.2 -> 72.9
 +
|-
 +
| 6.3
 +
| 56 / 806 (77.04 APS)
 +
| 6.9%
 +
| kid.Gladiator .7.2
 +
| 47.7 -> 65.5
 +
| nat.BlackHole 2.0gamma
 +
| 53.4 -> 33.3
 +
|-
 +
| 6.4
 +
| 51 / 806 (78.22 APS)
 +
| 6.3%
 +
| dmp.micro.Aurora 1.41
 +
| 62.1 -> 79.1
 +
| myl.micro.NekoNinja 1.30
 +
| 77.3 -> 61.3
 +
|-
 +
| 6.5
 +
| 48 / 808 (78.70 APS)
 +
| 5.9%
 +
| ncj.MoxieBot 1.0
 +
| 76.9 -> 92.6
 +
| bayen.nut.Squirrel 1.621
 +
| 89.3 -> 74.9
 +
|-
 +
| 6.7
 +
| 45 / 807 (79.17 APS)
 +
| 5.6%
 +
| apv.ScruchiPu 1.0
 +
| 57.9 -> 79.5
 +
| trab.nano.AinippeNano 1.3
 +
| 91.4 -> 74.7
 +
|-
 +
| 6.8
 +
| 42 / 808 (79.69 APS)
 +
| 5.2%
 +
| trab.nano.AinippeNano 1.3
 +
| 72.2 -> 89.5
 +
| rampancy.Durandal 2.2d
 +
| 81.5 -> 69.4
 +
|-
 +
| 9.0
 +
| 46 / 827 (79.73 APS)
 +
| 5.6%
 +
| N/A
 +
| N/A
 +
| N/A
 +
| N/A
 +
|-
 +
| 9.0.1
 +
| 45 / 827 (80.03 APS)
 +
| 5.4%
 +
| ary.SMG 1.01
 +
| 50.5 -> 76.4
 +
| ncj.MoxieBot 1.0
 +
| 95.5 -> 75.5
 +
|-
 +
| 9.1
 +
| 43 / 828 (80.25 APS)
 +
| 5.2%
 +
| kc.mini.Vyper 0.311
 +
| 54.7 -> 60.7
 +
| ab.DangerousRoBatra 1.3
 +
| 74.0 -> 66.7
 +
|-
 +
| 9.2
 +
| 38 / 828 (80.84 APS)
 +
| 4.6%
 +
| Bemo.Sweet30 1.6.1
 +
| 57.9 -> 68.3
 +
| kenran.mega.Pantheist
 +
| 75.3 -> 57.1
 +
|-
 +
| 9.3
 +
| 34 / 829 (81.35 APS)
 +
| 4.1%
 +
| ags.micro.Carpet 1.1
 +
| 76.3 -> 89.2
 +
| ary.SMG 1.01
 +
| 81.2 -> 64.9
 +
|-
 +
| 9.4
 +
| 33 / 830 (81.55 APS)
 +
| 4.0%
 +
| kenran.mega.Panthiest
 +
| 73.9 -> 85.3
 +
| bayen.nut.Squirrel 1.621
 +
| 88.8 -> 80.9
 +
|-
 +
| 9.5
 +
| 30 / 830 (81.71 APS)
 +
| 3.6%
 +
| wiki.BasicGFSurfer
 +
| 65.3 -> 75.5
 +
| rampancy.Durandal 2.2d
 +
| 80.3 -> 67.6
 +
|-
 +
| 9.6
 +
| 28 / 830 (81.91 APS)
 +
| 3.4%
 +
| darkcanuck.Gaff 1.50
 +
| 43.3 -> 52.4
 +
| kenran.mega.Panthiest 1.1
 +
| 89.6 -> 78.9
 +
|-
 +
| 9.7.1
 +
| 25 / 832 (82.05 APS)
 +
| 3.0%
 +
| rampancy.Durandal 2.2d
 +
| 77.8 -> 88.3
 +
| brainfade.Fallen 0.63
 +
| 64.0 -> 57.0
 +
|-
 +
| 9.8
 +
| 25 / 832 (82.12 APS, 1600 PL)
 +
| 3.0%
 +
| asm.Statistas 0.1
 +
| 70.4 -> 77.1
 +
| wcsv.PowerHouse.PowerHouse 1.7e3
 +
| 53.9 -> 46.8
 +
|-
 +
| 9.9.5
 +
| 24 / 831 (82.37 APS, 1604 PL)
 +
| 2.9%
 +
| ncj.MoxieBot 1.0
 +
| 74.9 -> 86.0
 +
| cx.mini.Cigaret 1.31
 +
| 64.9 -> 55.2
 +
|-
 +
| 9.15
 +
| 20 / 833 (82.74 APS, 1646 PL)
 +
| 2.4%
 +
| janm.Jammy 1.0
 +
| 75.2 -> 91.4
 +
| davidalves.net.DuelistMicro 1.22
 +
| 72.1 -> 63.8
 +
|-
 +
| 10.13
 +
| 19 / 837 (82.98 APS, 1658 PL)
 +
| 2.3%
 +
| whind.StrengthBee 0.6.4
 +
| 56.8 -> 67.8
 +
| rc.yoda.Yoda 1.0.6c.fix
 +
| 74.6 -> 63.9
 +
|-
 +
| 10.15
 +
| 19 / 837 (83.11 APS, 1658 PL)
 +
| 2.3%
 +
| cf.proto.Chiva 2.2
 +
| 61.5 -> 68.0
 +
| florent.XSeries.X2 0.17
 +
| 62.3 -> 56.7
 +
|-
 +
| 10.18.1
 +
| 16 / 837 (83.20 APS, 1656 PL)
 +
| 1.9%
 +
| jab.avk.ManuelGallegus 0.6
 +
| 70.4 -> 82.1
 +
| dft.Virgin 1.25
 +
| 73.6 -> 63.2
 +
|-
 +
| 10.22
 +
| 16 / 837 (83.59 APS, 1664 PL)
 +
| 1.9%
 +
| voidious.mini.Komarious 1.88
 +
| 54.4 -> 65.8
 +
| robar.micro.Topaz
 +
| 74.1 -> 65.5
 +
|-
 +
| 11.0
 +
| 10 / 840 (84.26 APS, 1668 PL)
 +
| 1.2%
 +
| florent.XSeries.X2 0.17
 +
| 58.6 -> 70.0
 +
| ary.micro.Weak 1.2
 +
| 68.1 -> 58.4
 +
|-
 +
| 11.3
 +
| 9 / 841 (84.41 APS, 1674 PL)
 +
| 1.1%
 +
| pez.micro.Aristocles 0.3.7
 +
| 67.6 -> 74.3
 +
| brainfade.Fallen 0.63
 +
| 70.5 -> 64.8
 +
|-
 +
| 11.4
 +
| 10 / 953 (84.92 APS, 1888 PL)
 +
| 1.1%
 +
| ags.micro.Carpet 1.1
 +
| 80.3 -> 85.1
 +
| abc.Shadow 3.83c
 +
| 54.9 -> 48.4
 +
|-
 +
| 11.5
 +
| 10 / 953 (84.94 APS, 92.52 S, 1890 PL)
 +
| 1.1%
 +
| Unavailable
 +
|
 +
| Unavailable
 +
|
 +
|-
 +
| 11.6
 +
| 8 / 953 (85.14 APS, 92.73 S, 1890 PL)
 +
| < 1%
 +
| Unavailable
 +
|
 +
| Unavailable
 +
|
 +
|-
 +
| 11.16
 +
| 9 / 971 (85.21 APS, 92.97 S, 1928 PL)
 +
| < 1%
 +
| Unavailable
 +
|
 +
| Unavailable
 +
|
 +
|-
 +
| 12.0.1
 +
| 8-9 / 971 (85.54 APS, 93.38 S, 1934 PL)
 +
| < 1%
 +
| kc.serpent.Hydra 0.21
 +
| 60.4 -> 97.3
 +
| dsx724.VSAB_EP3a 1.0
 +
| 98.2 -> 77.4
 +
|-
 +
| 12.1
 +
| 7 / 972 (86.09 APS, 93.89 S, 1932 PL)
 +
| < 1%
 +
| ph.mini.Archer 0.6.6
 +
| 64.7 -> 98.5
 +
| cx.mini.Nimrod 0.55
 +
| 99.3 -> 69.9
 +
|-
 +
| 12.2*
 +
| 7 / 976 (86.36 APS, 94.00 S, 1942 PL)
 +
| < 1%
 +
| synapse.rsim.GeomancyBS 0.11
 +
| 40.0 -> 69.6
 +
| kc.serpent.Hydra 0.21
 +
| 99.4 -> 82.6
 +
|-
 +
| 12.3*
 +
| 6 / 980 (86.60 APS, 94.10 S, 1948 PL)
 +
| < 1%
 +
| davidalves.Firebird 0.25
 +
| 78.0 -> 97.6
 +
| sm.Devil 7.3
 +
| 79.4 -> 69.0
 +
|-
 +
| 12.4*
 +
| 6 / 980 (86.68 APS, 94.10 S)
 +
| < 1%
 +
| rc.yoda.Yoda 1.0.6c.fix
 +
| 71.0 -> 87.6
 +
| Legend.BoulderZY 1.4.9
 +
| 95.0 -> 69.5
 +
|-
 +
| 12.5**
 +
| 5 / 984 (87.19 APS, 94.72 S)
 +
| < 1%
 +
| simonton.mini.WeeksOnEnd 1.10.4
 +
| 57.8 -> 83.8
 +
| jf.Dodger
 +
| 96.9 -> 70.0
 +
|-
 +
| 12.6*
 +
| 5 / 982 (87.74 APS, 94.8 S)
 +
| < 1%
 +
| mladjo.Grrrrr 0.9
 +
| 68.5 -> 99.2
 +
| kid.Gladiator .7.2
 +
| 86.9 -> 58.8
 
|}
 
|}
  
−
== Version 1.0 ==
+
(*) Version 12.2+ scores are greatly affected by what clients run them.  On some clients, a lot of skipped turns occur in the first round, typically causing the bullet shielding mode to fail.  12.3+ should be slightly better due to some CPU usage improvements, but the problem remains.  Despite this, there was little effect on 12.3 - 12.6 due to who all was running clients at the time and possibly also due to the CPU usage improvements.
  
−
Based on a not-quite-complete Xander framework.  Uses BasicRadar, OrbitalDrive, and a CompoundGun combining a CircularGun and a LinearGun.
+
(**) Version 12.5 score shown of 87.19 APS was on the Darkcanuck server.  However, the rank was only 86.38 APS on the LiteRumble server.  This was probably almost entirely due to the skipped turns anomaly of the clients, and gives an idea of how big a difference this anomaly can make.
  
−
== Version 2.0 ==
+
== Version CPU Usage ==
  
−
This version adds a StatGun to the CompoundGun (in order, the CompoundGun will consist of a StatGun, CircularGun, and LinearGun).  The StatGun is a "Guess Factor" gun of my own design.  I don't call it "Guess Factor" because, frankly, I hate that term.  The stat gun supports variable configuration, with interchangable Segmenter modules.  Version 2.0 uses a CompoundSegmenter, which combines a BulletTravelTimeSegmenter and a RelativeDirectionSegmenter.  This segmenter combination categorizes the statistics based on approximate time it takes bullet to reach opponent and opponent heading relative to self.
+
All values are averages in milliseconds with the exception of those listed as '''Peak''' values, which are the maximum time in milliseconds encountered during a typical 35 round battle.
  
−
== Version 2.1 ==
+
{| border="1" cellpadding="4"
 +
!Version
 +
!Notes
 +
!Gun Avg/Tick
 +
!Gun Peak
 +
!Drive Avg/Tick
 +
!Drive Peak
 +
|-
 +
|6.5
 +
|Single wave surfing, single guess factor gun.
 +
|1.01
 +
|13.41, 8.77, 8.41, 7.15, 6.94
 +
|0.21
 +
|7.70, 7.61, 6.93, 6.93, 6.49
 +
|-
 +
|9.13
 +
|Multi-wave surfing, single guess factor gun.
 +
|0.301
 +
|6.23, 6.21, 5.82, 5.13, 4.74
 +
|0.775
 +
|22.52, 20.01, 16.26, 16.23, 15.94
 +
|-
 +
|9.14 / 10.0
 +
|Multi-wave surfing, gun array with 3 guess factor guns, Levy's KD Tree.
 +
|0.182
 +
|6.13, 6.07, 5.24, 4.05, 3.93
 +
|0.544
 +
|15.24, 14.55, 14.13, 13.91, 13.78
 +
|-
 +
|11.0
 +
|Multi-wave surfing, gun array with 2 guess factor guns, Levy's KD Tree, unoptimized Precise MEA on guns
 +
|0.978
 +
|140.3, 27.06, 21.98, 20.92, 17.43
 +
|0.558
 +
|21.34, 20.03, 18.62, 17.41, 15.32
 +
|-
 +
|11.3
 +
|Multi-wave surfing, gun array with 2 guess factor guns, Levy's KD Tree, optimized Precise MEA on guns
 +
|0.631
 +
|12.79, 12.65, 9.98, 8.76, 8.68
 +
|0.543
 +
|19.16, 15.21, 14.57, 14.51, 14.40
 +
|-
 +
|11.4
 +
|Multi-wave surfing, gun array with 2 guess factor guns, Rednaxela's 3rd Gen KD Tree (w/ bucket size 64 and MaxHeap copied to List every search; might be better way to do this), optimized Precise MEA on guns
 +
|0.603
 +
|13.40, 9.15, 8.84, 8.76, 8.74
 +
|0.545
 +
|16.99, 15.04, 14.73, 14.39, 14.23
 +
|-
 +
|12.3
 +
|The same as 11.4, but with processing performance improvements.  The biggest improvement made to the direct drive predictor.  For more details, see version notes for 12.3.
 +
|0.267
 +
|5.23, 4.44, 3.77, 3.28, 2.98
 +
|0.299
 +
|7.34, 6.95, 6.81, 6.71, 6.60
 +
|}
  
−
Version 2.1 adds better gun selection, tweaked parameters for firing, driving, and stat gun segmenting.  For the driving, it drops the "inverse gravity bullet dodging", as it assumes opponents are using head-on or linear targeting, which likely causes worse performance against opponents using guess factor guns.  Instead, it just randomizes movement a little more. 
+
== Series Notes ==
  
−
== Version 3.0 ==
+
'''Series 1.x'''
  
−
This version drops the Orbital Drive, and instead uses a Wave Surfing drive based on the drive used by the BasicGFSurfer.  This means I cannot credit myself entirely for this version, as I am using a modified version of a previously existing Wave Surfing drive.  This version will serve as a reference point for my next version, which will use a Wave Surfing drive of my own design.
+
This series of robots was released while work on the Xander framework was still ongoing.  Targeting and drive strategies were somewhat simple.  No surfing or guess-factor targeting.
  
−
== Version 3.1 ==
+
'''Series 2.x'''
  
−
Switched to using my StatDrive for driving, a form of wave surfing drive of my own design.  This drive has not been tweaked yet, but seems to be doing it's job well so far.  Will be interesting to see how it compares to version 3.0 in the rumble.  This version also takes advantage of the ability to paint on the battlefield ([http://www.distantvisions.net/robocode/robo-draw.png very cool!]), though it is disabled in the packaged form.  It also benefits form a few minor tweaks to the Xander framework, for things like firing at enemies who are low on energy or disabled.
+
This series introduced my earliest concept on guess factor targeting.  Drive strategy was still simple.
  
−
== Version 3.2 ==
+
'''Series 3.x'''
  
−
This version has the following modification from version 3.1:
+
This series introduced wave surfing, and improvements to the guess factor gun.  Version 3.0 used a modified version of the BasicGTSurfer wave surfing drive as a reference point, with all later versions in the line using a wave surfing drive of my own design.  Towards the end of this line, I introduced virtual hit ratios, where all guns would provide aiming information for every shot to determine whether or not their aims would have hit the target or not.
−
*  Flattening turned off in StatDrive
 
−
*  Now tries to better position itself on round start using IdealPositionDrive (before bullets start flying)
 
−
*  StatDrive now attempts to back away from the enemy/enemy waves if it deems itself too close
 
−
*  Anti-Mirror components added (a drive, gun, and a few other odds and ends).  Bye bye PolishedRuby 1; I was tired of you wiping the floor with me. :-)
 
  
−
== Version 3.3 ==
+
'''Series 4.x'''
  
−
This version has the following modifications from version 3.2:
+
This series focused largely on drive improvements, including improvements to the wave surfing drive, dive protection, and a new ''Ram Escape'' drive.  This series also improved how fire power is selected.
−
*  StatDrive Flattening now auto-enables after a particular point in time if the opponent's hit ratio is over a certain threshold.
 
−
*  StatGun segmentation changed a bit; fewer relative direction and bullet travel time segments, but added a drive speed segmenter.
 
−
* StatGun now does a better job of predicting how far an opponent can get, and only looks within that range when deciding where to fire.
 
−
*  Some other minor StatGun tweaks.
 
  
−
== Version 3.4 ==
+
'''Series 5.x'''
  
−
Version 3.3 didn't show the improvement I was hoping for.  My next step was to do some bug hunting.  This has revealed a few things which have resulted in the following changes:
+
This series focuses on using a new strategy for calculating factors in guess factor guns and wave surfing drives, surfing multiple waves simultaneously (explored by never implemented), paying more attention to robot width, improving wall avoidance, and improving segmentation selection and processing.
−
*  StatDrive previously would decide on where to go for a bullet wave repeatedly.  While this might would seem good in that it makes it arguably more adaptable to unexpected events, that potential advantage appears to be outweighed by the "flip flopper" effect.  In some cases, XanderCat would keep changing it's mind on which direction to go for a wave, making it more likely to get hit.  Amusing, but not what I'm going for.  To avoid this problem, I have changed it so the decision on where to go for a wave is made once, and XanderCat sticks to that decision until the next wave.
 
−
*  StatDrive would previously go to the division of least danger.  I've found this to be too simple in practice.  I've now changed it so it separately looks clockwise and counter-clockwise, computing the average danger in each direction, and finding the exact division of least danger in each direction.  If one direction has significantly lower average danger than the other, the exact division of least danger in that direction is chosen.  If the two average danger levels are close to equal, it then chooses by which individual division has the least danger.  If the individual danger levels are close to equal, it then randomly decides.
 
−
*  Flattening effect has been turned off.
 
−
*  Rolling danger levels has been turned on (note:  danger levels are only rolled when total danger for a segment reaches a set maximum value)
 
−
*  The number of drive segments has been reduced slightly.
 
  
−
Per the advice of others, I looked deeper into the performance against HawkOnFire and Barracuda.  Some of the above changes are based on that.  My current scores against (in my own testing) against HawkOnFire and Barracuda average about 98% and 95% respectively.
+
'''Series 6.x'''
  
−
For kicks, I left on the painting features, in case anyone wants to see what I have been playing with. :-) I don't think it degrades performance too much, as most of the work happens in the onPaint method which is bypassed when not turned on the the UI.
+
XanderCat series 6 focuses on taking everything learned so far and evolving it into a new set of components, or at the very least, cleaning up old components or features that did not work out.  Series 6 introduces the new ''Evolution Drive'', an updated Wave Surfing drive, and new ways of handling factor arrays.
  
−
=== Rumble Results ===
+
'''Series 7.x'''
  
−
XanderCat 3.4 places 85th in the Rumble.  To someone not familiar with Robocode, that might sound kind of bad.  But to those who are familiar with Robocode...well, I can't speak for the rest of you, but I think it's pretty darn good.  It achieves my early goal of reaching the top 100.
+
XanderCat series 7 uses the first release-ready version of the Xander framework.  With the knowledge gained over prior versions of XanderCat, the Xander framework has undergone a final refactoring and cleanup and is now considered ready for public use.  The Xander framework can be considered as version 1.0. In addition to using the finished Xander framework, series 7 may see updates to the main drive and gun, as well as a first release into the melee competition.
  
−
== Version 3.5 ==
+
'''Series 8.x'''
  
−
This version has the following changes from the previous version:
+
This series will use my own take on using a K-nearest-neighbor (KNN) approach for the main drive and gun.  It may also finally introduce surfing multiple waves at once.   
−
*  Mostly fixed bug with gun aiming where aim was always one tick behind.  Fixed this by aiming with predicted positions 1 tick into the future, though this won't be exact.
 
−
*  Future position prediction bug fixed (was not taking velocity into account when changing heading).
 
−
*  StatGun overhaul.  I have attempted to make it as precise as possible.  Changes to the StatGun include the following upgrades:
 
−
**  Segment "danger" is now added as a triangular region in the factors/divisions centered at exact sighting factor rather than at a fixed sighting factor (in other words, the values added to the bins approximates for the exact sighting location rather than centering at the center of the closest factor; I'd have to include a picture, as it is hard to explain).  The triangular region added adjusts based on robot width (when a robot is closer, it's width causes it to span more divisions).
 
−
**  When getting the factor angle for a particular factor index, it now estimates an exact factor by considering the values in neighboring bins rather than taking the factor angle for the center of the pie slice for the factor index.
 
−
** It now attempts to get state of opponent when my bullet wave hits them down to the partial tick.
 
−
** Rolling history added.
 
−
*  Xander framework cleaned up and documented a little more. 
 
−
*  Some segmentation changes on the StatGun.  Now using lateral velocity, and wall smoothing (or wall proximity).
 
−
*  implemented a victory move when it wins. (because I can, though Robocode usually cuts the performance short)
 
  
−
The main purpose of this version is to see how much an improvement I can make just by polishing my guns.
+
My KNN approach to to create a ''KNN Factor Array Processor'' that can be used in both drives and guns.  I already have a '''FactorArrayProcessor''' interface built into my guess factor / wave surfing framework that it will utilize.  However, instead of saving a large number of factor arrays and combining them, it will instead store a tree of data points, retrieve the closest data points to the current situation, and build a single factor array from those data points.  One advantage of this approach is that is should allow for a greater number of segmenters and slices per segmenter.
  
−
Left out of this version (and possible changes for next version):
+
'''Series 9.x'''
−
*  Drive flattening in special cases
 
−
*  Dive protection
 
−
*  The Red Eyed Monkey
 
  
−
=== Rumble Results ===
+
This series uses the updated Xander framework version 2.0.  There are a variety of changes as a result.  This series saw the first introduction of bullet shadows.
  
−
Version 3.5 had a couple of bugs that were causing it to crash hard.  I found the bugs and updated it.  Waiting to see how 3.5.1 does.
+
'''Series 10.x'''
  
−
Performed worse than 3.4.  The problem I believe is a combination of 2 factors -- my segmentation isn't right, and my mix of guns is throwing things off.  I believe by continuing to allow other guns to fire, it is polluting the statistics of the stat gun (the stat gun still records everything, but the opponent behaves in a less predictable fasion).
+
The "Pro" series. This series switched to using a true KD Tree for drive and gun data.  However, many of the versions in this series were just parameter adjustments.  The only other major feature changes were to fix the buggy bullet shadows implementation introduced in series 9 and to begin (but not fully switch over to) the Xander Painting Framework.
  
−
Note: despite worse performance overall, performance on uCatcher improved quite a bit due to the improvements to the stat gun core.
+
'''Series 11.x'''
  
−
== Version 3.6 ==
+
This series attempts to add some revised functionality in an attempt to break into the top 10, or at least get very close.  This series will also see another round of code cleanup to reduce code size and fully utilize the Xander Painting Framework and Xander File Utility (removing any old code that the new frameworks can take over for).
  
−
This version will include the following changes from the previous version:
+
== Current Series Version Notes ==
−
*  Linear and Circular guns are only be used if their hit ratio early on is very high.
 
−
*  New higher quality segmentation processing for the guns allowing for the comparison of segment combinations on the fly (hotness!).
 
−
*  Gun segmenters in use changed to lateral velocity, bullet speed, and wall smoothing (wall proximity).
 
  
−
=== Rumble Results ===
+
=== Version 12 ===
  
−
No improvement overall.  Improvement against the top robots, but somehow this version loses too many points against the middle of the pack.  It could be the restriction of the linear and circular guns has something to do with it.
+
In series 12, I was attempting to build some new surfing components, but I generally didn't have much success doing so.  Therefore, I instead decided to go back to what I am good at -- multi-mode operation -- and added some new modes that should inflict a new round of pain on my unsuspecting foes.
  
−
== Version 3.7 ==
+
<b>New Features:</b>
  
−
This version includes the following changes from the previous version:
+
<i>Xander Framework Updates</i>
−
*  Re-worked how guns are handled in the Xander framework.  The performance of all guns can now be tracked simultaneously, rather than only for the active gun.  This is a big deal and should help a lot with some of my earlier troubles where gun selection was sloppy.  What this means is that I no longer have to actually shoot a gun to know it's performance, and can switch between them much more intelligently.
 
  
−
=== Rumble Results ===
+
*  Segmenter interfaces cleaned up and updated to reflect modern usage.  All segmenter implementation classes updated to use the new interfaces.  This change was validated in 11.10 and did not affect APS (although it did slightly reduce code size and overhead).
 +
*  Updated resources and related classes such that separate FactorIndexers can be used for self and opponent instead of a single FactorIndexer for both.
 +
*  Fix bug in guess factor targeter class where some aim attempts could be ignored due to the failure to normalize the aim degrees.  This caused occasional delays in firing.
  
−
Positive movement, and highest rank yet, though only by a few places.  The update in this version is brilliant, but not a silver bullet.  Still a few areas I need to work on.
+
<i>XanderCat Updates</i>
  
−
== Version 3.8 ==
+
*  Added new bullet shielding mode to the component chain.  Feel the pain, boys!  (poor Hydra)
 +
*  Added new ramming mode to the component chain.  This is only used in very limited circumstances -- when the opponent is at very low energy and has stopped firing.  This adds insult to injury on opponents who are vulnerable to the new bullet shielding mode. (sorry, I can't help myself!)
 +
*  Turned off auto-fire on disabled opponents in the configuration.  XanderCat rams them now.
 +
*  History size increased from default of 80 to 120 (the default history size was occasionally too small).
 +
*  Fixed possible rare NPE bug in a couple of places where obtaining a robot history snapshot did not appropriately handle the rare case where a snapshot doesn't exist (one example where this can happen is a skipped turn resulting in missing a snapshot for self).
 +
*  Updating drive data roll parameters, including the use of a new non-linear roll function to replace the previous linear function.
  
−
Version changes:
+
==== Version 12.0.1 ====
−
*  Fire power. I haven't changed how I figure fire power since the beginning.  With version 3.8, I've finally tuned it.  This alone made enough of a change that I have decided to release it as a new version, without making any other changes.
 
  
−
== Version 3.9 ==
+
*  Fixed bug in bullet shielding scenario so scenario will disengage if the opponent is not firing any bullets.
  
−
Changes in this version:
+
=== Version 12.1 ===
−
*  Added new gun that takes care of a problem area.  The new gun specifically targets the factor the opponent was at on the previous shot.
 
−
*  Fixed bug of checking gunTurnRemaining() < really-small-number before firing (oops! it can return negative values for left turns -- need to take absolute value!)
 
−
*  Fixed bug that was making calculated timing of when my bullet waves hit the opponent inaccurate.
 
−
*  Fixed issue with hit ratio of Xander guns going down immediately on bullet fire (then back up if it hits); it now waits until the bullet either hits or misses before updating hit ratio numbers.
 
−
*  Fixed bug in wall smoothing gun segmenter.
 
−
*  Now handling bullet-hit-bullet when tracking my own bullet waves.
 
  
−
Areas that can still improve:
+
In this version, the bullet shielding components have been reworked to fix a number of problems.  You can tell version 12.0.x is not operating at full potential by comparing it's results to another bullet shielder like BulletCatcher.  I believe the new components, while still not perfect, are much improved.
−
*  Stat Drive?  I still don't have a good dive protection.  And I could potentially employ the dynamic segmentation approach I created for the Stat Gun, and adjust the segmentation for it as well.  I could also play with "flattening" again in special cases, but the approach would need to be sure-proof.
 
−
*  More analysis could improve things.  Possibly changing how data points get rolled off in the StatGun and StatDrive.
 
−
*  Fire power selection might could be tuned again, but for this version I left it as is to get a better idea of how the other changes play out.
 
  
−
=== Rumble Results ===
+
<i>Xander Framework Updates:</i>
 +
*  Add new AbstractGun class that implements Gun and handles the actual firing of bullets, leaving aiming up to subclasses.  Changed XanderGun to extend AbstractGun.  These changes make it easier to build guns when not utilizing XanderGun.
  
−
Moved up in the ranks some.  How much of it was my bug fixes and how much of it was the new gun is hard to say.  GeomancyBS and BulletCatcher results were interesting.  Possible bug causing my bot to disable?  I'll have to investigate it.
+
<i>XanderCat Updates:</i>
 +
*  Change parameter for BulletShieldingScenario condition 1 so that scenario will activate immediately on start of round, rather than allowing 20 or so ticks for IdealPositionDrive to improve positioning.  I'm still not sure which way is better.  In my initial testing, it was a wash either way.  If shielding right away, you can successfully shield against more opponents, but it takes away a little score from opponents who cannot be shielded against.  I need a lot more testing to refine which way is better.  For now, because it will be more interesting, I'm going with immediate shielding activation.
 +
*  Change BulletShieldingScenario condition 3 to check for ((time - lastOpponentFireTime) < 250) instead of (opponentBulletsFired > 0).  This condition is for handling opponents who are not firing bullets, and the change fixes it to work at any time in the battle instead of just checking the beginning of the first round.  This fixes the survival anomaly against ad.last.Bottom, and could potentially apply to other opponents under various special conditions.
 +
*  Change BulletShieldingScenario condition 7 to use opponent bullet power cutoff of 0.2 instead of 0.3.
 +
* Change BulletShieldingScenario condition 8 to use shielding shot cutoff of 20 shots instead of 10.
 +
*  Change bullet shielding drive strategy to standing still when opponent is moving at the time they fire (as in previous version), but shifting position when opponent is standing still at the time they fire.  (Why???? Why does it work this way????  Whatever.)
 +
*  Fixed a couple of bugs related to using getDistanceRemaining() with bullet shielding control sequence.  The only real impact with my current usage is that it prevents the possibility of a brief "runaway robot" when switching from some other scenario to the bullet shielding scenario.
 +
*  BulletShieldingScenario now ensures that bullet shielding components are properly reset to initial condition when scenario is deactivated and then reactivated later.
 +
*  Created new BulletShieldingGun (that extends the new AbstractGun).  It replaces the BulletShieldingTargeter and BulletShieldingPowerSelector used previously.  For bullet shielding, the aiming and power selection are too closely intertwined to continue using a separate targeter and power selector approach like I use for other guns.
  
−
:LOL.  No bug with BulletCatcher or GeomancyBS.  My guns appear to be newly vulnerable to bullet shielding, likely due to some of my bug fixes.  Pretty funny really.  I will make sure it's fixed in the next version. [[User:Skotty|Skotty]] 22:08, 13 June 2011 (UTC)
+
Some interesting shielding notes:
 +
* My shielding doesn't work against a few opponents, like Phoenix, but those same opponents can be shielded by other bullet shielders.  Why?  More research needed.
 +
* For a few opponents, shielding only works if the shielder stands still from the very beginning (note my change to shielding condition 1).  Some examples of this include Engineer (definitely) and SniperFrog (I think).  XanderCat 12.0.x will move to improve it's position in the first 20 ticks or so before stopping to try to shield.  This apparently pollutes the data Engineer is collecting rendering shielding ineffective.  More testing is needed to determine if it is better over the entire rumble to improve positioning as in XanderCat 12.0.x or to hold still, risking worse positioning against the greater field for the benefit of a few shielding vulnerable opponents like Engineer.
 +
*  The new BulletShieldingGun (that extends AbstractGun) that I created can adjust fire power to try to hit opponent bullets at a time midpoint.  However, if the required power adjustment exceeds a set threshold (currently 0.2), it just falls back to using power 0.1.  In some initial testing, the power adjustment was only occurring on about 7% of shots.  I don't expect this feature to provide a noticeable benefit, so I've opted to leave this function off for XanderCat version 12.1.  I may throughly test it out for potential use in a later version however.
  
−
== Version 4.0 ==
+
=== Version 12.2 ===
  
−
Since this version goes back to working on the drive instead of the guns, and since XanderCat is quite a bit different from where it was at version 3.0, I've decided to update the major version number.
+
* Fixed bug where opponent wave too close test in the bullet shielding controller was failing to correctly report when opponent was too close.  This bug is the main reason the previous version was losing to GeomancyBS, and was also hurting scores against other close fighting opponents.
 +
* Opponent too close test in the bullet shielding controller now factors in time remaining until gun cool when deciding if an opponent wave is too close to shield against.  This allows us to get out of the way sooner of any shot that cannot be shielded against due to waiting on the gun to cool.
 +
* Increased required lead time for an opponent wave from 6 to 7 ticks.
 +
* Add condition to stop trying to bullet shield for the rest of the battle if the opponent is repeatedly not firing first (more than 3 consecutive times in the same round)
 +
* When opponent is under 8 energy remaining, required distance from opponent is increased by a set amount. This is intended to prevent being hit by low power shots that cannot be shielded against and that other scenarios will not have enough time to dodge.
  
−
Changes in this version include:
+
=== Version 12.3 ===
−
*  "Dynamic" segmentation processing, developed originally for the Stat Gun, is now added to Stat Drive as well. This allows me to consider different segment combinations on the fly, rather than being locked into one segmentation combination.
 
−
*  Changed segmenters used in the stat drive to lateral velocity, relative direction, defender speed, and wall smoothing (wall proximity).
 
−
*  Increased stat drive bins from 47 to 87.
 
−
*  Added new bullet shielding protection gun.  This gun is just a wrapper (or decorator, in GUI terms) for other guns.  This gun wrapper detects bullet shielding and, when detected, shifts the position of the opponent "snapshot" a small random amount laterally (currently a distance of 5 to 10 in either direction).
 
−
*  When the opponent is in the way from reaching the "ideal position", the IdealPositionDrive now tries to drive around the opponent instead of through them.
 
−
*  Cleaned up framework in a few areas.
 
  
−
== Version 4.1 ==
+
This version focuses on enhancing/reducing CPU usage in hopes this will fix skipped turn issues and bullet shielding failures on some clients.
  
−
Changes in this version include:
+
* Moved some direct drive predictor function calls inline rather than calling methods on utility classes; this reduced function calls and reduced the number of objects created on some methods.
−
* Now using a fixed bullet power instead of variable. Takes an extra variable out of the equation.
+
* Updated direct drive predictor to perform fewer drive bounds .contains checks.
−
* Fixed bug in segmentation handling in the StatDrive where segments would get used before they had enough data points.
+
* Updated direct drive predictor to cache trig values for last heading rather than recalculate every time a drive state is advanced.
−
*  Changed gun segmenters (since I switched to fixed bullet power, and one of my previous segmenters was bullet speed, I figured I might as well swap them up a bit -- changed them to match what I am currently using in the drive)
+
* Removed a few log statements that get ignored anyway. This removes a few unnecessary String creations.
  
−
== Version 4.2 ==
+
=== Version 12.4 ===
  
−
Plans for this version include:
+
* Fix bug where missed shielding shot can go unnoticed. This could potentially happen repeatedly causing loss of round.   
−
*  Update segmentation processing on the stat drive such that the no-segmentation array is always considered as an option, rather than just being used as a backup early in the game when the segments are low on data points.  Will this improve my scores on the middle pack?
+
* Improve how lead time required for successful shielding is calculated.  This improves shielding against close fighting opponents.
−
* Updated fire power selection.  Fire power will remain at a constant level as in the previous version most of the time, but will jump up to maximum power at very close ranges where a miss is unlikely.
+
* Assume firepower of 0.1 for opponent shots fired when their energy is less than 0.1.  This seems to be how Robocode 1.7.3.x works.
−
* New Ram Escape Drive added to the "drive tree". This drive engages only when in very close proximity to the opponent, and attempts to back away in an intelligent manner.  It is targeted primarily at ramming robots or robots who like to crowd in as close as possible (e.g. as.xbots 1.0).  At such close ranges, wave surfing is rendered ineffective, resulting in roughly 50% scores.  The Ram Escape Drive intends to increase scores against such robots.
+
* Fix bug in linear intercept calculation where computed double value (one value minus another) is compared to zero.  Due to imprecise doubles, the correct behavior it to compare to ''almost'' zero.  This bug could result in the occasional firing of a bullet in a bizarre direction.
−
* Fix bug where XanderCat still fires a bullet when down to 0.1 energy.
+
* Fix bug where bullet shielding gun can get stuck (disabled) on a really low power bullet due to not being able to compute a linear intercept.
  
−
Drive tree for Version 4.2:
+
=== Version 12.5 ===
−
<pre>
 
−
              Ram Escape Selector
 
−
          /-------------^--------------\
 
−
  Ram Escape Drive              Anti-Mirror Selector
 
−
                            /-------------^---------------\
 
−
                    Anti-Mirror Drive              Active Bullet Waves Selector
 
−
                                              /-----------------^----------------\
 
−
                                  Ideal Position Drive                    Advanced Stat Drive
 
−
</pre>
 
  
−
Gun tree for Version 4.2
+
<i>Framework Updates</i>
−
<pre>
 
−
          Opponent Disabled Check
 
−
        /-----------^------------\
 
−
Head-On Gun              Bullet Shield Protected Wrapper
 
−
                                        |
 
−
                              Anti-Mirror Selector
 
−
                              /--------^----------\
 
−
                  Anti-Mirror Gun            Virtual Hit Ratio Selector
 
−
                                  /-----------/----------^-----\--------------\
 
−
                            Linear Gun    Circular Gun      Stat Gun*    Advanced Stat Gun                     
 
−
</pre>
 
−
* The basic Stat Gun is configured specifically to target the last guess factor where an opponent was seen.
 
  
−
I also plan to investigate more middle-pack opponents to try to determine where XanderCat can improve. This might result in a few other changes.
+
* Add new checks of velocity and gun cool time to try to avoid registering an opponent wall hit as firing a bullet.
 +
* Bullet Shielding Gun updated to allow for multiple opponent targeting types.
 +
* Bullet Shielding Drive now moves only a tiny amount when moving to shield against a stationary opponent.
  
−
== Version 4.3 ==
+
<i>XanderCat Updates</i>
  
−
Changes from the previous version:
+
* Add secondary targeting type to the Bullet Shielding Gun. (same as is used in Spitfire)
 +
* Ideal Position Drive will now hold position instead of driving to center of battlefield when no opponents remain.
 +
* No longer ram disabled opponents when shielding.
  
−
*  Fixed issue with advanced stat gun segments not being properly balanced based on data load.
+
=== Version 12.6 ===
−
*  Advanced stat gun segments must now have a certain number of data points before being used.
 
−
*  Advanced stat gun no-segmentation array is now a valid option at all times.
 
  
 +
<i>Rednaxela's KD Tree Update:</i>
  
 +
* Updated Rednaxela's 3rd gen KD Tree so that the heaps returned from a search have methods to directly access the data and keys by index.  This was done to support multiple iterations through the same data of a KD Tree search.  Data accessed in this manner is not returned in order (I don't need it to be; I just need to be able to iterate through the data multiple times without having to re-execute the same search; this is handled by my CachingLogReader and is utilized when there are multiple guns or drives using the same KNN parameters).
  
−
== Version 4.4 ==
+
<i>Framework Updates:</i>
  
−
Changes from the previous version:
+
* Expanded auto fire on disabled opponents functionality such that conditions can be specified for when auto fire is allowed.
 +
* Reworked how opponent gun fire detection works when opponent has collision with wall.  If opponent is assumed to have gun heat remaining, assume no bullet was fired unless the previous shot happened on a known collision.  A known collision is any time a velocity change exceeds the maximum deceleration rate.  If no heat remaining on a known collision, assume a bullet was fired, but skip the gun heat check the next time an energy drop is detected.  There is no way to know for sure what the bullet power is, so assume the bullet power is the same as the previous shot.  The following possible errors remain from this approach:
 +
** A slow collision when gun heat is 0 will not be detected as a collision.  This will result in a false wave.  Furthermore, the next real wave will likely be missed as the system will assume a shot could not have been fired due to assumed gun heat remaining after the previous wave.
 +
** A correctly detected collision when gun heat is 0 will assume a bullet of the previous fire power has been fired.  It may be that no bullet was fired, or possibly a bullet with a different firepower.  I don't see any way to resolve this.  However, the next wave should not get missed if no bullet or a lower power bullet was fired because the system skips the gun heat check for the next wave after a collision.
 +
* Saving the number of battles for each individual opponent and the total battles for all opponents to the battle statistics file is now a function of the framework.  This data is only saved if the robot is saving other information to the battle statistics as well.
 +
* Robots can now have the framework save gun, drive, and radar run times to the battle statistics file using settings in the Configuration.
 +
* Added utility method to the BattleStats class to simplify saving averages to the battle statistics file.
 +
* Updated getActiveGunName() in AbstractXanderRobot to return the disabled robot gun name when the disabled robot gun is in use.
 +
* Updated Graph Data and CPU Utilization painting to allow graph to be resized, fix a bug in the data end points, and allow CPU constant to be graphed.
  
−
*  Finally implemented dive protection (score on Barracuda up from about 95% to about 98%).
+
<i>XanderCat Updates:</i>
−
*  Fixed bug where the number of data points for a segment in the stat gun / advanced stat gun was being calculated incorrectly.
 
−
*  Fixed bug with Bullet Shield wrapper not propagating call to initialize wrapped gun for new round.
 
−
*  Added bias to the virtual hit ratio gun selector such that linear gun is only used if it's virtual ratio is at least 5% better than the other guns. (this may be modified again before this version is released)
 
−
*  Changed segmentation on main gun and drive to use defender relative direction, defender speed (positive only), bullet travel time, and wall smoothing (wall proximity).
 
−
*  Added minor negative danger (-5% of what gets added for a hit) in the stat drive for factors when XanderCat doesn't get hit.  Not sure if this is a good idea or not overall, but it makes sense to me.  It means if XanderCat keeps going to the same factor, the opponent would have to get above a 5% hit ratio at that factor for XanderCat to go somewhere else.  Works well on an opponent like Barracuda who might occasionally get in a lucky hit.
 
  
−
== Version 4.4.1 ==
+
* Revise generic KNN log reader to return a data iterator instead of a data point list.  This should mostly eliminate the massive overhead of creating a List for each read when using Rednaxela's KD Tree in order to match the interface.  This will also make data point KD Tree distance available on each point, something previously unavailable that could improve performance if used when filling the factor arrays.
 +
* Use KD Tree distance for each point to adjust the weight of data points in the constructed factor arrays.  This is done for the drive only (affect had no statistical significance when tested on the guns).
 +
* Adjust KNN selection parameters on the drive from (1, 30, 0.3) to (10, 40, 0.4) where values are (minK, maxK, K growth rate)
 +
* Start recording drive and gun run time stats in the saved battle statistics file.
 +
* Auto-fire on disabled opponents turned back on, with condition that if the bullet shielding gun is active, there must be no active opponent waves.  Ramming will now only be used on low energy opponents who have stopped firing but are not disabled.
 +
* Fix issue where shielding vulnerable opponents repeatedly get too close to shield against.  This was fixed by switching to using a disengage distance and a re-engage distance, rather than a single required distance check.  This keeps the bullet shielding scenario from bouncing on and off against opponents who keep nudging closer.
 +
* Add workaround for rare bug where bullet shielding system gets stuck with the drive in the Firing state but the gun requesting a wave to shield against.  Previously the controller would just return null when a wave was requested if the drive wasn't in Standing state.  This is now updated so that if a wave is requested when the drive is in Firing state, the controller requests the drive return to Standing state (normally this happens when the gun fires, but somehow this fails on rare occasions).
 +
* Update move to standing steps in the drive to immediately switch to Standing state if the drive shift was 0.  This saves an extra tick on most shielding shots.  This was previously done for the move to firing step, but was previously overlooked for the move back to standing.
  
−
Changes from the previous version:
+
=== Version 12.7 ===
  
−
*  Fixed bug that was causing stat gun no-segmentation array to never be used.  This was rendering the basic stat gun targeting the last factor completely ineffective.
+
Work on this version was stalled for months but is underway again as of mid November, 2013.  Probable release in late November.
−
* Fixed issue in how ram escape drive attempts to dodge bullets.
 
  
−
=== Rumble Results ===
+
This version focuses on managing garbage collection.  The amount of garbage collection going on is causing lots of skipped turns on some clients in the first round, which is seriously compromising the effectiveness of my shielding components.
  
−
Amazing how many differences there are with the "last factor" gun working again.  While the last factor gun works well on certain opponents, it's presence seems to interfere with the performance of the advanced stat gun.  Perhaps what I need to do is add a "bias" to the last factor gun, where it does not get used unless it's virtual hit ratio exceeds the advanced stat gun virtual ratio by a certain margin.  Especially in the early rounds where the advanced stat gun is still learning.
+
* Create and utilize new mechanism for managing garbage (particularly in the first round).  Current strategy is to use a new "waste basket" to hold onto old objects and delay garbage collection until non-critical times (object pooling was another strategy considered but is not favored at this time).  This occurs until round 3.
 +
* Initial objects selected for management include Snapshots and Waves.  This was calculated out to be about 2000 objects per round that are thrown away and garbage collected.
 +
* Add new condition for bullet shielding scenario to handle situations where shielding is not sufficiently effective on a round (shielding will shut off for current round only under this condition).  This should fix a shielding vulnerability that was occurring against certain mirror bots from suh (the problem turned out not to be with the anti-mirror components, but rather with the bullet shielding components).
  
−
The only other change this vesion was a change to the ram escape drive, to make it dodge bullets a little better.  While this worked well on opponents like GubbmThree, it also worked a little worse in at least one case (as.xbots).  I'll have to review this to see if it was just a matter of chance or if the ram escape drive needs more tweaking.
+
=== Version 12.8 ===
  
−
:On further analysis, it appears the rank differences are not just a result of the last factor gun coming back online.  It's a combination of factors that results in slightly different results against the same opponents.
+
The attempt to fix the garbage collection problem using the "waste basket" approach in version 12.7 was a failure.  I can tell this pretty easily by comparing XanderCat against Spitfire.  Therefore, version 12.8 will take a new approach to fixing the problem.
  
−
== Version 4.5 ==
+
After more research, it appears as though the problem caused by the skipped turns is not so much with timing (or insufficient time) causing shielding misses, but rather a problem with how opponent wave objects are created when the opponents bullet was fired on a skipped turn!  Fixing this may be enough to make the shielding work even with the missed turns, plus there may be a latent benefit of eliminating/reducing tracking errors in general.  Therefore...
  
−
Changes from the previous version:
+
Changes in this version include:
−
 
+
<i>Framework Changes</i>
−
*  Xander framework updated to track rolling virtual hit ratios, configurable through the '''Configuration''' class.  XanderCat makes use of this through the '''VirtualHitRatioGunSelector''' for choosing a primary gun.  The '''VirtualHitRatioGunSelector''' looks at both the overall virtual hit ratio and the rolling virtual hit ratio.  XanderCat currently weights the rolling ratio at 60% and overall ratio at 40% (subject to change before release).
+
*  Removed the "waste basket" utility.
−
*  Bullet fire power now ranges from 1.8 to 2.4 dependent on overall hit ratio on opponent.
+
* Added a skipped turn simulator that can be used during testing.
−
*  Disabling self with bullet shot is now allowed if opponent is already disabled.
+
<i>XanderCat Changes</i>
 +
* Updated created wave objects from opponent bullets fired when scans are missed (for example, if there are skipped turns) to flag them as estimated (the system doesn't know exactly on what scan the bullet was fired because we don't have back to back scans).
 +
*  Bullet shielding controller no longer accepts estimated opponent waves as valid waves to shield against. This won't prevent hits on us but will prevent a hit from an estimated wave from being seen as a shielding failure (as it's really a scan failure).
 +
*  Adjusted shielding energy level condition for shielding scenario to accept reduced effectiveness on first couple of rounds to account for skipped turns early in the game (I didn't fix the skipped turns problem, I just worked around it).
  
−
== Version 4.5.1 ==
+
=== Version 12.9 ===
  
−
Changes from the previous version:
+
Kind of wrecklessly throwing this version out there without solid vetting. :-P
  
−
*  Fixed bug where overall hit ratio was not getting carried over from round to round.
+
*  Fix some bullet shielding failures.
 +
*  Remove ram scenario.  XanderCat will no longer try to ram low energy opponents who are not firing.  The movement was degrading bullet shielding effectiveness due to opponent data pollution.
  
−
== Version 4.6 ==
+
These are battles that XanderCat should be able to successfully bullet shield against (screenshot from RoboJogger)
 +
[[File:skotty-xandercat-bs-failures.png]]
  
−
This version adjusts fire power selection and focuses on improving distancing.  Changes from the previous version:
+
Note:  Nothing I can do about Seraphim.  After some analysis, I discovered that XanderCat's bullet shielding strategy is not flawed on Seraphim; rather, Seraphim is actively countering it against XanderCat specifically.  I'll exclude him from further analysis.
−
* Bullet fire power range adjusted to be from 2.0 to 2.5 (from 1.8 to 2.4).
 
−
* Stat drive now retreats away from opponent rather than away from bullet wave when inside of optimal range.
 
−
* Stat drive now advances on opponent some when outside of optimal range.
 
  
−
Opponent scan for retreat/advance is currently from the moment wave being surfed changes; it does not presently update on the fly, as the design doesn't currently support it. Nevertheless, using the opponent scan should be better than using the wave origin.
+
UH OH! At least one bot I broke XanderCat against.  12.2 APS on one battle against simonton.mini.WeeksOnEnd 1.10.4.  Well, that's what happens when you have a multi-mode bot you don't test well enough before releasing to the rumble.  Doh!  Hopefully the improvements against other bots make up for it.
−
 
 
−
== Version 4.7 ==
 
−
 
 
−
Changes from the previous version:
 
−
 
 
−
* Introduction of a Simple Targeting Drive, targeted primariliy at increasing scores against simple linear targeting, though it is also designed to work against head-on targeting. The advanced stat drive works fine against head-on targeting, but underperforms against simple linear targeting (achieving only around 75% against linear targeters, whereas over 90% is a reasonable expectation for an intelligent robot). Are there many linear targeters out there?  Well...I know of at least one, so might as well take it into consideration.  Simple Targeting Drive stays online so long at hit ratio against it does not exceed 9%.
 
−
*  Refactored a lot of my wave surfing and guess factor code to use common components where ever possible.  I had already done this with Segmenters in the past, but I'm now doing it with various other tasks as well, like determining reachable factor ranges, converting between factor angles and factor indexes, distributing weight within a factor array, and choosing best factors within an array.  While I could have introduced bugs by doing this, in the long run it should decrease the likelihood of bugs, eliminate code duplication, make it easier to develop new guess factor components, and reduce overall code size. 
 
−
 
 
−
A note on distributing weight within an array:
 
−
 
 
−
XanderCat 4.7 uses a '''WeightDistributer''' interface for it's guess factor guns and wave surfing drives.  This allows the means for weight distribution within an array to be interchanged easily.  At the moment, I have 3 different weight distributers:  Triangle Distributer (used in XanderCat's guns), Wave Distributer (used in XanderCat's drives), and Point Distributer (currently unused).
 
−
<pre>
 
−
Point Distribution    Triangle Distribution      Wave Distribution
 
−
 
 
−
        X                                                  X
 
−
        X                        X                        X
 
−
        X                      X X X                    x X x
 
−
_ _ _ _ X _ _ _ _        _ _ X X X X X _ _      . x x X X X X X x x .
 
−
</pre>
 
  
−
== Version 4.7.1 ==
+
=== Version 13.0 (planned) ===
  
−
Changes in this version:
+
* Switch to updated Xander Framework v3.
 +
* Fix an exploitable vulnerability in the tracking systems.
 +
* New statistics-based distancing technique for surf drives.  This is actually somewhat revolutionary for XanderCat -- not just a tweak -- and it will give the drive far more authority to adjust distance than it has ever had before, from maintaining max distance possible all the way up to essentially ramming (a point of interest that I just removed the Ram drive components in the prior version, but this change would bring similar behavior back as a possibility).  Will require some thorough testing prior to release due to the significance of the change.
 +
* Fix bug in wave surfing framework that could result in NullPointerException.
 +
* Tweaks to fix whatever corner cases I might have broke in 12.9.
 +
* TBD
  
−
*  Fixed NPE bug in refactored method for getting reachable factor ranges.
+
=== Future Version Possibilities ===
  
−
== Other Versions ==
+
<b>Possible Features</b>
  
−
I may release various other minor versions that are just tweaks and bug fixes.  There are a number of configurable parameters I could play with.  I might also update it specifically for melee and enter it in the melee rumble.
+
*  Update gun data roll procedure.
 +
*  New drive system for wave surfing?  This was tested and so far has not proved advantageous, so the likelyhood of it making it into the final version is dropping.
 +
* Add 2 new segmenters to the guns.
 +
* Possibly update how danger is modified based on distance.
 +
*  Figure out how to pummel PrairieWolf.
 +
*  Add tracking of certain types of "errors" to help with improvements (for example, keep and report on a count of how often the robot runs into walls, or fails to reach it's intended location)
 +
*  Modify segmenters?
 +
*  For logged battle stats against each opponent, instead of keeping a single average for stat values, keep two sets of stat values:  one for the best battle against them, one for the worst battle against them.
 +
*  Segmenter changes? (possibly a new type of segmenter)
 +
*  Try out a "performance-based distancing equation"?
 +
*  Implement several speed improvements?
 +
*  Maybe tweak some other parameters?
 +
*  Improve bullet shielding protection?

Latest revision as of 00:32, 9 April 2017


XanderCat
XanderCatLogo-small.png
Author(s) Skotty
Extends AdvancedRobot
Targeting GF / Linear / Circular / Anti-Mirror / Bullet Shielding
Movement WS(GoTo) / Anti-Mirror / RamEscape / Ram / IdealPosition
Released 2011-5-20 (v 1.0)
Best Rating #4/5/6 (v 12.8)
Current Version 12.9
Code Size 58,581 (lol)
Code License GCWCD
Download

Introduction

MegaBot based on my Xander Robot Framework with pluggable guns, radars, and drives. XanderCat is the flagship of my robot fleet. It is a multi-mode robot using multiple guns and drives organized into a component chain. It's main gun is a guess factor gun, and the main drive is a wave surfing drive (GoTo-style), but a number of other guns and drives exist for special situations. Both the main gun and drive are currently using a hybrid form of dynamic clustering. The drive is somewhat unique in that it decides where it wants to go and goes there directly (no orbiting -- though the path still is somewhat orbital in nature due to MEAs and distancing -- and no wall stick while driving). XanderCat also makes use of my Xander Painting Framework for development and debugging.

(*) As of 2013, version 12.6 was ranked #7 in the rumble, but can rank as high as #5 if a solution for the first round garbage collection problem can be implemented. It is unusual to have a garbage collection issue in Java, but Robocode is an unusual game. On some platforms, garbage collection in the first round can cause multiple skipped turns on large robots that create a lot of objects. This is true for XanderCat. XanderCat is further affected by this issue because it causes the bullet shielding mode to fail some of the time, when otherwise it would have worked.

Best against: Generally a good performer; probably most notable for having simple yet effective anti-mirroring capabilities.

Worst against: Currently DrussGT, Diamond, and Tomcat are still quite deadly to XanderCat.

Favorite Robots To Beat:

  • lazarecki.mega.PinkerStinker 0.7 - because I don't like it's name.
  • da.NewBGank 1.4 - because of it's name and because it can be beat by a large margin by exploiting a "newbie" bug in it, which is pleasantly ironic.

Past Version Notes: For information on versions prior to the current series, see the XanderCat/History page.

Name Origin?

Xander comes from my son's name Alexander. Cat was originally meant to be of the feline variety, as I like cats, have used the term in other software projects, and it seemed appropriate. Cat could also be associated with the tractor variety, which I think also works (a tractor with a gun), and I'm fine if people make that association too.

Hybrid Dynamic Clustering?

XanderCat uses Dynamic Clustering (DC) in the sense that data about past waves is stored in a tree structure. For each wave, past data is pulled from the tree that as closely as possible matches the current situation, and that data is used to decide where to aim or drive. However, once the data is pulled, how to use it differs from classic DC. In classic DC, some form of kernel density algorithm is used to determine what to do. In the XanderCat hybrid approach, it behaves more like VCS, in that the data is logged into a factor array, and that array is surfed in the GoTo style.

Surfing Multiple Waves?

Starting with version 9.5, XanderCat now surfs up to 2 waves at a time. The general approach is as follows:

  1. Calculate the first n best factor angles to drive to for the next wave to hit, each of which must be separated by a given amount. Each has an associated danger value.
  2. From the end points of the n factor angles, continue to predict into the future surfing of the second wave to hit. For the second wave, only the best factor angle is used.
  3. Add the first wave danger value to the corresponding second wave danger value for both the factor angles of the first wave. Choose which first wave factor angle to drive to by which has the lowest combined danger value. (Note: The calculation is a little more complicated, taking wave distance and bullet power into account, but the basic idea is the same.)

Note the image below, where:

  • a = reachable factor range for first wave
  • b = minimum distance that must exist between choices
  • c = first choice for surfing first wave
  • d = second choice for surfing first wave
  • e = current robot position

If the sum of the danger values represented by orange lines was less than the sum of the danger values represented by the red lines, the second choice for the first wave would be used.

Skotty-2wsrf.png

Saving Data Between Battles?

XanderCat does save data between battles, but that data is not used by the robot and does not effect performance any. It is collected solely for my own analysis. It helps me find problems and decide on where improvements are needed. I also just like statistics. Of course, I only get statistics on battles run by my own machine. Below is an example some data it collected:

Key:

  1. Opponent = Opponent robot name and version
  2. G1 Shots = Shots taken by the main guess factor gun
  3. G2 Shots = Shots taken by the Anti-Scarlet guess factor gun
  4. CD Scenario = Percentage of time the CircularDriverScenario was applied against the opponent
  5. PD Engage = Number of times my bullet fire power was dropped (see v10.21 notes for what this means)
  6. Flattener = Percent of total time the flattener was engaged
  7. My HR = My overall hit ratio
  8. Opponent HR = Opponent overall hit ratio
Opponent G1 Shots G2 Shots CD Scenario PD Engage Flattener My HR Opponent HR
techdude.kombat.FlamingKombat 1.5 8 62 78.5% 0 0.0% 73.5% 3.4%
test.Fuzzer 1.0.1 449 13 0.0% 0 0.0% 60.6% 9.9%
test.Podgy 4.0 465 387 0.0% 0 0.0% 22.0% 7.2%
throxbot.ThroxBot 0.1 747 12 0.0% 0 0.0% 30.9% 5.5%
tide.pear.Pear 0.62.1 806 490 0.0% 10 7.0% 13.0% 11.2%

In addition to saving data on each robot, it can save a generic set of data about performance against the field as a group. As an example, to get an idea of early, mid-game, and late game performance, I log the number of round wins for each round. Example (to keep the table short, I left out rows for rounds 3 through 31):

Round Wins % Wins
0 615 88.9%
1 630 91.0%
2 613 88.6%
...
32 644 93.1%
33 654 94.5%
34 644 93.1%
Total 692

Multi-Mode Scenarios / Component Chain

Component Chain: 

Default --> Basic Radar
  |
  v
BulletShieldingScenario -> Bullet Shielding Drive, Bullet Shielding Gun
  |
  v
RamEscapeScenario --> Ram Escape Drive, Linear Gun
  |
  v
AntiMirrorScenario --> Anti-Mirror Drive, Anti-Mirror Gun
  |
  v
NoBulletWavesScenario --> Ideal Position Drive
  |
  v
CircularDriverScenario --> Circular Gun
  |
  v
Defaults --> Guess Factor Gun Array, Drive Array
                     |              ______|_______________
                     |             /                      \
                     |  Targeting Detector Drive    Main Wave Surfing Drive
           __________|___________
          /                      \
   Original Gun           Anti-Surfer Gun

Ram Low Energy Scenario (not currently in use)

This scenario attempts to ram the opponent if the opponent is at low energy and has stopped firing bullets. Should the opponent who stopped firing bullets suddenly fire a bullet at close range during the ram attempt, the low energy cutoff can be reduced further (fool me twice, shame on me). Also, this scenario will only engage if our own robot is over some minimum energy level threshold.

To ram the opponent, the ram drive uses three approach methods depending on distance from opponent. At far distances, the ram drive will just drive directly at the opponent. At short distance, the ram drive uses a linear intercept. At intermediate distances, the ram drive uses a blending of the two.

Bullet Shielding Scenario

This scenario attempts to use bullet shielding against the opponent. The bullet shielding components basically follow the standard approach, except I didn't bother trying to make the bullet lines cross at their segment midpoints, so there may be an improvement to make there some day? Determining when to use this scenario is a bit complex, and includes 9 different conditions that must be met for the scenario to apply.

Ram Escape Scenario

This scenario applies whenever the opponent appears to be ramming. At present, this works be simply testing the opponent's distance being under some threshold. This sometimes happens against robots who are not really ramming -- this can happen due to initial round positioning, or just due to drive paths that happen to run too close together -- but in these cases there is no real disadvantage to using the ram escape scenario to back away from the opponent. This distance of ram detection will increase the more the ram scenario is applied. This makes the ram escape scenario kick in sooner and more often against the real rammers who ram consistently.

When this scenario is applied, a Ram Escape Drive is paired with a linear targeting gun. At present, this is the only place in which I utilize linear targeting in a gun. The Ram Escape Drive attempts to drive away from the enemy as much as possible, and uses turning to try and dodge some of the opponents shots (for example, it may change the direction of turn at the moment an opponent shot is detected).

Anti-Mirror Scenario

This scenario applies whenever the opponent appears to be using a mirroring drive strategy. The countering technique is to plan a drive path into the future such that it is known where to shoot in order to hit the mirrored position in the future. At present, this can be fooled by creative mirrorers that utilize a delay or position shifting.

No-Bullet-Waves Scenario

This scenario applies whenever the opponent has no bullets in the air (note: this can happen often with a rammer, but the ram scenario happens earlier in the component chain and thus supercedes this scenario). When the opponent has no bullets in the air, the Ideal Position Drive takes over and moves the robot directly to what it perceives as the ideal position on the battlefield given the battlefield size and the current position of the opponent.

I've attempted to replace this somewhat crude drive a few times, but each time resulted in a lower overall score in the RoboRumble, giving rise to the idea that this drive is imbued with magical powers.

Circular Driver Scenario

This scenario doesn't affect overall performance much, but it does two things that make me feel better: first, it brings back my circular gun, which otherwise would not be in use. I once spent a lot of time on it, and would like it to be used somewhere. Second, it makes me feel better when pitted against simple circular drivers like SpinBot, where my guess factor gun still misses quite a few shots, but my circular gun can hit nearly every time.

To make this scenario as effective as possible without degrading any performance elsewhere, it is not enough for an opponent to appear to be moving in a circular path at the time a shot is taken. The opponent must have been moving (and still be moving) in a consistent circular path. Furthermore, that path must not intersect any walls before the shot would reach them. The circular movement path is predicted into the future until the bullet would arrive to check for this. (Note: Using prediction for this is not really a good idea; I should have just checked the bounds of the circle. I will make this change in some future version.)

Default Gun Array

The gun array consists of several guess factor guns. This is not too computationally expensive because they are currently all using the same cached copy of data. They just use the selected data differently when building the factor array to use for aiming. The Anti-Surfing Gun uses a certain amount of data rolling. This technique was first implemented to counter Scarlet, who at one time was trouncing my robot far worse than any other, and was thus for awhile named the Anti-Scarlet gun.

Default Drive Array

The drive array consists of two drives: what I currently call the Targeting Detector Drive and the Main Wave Surfing Drive. Both drives are direct wave surfing drives. They just differ in what data they use to surf. I use the term direct to indicate how the drive moves the robot; the robot is moved at a fixed angle until it reaches the desired surfing factor angle for the current wave, in essence moving there directly in as straight a line as possible rather than using an orbital path. However, in action, it may still appear to use a somewhat orbital path, as where to move is recalculated for the same wave under various conditions -- such as when the waves are updated due to new bullet shadows, or the opponent moves too far away from it's predicted path.

Main Wave Surfing Drive

This drive uses Dynamic Clustering with a KD Tree for it's data management. A simple equation is used to determine how many nearest neighbor data points to pull, and those points are logged into a factor array to surf.

Targeting Detector Drive

This drive uses a combination of targeting detectors that are designed to detect specific types of targeting. Each targeting detector can add a data point to the factor array, with the data point weight based on how often the detector thinks it is detecting it's specific form of targeting. This system is designed to improve scores against robots that use predictable targeting (non-guess-factor), something I have had trouble getting my main wave surfing approach to handle as well as other top robots.

Bullet Shielding Protection

All main guns are wrapped by my BSProtectedGun wrapper/decorator class. It is a different animal from my original version. My original version shifted the target's position slightly to avoid perfect aim shots, a technique that works well against the basic shielder's such as uCatcher. However, it was generally ineffective against moving shielders like MoxieBot. At the same time, my normal aiming technique for my latest guess factor guns is not vulnerable to the stand-still shielders (by chance more than design). Therefore, the latest incarnation of my BSProtectedGun attempts to handle shielding using a new strategy that does not rely on shifted aims, and focuses more on protecting against on-the-move shielders.

When bullet shielding is detected, the BSProtectedGun will check the energy levels of both robots. So long as my energy level is more than the opponents, the BSProtectedGun will halt firing and wait for the shielding opponent to fire first, then the BSProtectedGun fires immediately after the opponent. This ensures that the opponent's shot is not a shielding shot. It is still possible that the opponent could fire a second shielding shot before the my shot reaches them, but in practice this hasn't been an issue. This could also fail against perfect shielders where my energy level never exceeds the opponent's, but again, in practice this hasn't been an issue. If it did ever become an issue, I would keep basically the same strategy, but start shifting target position again like in the original gun.

This strategy has an interesting yet not surprising result against MoxieBot. MoxieBot shields on the move, but the shielding is never perfect, and my robot can usually get the upper hand on energy at some point in the round. When this happens, my robot stops firing and waits for MoxieBot to fire first. However, MoxieBot in turn is waiting for me to fire before it fires, resulting in a stalemate where no one is firing. This in turn results in Robocode activating the stalemate energy drain. Neither robot incorrectly detects the energy drain as an opponent bullet, so the stalemate continues until the energy drain kills one of the robots. However, since my robot only stopped firing after getting the upper hand on energy, my robot gets the win. End result, a somewhat higher score against MoxieBot, and much higher survival.

To improve on this further, I am considering possibly using chase bullets when my energy level is less than the opponent's, which should make it harder for the opponent to shield.

Version Notes

Version Ranks

Note: Best Change and Worst Change are the change from previous version against the given opponent.

Note: Starting from version 6.4 onward in the table, I am ignoring nat.BlackHole 2.0gamma and nat.Samekh 0.4, as scores against them always fluctuate rather wildly.

Version 1-on-1 Rank Top Best Change % Score Change Worst Change % Score Change
1.0 ~475 / 805 59% N/A N/A N/A N/A
2.0 386 / 806 48% mld.Wisdom 1.0 4.18 -> 76.13 SuperSample.SuperCrazy 1.0 61.97 -> 37.00
2.1 320 / 805 40% dz.MostlyHarmlessNano 2.1 20.90 -> 63.01 jf.Dodger 1.1 78.98 -> 41.10
3.0 148 / 805 18% gg.Wolverine 2.0 41.08 -> 94.57 xiongan.Xiongan 1.1 100.0 -> 74.39
3.1 145 / 804 18% zyx.nano.RedBull 1.0 53.4 -> 85.3 pulsar.PulsarNano 0.2.4 89.3 -> 64.2
3.2 116 / 806 14% ags.polished.PolishedRuby 1 28.5 -> 83.5 rsim.micro.uCatcher 0.1 91.7 -> 31.8
3.3 115 / 806 14% nat.Samekh 0.4 24.9 -> 64.9 simonton.micro.GFMicro 1.0 62.2 -> 39.2
3.4 85 / 806 11% dsx724.VSAB_EP3a 1.0 67.2 -> 93.4 intruder.PrairieWolf 2.61 65.6 -> 48.4
3.5.1 94 / 805 12% rsim.micro.uCatcher 0.1 21.3 -> 96.4 nat.BlackHole 2.0gamma 69.2 -> 42.5
3.8 81 / 805 10% synapse.rsim.GeomancyBS 0.11 36.5 -> 49.8 mn.Combat 1.0 80.1 -> 60.8
3.9 75 / 805 9.3% pez.mini.ChironexFleckeri 0.5 42.2 -> 64.9 rsim.mini.BulletCatcher 0.4 57.7 -> 7.0
4.0 92 / 805 11% rsim.mini.BulletCatcher 0.4 7.0 -> 72.1 nat.Samekh 0.4 73.3 -> 45.2
4.1 74 / 805 (73.66 APS) 9.2% nat.Samekh 0.4 45.2 -> 75.7 staticline.whiskey.Whiskey 0.6 75.5 -> 57.5
4.2 74 / 805 (73.73 APS) 9.2% mladjo.iRobot 0.3 53.8 -> 69.9 jcs.AutoBot 4.2.1 60.1 -> 35.1
4.3 74 / 805 (73.92 APS) 9.2% kc.mini.Vyper 0.311 33.0 -> 53.0 positive.Portia 1.26e 60.0 -> 36.2
4.4 71 / 805 (74.11 APS) 8.8% pez.frankie.Frankie 0.9.6.1 45.9 -> 62.8 fromHell.CHCI3 0.1.4 74.4 -> 55.7
4.4.1 71 / 805 (74.11 APS) 8.8% brainfade.Fallen 0.63 45.7 -> 65.5 jam.micro.RaikoMicro 1.44 64.0 -> 49.8
4.5.1 71 / 805 (74.25 APS) 8.8% spinnercat.CopyKat 1.2.3 51.6 -> 69.3 synapse.rsim.GeomancyBS 0.11 54.4 -> 38.6
4.6 71 / 805 (74.35 APS) 8.8% deo.virtual.RainbowBot 1.0 54.8 -> 69.1 jab.DiamondStealer 5 80.6 -> 61.7
4.8 57 / 803 (76.46 APS) 7.1% ar.QuantumChromodynamics 1.2.1 69.2 -> 90.5 nat.BlackHole 2.0gamma 60.8 -> 42.0
5.0 70 / 805 (74.37 APS) 8.7% deo.FlowerBot 1.0 53.4 -> 84.6 kcn.unnamed.Unnamed 1.21 79.1 -> 58.0
5.1 49 / 815 (78.59 APS) 6.0% ary.SMG 1.01 35.5 -> 90.3 nat.BlackHole 2.0gamma 54.4 -> 33.0
5.1.1 49 / 815 (78.75 APS) 6.0% rz.Apollon 0.23 69.6 -> 94.0 nat.Samekh 0.4 72.7 -> 53.6
6.1.8 59 / 806 (76.65 APS) 7.3% cx.Princess 1.0 47.8 -> 65.1 toz.Gnome 1.1 88.4 -> 61.6
6.2 59 / 806 (76.84 APS) 7.3% nat.BlackHole 2.0gamma 42.1 -> 67.0 stelo.RamTrackSurfer 1.2 89.2 -> 72.9
6.3 56 / 806 (77.04 APS) 6.9% kid.Gladiator .7.2 47.7 -> 65.5 nat.BlackHole 2.0gamma 53.4 -> 33.3
6.4 51 / 806 (78.22 APS) 6.3% dmp.micro.Aurora 1.41 62.1 -> 79.1 myl.micro.NekoNinja 1.30 77.3 -> 61.3
6.5 48 / 808 (78.70 APS) 5.9% ncj.MoxieBot 1.0 76.9 -> 92.6 bayen.nut.Squirrel 1.621 89.3 -> 74.9
6.7 45 / 807 (79.17 APS) 5.6% apv.ScruchiPu 1.0 57.9 -> 79.5 trab.nano.AinippeNano 1.3 91.4 -> 74.7
6.8 42 / 808 (79.69 APS) 5.2% trab.nano.AinippeNano 1.3 72.2 -> 89.5 rampancy.Durandal 2.2d 81.5 -> 69.4
9.0 46 / 827 (79.73 APS) 5.6% N/A N/A N/A N/A
9.0.1 45 / 827 (80.03 APS) 5.4% ary.SMG 1.01 50.5 -> 76.4 ncj.MoxieBot 1.0 95.5 -> 75.5
9.1 43 / 828 (80.25 APS) 5.2% kc.mini.Vyper 0.311 54.7 -> 60.7 ab.DangerousRoBatra 1.3 74.0 -> 66.7
9.2 38 / 828 (80.84 APS) 4.6% Bemo.Sweet30 1.6.1 57.9 -> 68.3 kenran.mega.Pantheist 75.3 -> 57.1
9.3 34 / 829 (81.35 APS) 4.1% ags.micro.Carpet 1.1 76.3 -> 89.2 ary.SMG 1.01 81.2 -> 64.9
9.4 33 / 830 (81.55 APS) 4.0% kenran.mega.Panthiest 73.9 -> 85.3 bayen.nut.Squirrel 1.621 88.8 -> 80.9
9.5 30 / 830 (81.71 APS) 3.6% wiki.BasicGFSurfer 65.3 -> 75.5 rampancy.Durandal 2.2d 80.3 -> 67.6
9.6 28 / 830 (81.91 APS) 3.4% darkcanuck.Gaff 1.50 43.3 -> 52.4 kenran.mega.Panthiest 1.1 89.6 -> 78.9
9.7.1 25 / 832 (82.05 APS) 3.0% rampancy.Durandal 2.2d 77.8 -> 88.3 brainfade.Fallen 0.63 64.0 -> 57.0
9.8 25 / 832 (82.12 APS, 1600 PL) 3.0% asm.Statistas 0.1 70.4 -> 77.1 wcsv.PowerHouse.PowerHouse 1.7e3 53.9 -> 46.8
9.9.5 24 / 831 (82.37 APS, 1604 PL) 2.9% ncj.MoxieBot 1.0 74.9 -> 86.0 cx.mini.Cigaret 1.31 64.9 -> 55.2
9.15 20 / 833 (82.74 APS, 1646 PL) 2.4% janm.Jammy 1.0 75.2 -> 91.4 davidalves.net.DuelistMicro 1.22 72.1 -> 63.8
10.13 19 / 837 (82.98 APS, 1658 PL) 2.3% whind.StrengthBee 0.6.4 56.8 -> 67.8 rc.yoda.Yoda 1.0.6c.fix 74.6 -> 63.9
10.15 19 / 837 (83.11 APS, 1658 PL) 2.3% cf.proto.Chiva 2.2 61.5 -> 68.0 florent.XSeries.X2 0.17 62.3 -> 56.7
10.18.1 16 / 837 (83.20 APS, 1656 PL) 1.9% jab.avk.ManuelGallegus 0.6 70.4 -> 82.1 dft.Virgin 1.25 73.6 -> 63.2
10.22 16 / 837 (83.59 APS, 1664 PL) 1.9% voidious.mini.Komarious 1.88 54.4 -> 65.8 robar.micro.Topaz 74.1 -> 65.5
11.0 10 / 840 (84.26 APS, 1668 PL) 1.2% florent.XSeries.X2 0.17 58.6 -> 70.0 ary.micro.Weak 1.2 68.1 -> 58.4
11.3 9 / 841 (84.41 APS, 1674 PL) 1.1% pez.micro.Aristocles 0.3.7 67.6 -> 74.3 brainfade.Fallen 0.63 70.5 -> 64.8
11.4 10 / 953 (84.92 APS, 1888 PL) 1.1% ags.micro.Carpet 1.1 80.3 -> 85.1 abc.Shadow 3.83c 54.9 -> 48.4
11.5 10 / 953 (84.94 APS, 92.52 S, 1890 PL) 1.1% Unavailable Unavailable
11.6 8 / 953 (85.14 APS, 92.73 S, 1890 PL) < 1% Unavailable Unavailable
11.16 9 / 971 (85.21 APS, 92.97 S, 1928 PL) < 1% Unavailable Unavailable
12.0.1 8-9 / 971 (85.54 APS, 93.38 S, 1934 PL) < 1% kc.serpent.Hydra 0.21 60.4 -> 97.3 dsx724.VSAB_EP3a 1.0 98.2 -> 77.4
12.1 7 / 972 (86.09 APS, 93.89 S, 1932 PL) < 1% ph.mini.Archer 0.6.6 64.7 -> 98.5 cx.mini.Nimrod 0.55 99.3 -> 69.9
12.2* 7 / 976 (86.36 APS, 94.00 S, 1942 PL) < 1% synapse.rsim.GeomancyBS 0.11 40.0 -> 69.6 kc.serpent.Hydra 0.21 99.4 -> 82.6
12.3* 6 / 980 (86.60 APS, 94.10 S, 1948 PL) < 1% davidalves.Firebird 0.25 78.0 -> 97.6 sm.Devil 7.3 79.4 -> 69.0
12.4* 6 / 980 (86.68 APS, 94.10 S) < 1% rc.yoda.Yoda 1.0.6c.fix 71.0 -> 87.6 Legend.BoulderZY 1.4.9 95.0 -> 69.5
12.5** 5 / 984 (87.19 APS, 94.72 S) < 1% simonton.mini.WeeksOnEnd 1.10.4 57.8 -> 83.8 jf.Dodger 96.9 -> 70.0
12.6* 5 / 982 (87.74 APS, 94.8 S) < 1% mladjo.Grrrrr 0.9 68.5 -> 99.2 kid.Gladiator .7.2 86.9 -> 58.8

(*) Version 12.2+ scores are greatly affected by what clients run them. On some clients, a lot of skipped turns occur in the first round, typically causing the bullet shielding mode to fail. 12.3+ should be slightly better due to some CPU usage improvements, but the problem remains. Despite this, there was little effect on 12.3 - 12.6 due to who all was running clients at the time and possibly also due to the CPU usage improvements.

(**) Version 12.5 score shown of 87.19 APS was on the Darkcanuck server. However, the rank was only 86.38 APS on the LiteRumble server. This was probably almost entirely due to the skipped turns anomaly of the clients, and gives an idea of how big a difference this anomaly can make.

Version CPU Usage

All values are averages in milliseconds with the exception of those listed as Peak values, which are the maximum time in milliseconds encountered during a typical 35 round battle.

Version Notes Gun Avg/Tick Gun Peak Drive Avg/Tick Drive Peak
6.5 Single wave surfing, single guess factor gun. 1.01 13.41, 8.77, 8.41, 7.15, 6.94 0.21 7.70, 7.61, 6.93, 6.93, 6.49
9.13 Multi-wave surfing, single guess factor gun. 0.301 6.23, 6.21, 5.82, 5.13, 4.74 0.775 22.52, 20.01, 16.26, 16.23, 15.94
9.14 / 10.0 Multi-wave surfing, gun array with 3 guess factor guns, Levy's KD Tree. 0.182 6.13, 6.07, 5.24, 4.05, 3.93 0.544 15.24, 14.55, 14.13, 13.91, 13.78
11.0 Multi-wave surfing, gun array with 2 guess factor guns, Levy's KD Tree, unoptimized Precise MEA on guns 0.978 140.3, 27.06, 21.98, 20.92, 17.43 0.558 21.34, 20.03, 18.62, 17.41, 15.32
11.3 Multi-wave surfing, gun array with 2 guess factor guns, Levy's KD Tree, optimized Precise MEA on guns 0.631 12.79, 12.65, 9.98, 8.76, 8.68 0.543 19.16, 15.21, 14.57, 14.51, 14.40
11.4 Multi-wave surfing, gun array with 2 guess factor guns, Rednaxela's 3rd Gen KD Tree (w/ bucket size 64 and MaxHeap copied to List every search; might be better way to do this), optimized Precise MEA on guns 0.603 13.40, 9.15, 8.84, 8.76, 8.74 0.545 16.99, 15.04, 14.73, 14.39, 14.23
12.3 The same as 11.4, but with processing performance improvements. The biggest improvement made to the direct drive predictor. For more details, see version notes for 12.3. 0.267 5.23, 4.44, 3.77, 3.28, 2.98 0.299 7.34, 6.95, 6.81, 6.71, 6.60

Series Notes

Series 1.x

This series of robots was released while work on the Xander framework was still ongoing. Targeting and drive strategies were somewhat simple. No surfing or guess-factor targeting.

Series 2.x

This series introduced my earliest concept on guess factor targeting. Drive strategy was still simple.

Series 3.x

This series introduced wave surfing, and improvements to the guess factor gun. Version 3.0 used a modified version of the BasicGTSurfer wave surfing drive as a reference point, with all later versions in the line using a wave surfing drive of my own design. Towards the end of this line, I introduced virtual hit ratios, where all guns would provide aiming information for every shot to determine whether or not their aims would have hit the target or not.

Series 4.x

This series focused largely on drive improvements, including improvements to the wave surfing drive, dive protection, and a new Ram Escape drive. This series also improved how fire power is selected.

Series 5.x

This series focuses on using a new strategy for calculating factors in guess factor guns and wave surfing drives, surfing multiple waves simultaneously (explored by never implemented), paying more attention to robot width, improving wall avoidance, and improving segmentation selection and processing.

Series 6.x

XanderCat series 6 focuses on taking everything learned so far and evolving it into a new set of components, or at the very least, cleaning up old components or features that did not work out. Series 6 introduces the new Evolution Drive, an updated Wave Surfing drive, and new ways of handling factor arrays.

Series 7.x

XanderCat series 7 uses the first release-ready version of the Xander framework. With the knowledge gained over prior versions of XanderCat, the Xander framework has undergone a final refactoring and cleanup and is now considered ready for public use. The Xander framework can be considered as version 1.0. In addition to using the finished Xander framework, series 7 may see updates to the main drive and gun, as well as a first release into the melee competition.

Series 8.x

This series will use my own take on using a K-nearest-neighbor (KNN) approach for the main drive and gun. It may also finally introduce surfing multiple waves at once.

My KNN approach to to create a KNN Factor Array Processor that can be used in both drives and guns. I already have a FactorArrayProcessor interface built into my guess factor / wave surfing framework that it will utilize. However, instead of saving a large number of factor arrays and combining them, it will instead store a tree of data points, retrieve the closest data points to the current situation, and build a single factor array from those data points. One advantage of this approach is that is should allow for a greater number of segmenters and slices per segmenter.

Series 9.x

This series uses the updated Xander framework version 2.0. There are a variety of changes as a result. This series saw the first introduction of bullet shadows.

Series 10.x

The "Pro" series. This series switched to using a true KD Tree for drive and gun data. However, many of the versions in this series were just parameter adjustments. The only other major feature changes were to fix the buggy bullet shadows implementation introduced in series 9 and to begin (but not fully switch over to) the Xander Painting Framework.

Series 11.x

This series attempts to add some revised functionality in an attempt to break into the top 10, or at least get very close. This series will also see another round of code cleanup to reduce code size and fully utilize the Xander Painting Framework and Xander File Utility (removing any old code that the new frameworks can take over for).

Current Series Version Notes

Version 12

In series 12, I was attempting to build some new surfing components, but I generally didn't have much success doing so. Therefore, I instead decided to go back to what I am good at -- multi-mode operation -- and added some new modes that should inflict a new round of pain on my unsuspecting foes.

New Features:

Xander Framework Updates

  • Segmenter interfaces cleaned up and updated to reflect modern usage. All segmenter implementation classes updated to use the new interfaces. This change was validated in 11.10 and did not affect APS (although it did slightly reduce code size and overhead).
  • Updated resources and related classes such that separate FactorIndexers can be used for self and opponent instead of a single FactorIndexer for both.
  • Fix bug in guess factor targeter class where some aim attempts could be ignored due to the failure to normalize the aim degrees. This caused occasional delays in firing.

XanderCat Updates

  • Added new bullet shielding mode to the component chain. Feel the pain, boys! (poor Hydra)
  • Added new ramming mode to the component chain. This is only used in very limited circumstances -- when the opponent is at very low energy and has stopped firing. This adds insult to injury on opponents who are vulnerable to the new bullet shielding mode. (sorry, I can't help myself!)
  • Turned off auto-fire on disabled opponents in the configuration. XanderCat rams them now.
  • History size increased from default of 80 to 120 (the default history size was occasionally too small).
  • Fixed possible rare NPE bug in a couple of places where obtaining a robot history snapshot did not appropriately handle the rare case where a snapshot doesn't exist (one example where this can happen is a skipped turn resulting in missing a snapshot for self).
  • Updating drive data roll parameters, including the use of a new non-linear roll function to replace the previous linear function.

Version 12.0.1

  • Fixed bug in bullet shielding scenario so scenario will disengage if the opponent is not firing any bullets.

Version 12.1

In this version, the bullet shielding components have been reworked to fix a number of problems. You can tell version 12.0.x is not operating at full potential by comparing it's results to another bullet shielder like BulletCatcher. I believe the new components, while still not perfect, are much improved.

Xander Framework Updates:

  • Add new AbstractGun class that implements Gun and handles the actual firing of bullets, leaving aiming up to subclasses. Changed XanderGun to extend AbstractGun. These changes make it easier to build guns when not utilizing XanderGun.

XanderCat Updates:

  • Change parameter for BulletShieldingScenario condition 1 so that scenario will activate immediately on start of round, rather than allowing 20 or so ticks for IdealPositionDrive to improve positioning. I'm still not sure which way is better. In my initial testing, it was a wash either way. If shielding right away, you can successfully shield against more opponents, but it takes away a little score from opponents who cannot be shielded against. I need a lot more testing to refine which way is better. For now, because it will be more interesting, I'm going with immediate shielding activation.
  • Change BulletShieldingScenario condition 3 to check for ((time - lastOpponentFireTime) < 250) instead of (opponentBulletsFired > 0). This condition is for handling opponents who are not firing bullets, and the change fixes it to work at any time in the battle instead of just checking the beginning of the first round. This fixes the survival anomaly against ad.last.Bottom, and could potentially apply to other opponents under various special conditions.
  • Change BulletShieldingScenario condition 7 to use opponent bullet power cutoff of 0.2 instead of 0.3.
  • Change BulletShieldingScenario condition 8 to use shielding shot cutoff of 20 shots instead of 10.
  • Change bullet shielding drive strategy to standing still when opponent is moving at the time they fire (as in previous version), but shifting position when opponent is standing still at the time they fire. (Why???? Why does it work this way???? Whatever.)
  • Fixed a couple of bugs related to using getDistanceRemaining() with bullet shielding control sequence. The only real impact with my current usage is that it prevents the possibility of a brief "runaway robot" when switching from some other scenario to the bullet shielding scenario.
  • BulletShieldingScenario now ensures that bullet shielding components are properly reset to initial condition when scenario is deactivated and then reactivated later.
  • Created new BulletShieldingGun (that extends the new AbstractGun). It replaces the BulletShieldingTargeter and BulletShieldingPowerSelector used previously. For bullet shielding, the aiming and power selection are too closely intertwined to continue using a separate targeter and power selector approach like I use for other guns.

Some interesting shielding notes:

  • My shielding doesn't work against a few opponents, like Phoenix, but those same opponents can be shielded by other bullet shielders. Why? More research needed.
  • For a few opponents, shielding only works if the shielder stands still from the very beginning (note my change to shielding condition 1). Some examples of this include Engineer (definitely) and SniperFrog (I think). XanderCat 12.0.x will move to improve it's position in the first 20 ticks or so before stopping to try to shield. This apparently pollutes the data Engineer is collecting rendering shielding ineffective. More testing is needed to determine if it is better over the entire rumble to improve positioning as in XanderCat 12.0.x or to hold still, risking worse positioning against the greater field for the benefit of a few shielding vulnerable opponents like Engineer.
  • The new BulletShieldingGun (that extends AbstractGun) that I created can adjust fire power to try to hit opponent bullets at a time midpoint. However, if the required power adjustment exceeds a set threshold (currently 0.2), it just falls back to using power 0.1. In some initial testing, the power adjustment was only occurring on about 7% of shots. I don't expect this feature to provide a noticeable benefit, so I've opted to leave this function off for XanderCat version 12.1. I may throughly test it out for potential use in a later version however.

Version 12.2

  • Fixed bug where opponent wave too close test in the bullet shielding controller was failing to correctly report when opponent was too close. This bug is the main reason the previous version was losing to GeomancyBS, and was also hurting scores against other close fighting opponents.
  • Opponent too close test in the bullet shielding controller now factors in time remaining until gun cool when deciding if an opponent wave is too close to shield against. This allows us to get out of the way sooner of any shot that cannot be shielded against due to waiting on the gun to cool.
  • Increased required lead time for an opponent wave from 6 to 7 ticks.
  • Add condition to stop trying to bullet shield for the rest of the battle if the opponent is repeatedly not firing first (more than 3 consecutive times in the same round)
  • When opponent is under 8 energy remaining, required distance from opponent is increased by a set amount. This is intended to prevent being hit by low power shots that cannot be shielded against and that other scenarios will not have enough time to dodge.

Version 12.3

This version focuses on enhancing/reducing CPU usage in hopes this will fix skipped turn issues and bullet shielding failures on some clients.

  • Moved some direct drive predictor function calls inline rather than calling methods on utility classes; this reduced function calls and reduced the number of objects created on some methods.
  • Updated direct drive predictor to perform fewer drive bounds .contains checks.
  • Updated direct drive predictor to cache trig values for last heading rather than recalculate every time a drive state is advanced.
  • Removed a few log statements that get ignored anyway. This removes a few unnecessary String creations.

Version 12.4

  • Fix bug where missed shielding shot can go unnoticed. This could potentially happen repeatedly causing loss of round.
  • Improve how lead time required for successful shielding is calculated. This improves shielding against close fighting opponents.
  • Assume firepower of 0.1 for opponent shots fired when their energy is less than 0.1. This seems to be how Robocode 1.7.3.x works.
  • Fix bug in linear intercept calculation where computed double value (one value minus another) is compared to zero. Due to imprecise doubles, the correct behavior it to compare to almost zero. This bug could result in the occasional firing of a bullet in a bizarre direction.
  • Fix bug where bullet shielding gun can get stuck (disabled) on a really low power bullet due to not being able to compute a linear intercept.

Version 12.5

Framework Updates

  • Add new checks of velocity and gun cool time to try to avoid registering an opponent wall hit as firing a bullet.
  • Bullet Shielding Gun updated to allow for multiple opponent targeting types.
  • Bullet Shielding Drive now moves only a tiny amount when moving to shield against a stationary opponent.

XanderCat Updates

  • Add secondary targeting type to the Bullet Shielding Gun. (same as is used in Spitfire)
  • Ideal Position Drive will now hold position instead of driving to center of battlefield when no opponents remain.
  • No longer ram disabled opponents when shielding.

Version 12.6

Rednaxela's KD Tree Update:

  • Updated Rednaxela's 3rd gen KD Tree so that the heaps returned from a search have methods to directly access the data and keys by index. This was done to support multiple iterations through the same data of a KD Tree search. Data accessed in this manner is not returned in order (I don't need it to be; I just need to be able to iterate through the data multiple times without having to re-execute the same search; this is handled by my CachingLogReader and is utilized when there are multiple guns or drives using the same KNN parameters).

Framework Updates:

  • Expanded auto fire on disabled opponents functionality such that conditions can be specified for when auto fire is allowed.
  • Reworked how opponent gun fire detection works when opponent has collision with wall. If opponent is assumed to have gun heat remaining, assume no bullet was fired unless the previous shot happened on a known collision. A known collision is any time a velocity change exceeds the maximum deceleration rate. If no heat remaining on a known collision, assume a bullet was fired, but skip the gun heat check the next time an energy drop is detected. There is no way to know for sure what the bullet power is, so assume the bullet power is the same as the previous shot. The following possible errors remain from this approach:
    • A slow collision when gun heat is 0 will not be detected as a collision. This will result in a false wave. Furthermore, the next real wave will likely be missed as the system will assume a shot could not have been fired due to assumed gun heat remaining after the previous wave.
    • A correctly detected collision when gun heat is 0 will assume a bullet of the previous fire power has been fired. It may be that no bullet was fired, or possibly a bullet with a different firepower. I don't see any way to resolve this. However, the next wave should not get missed if no bullet or a lower power bullet was fired because the system skips the gun heat check for the next wave after a collision.
  • Saving the number of battles for each individual opponent and the total battles for all opponents to the battle statistics file is now a function of the framework. This data is only saved if the robot is saving other information to the battle statistics as well.
  • Robots can now have the framework save gun, drive, and radar run times to the battle statistics file using settings in the Configuration.
  • Added utility method to the BattleStats class to simplify saving averages to the battle statistics file.
  • Updated getActiveGunName() in AbstractXanderRobot to return the disabled robot gun name when the disabled robot gun is in use.
  • Updated Graph Data and CPU Utilization painting to allow graph to be resized, fix a bug in the data end points, and allow CPU constant to be graphed.

XanderCat Updates:

  • Revise generic KNN log reader to return a data iterator instead of a data point list. This should mostly eliminate the massive overhead of creating a List for each read when using Rednaxela's KD Tree in order to match the interface. This will also make data point KD Tree distance available on each point, something previously unavailable that could improve performance if used when filling the factor arrays.
  • Use KD Tree distance for each point to adjust the weight of data points in the constructed factor arrays. This is done for the drive only (affect had no statistical significance when tested on the guns).
  • Adjust KNN selection parameters on the drive from (1, 30, 0.3) to (10, 40, 0.4) where values are (minK, maxK, K growth rate)
  • Start recording drive and gun run time stats in the saved battle statistics file.
  • Auto-fire on disabled opponents turned back on, with condition that if the bullet shielding gun is active, there must be no active opponent waves. Ramming will now only be used on low energy opponents who have stopped firing but are not disabled.
  • Fix issue where shielding vulnerable opponents repeatedly get too close to shield against. This was fixed by switching to using a disengage distance and a re-engage distance, rather than a single required distance check. This keeps the bullet shielding scenario from bouncing on and off against opponents who keep nudging closer.
  • Add workaround for rare bug where bullet shielding system gets stuck with the drive in the Firing state but the gun requesting a wave to shield against. Previously the controller would just return null when a wave was requested if the drive wasn't in Standing state. This is now updated so that if a wave is requested when the drive is in Firing state, the controller requests the drive return to Standing state (normally this happens when the gun fires, but somehow this fails on rare occasions).
  • Update move to standing steps in the drive to immediately switch to Standing state if the drive shift was 0. This saves an extra tick on most shielding shots. This was previously done for the move to firing step, but was previously overlooked for the move back to standing.

Version 12.7

Work on this version was stalled for months but is underway again as of mid November, 2013. Probable release in late November.

This version focuses on managing garbage collection. The amount of garbage collection going on is causing lots of skipped turns on some clients in the first round, which is seriously compromising the effectiveness of my shielding components.

  • Create and utilize new mechanism for managing garbage (particularly in the first round). Current strategy is to use a new "waste basket" to hold onto old objects and delay garbage collection until non-critical times (object pooling was another strategy considered but is not favored at this time). This occurs until round 3.
  • Initial objects selected for management include Snapshots and Waves. This was calculated out to be about 2000 objects per round that are thrown away and garbage collected.
  • Add new condition for bullet shielding scenario to handle situations where shielding is not sufficiently effective on a round (shielding will shut off for current round only under this condition). This should fix a shielding vulnerability that was occurring against certain mirror bots from suh (the problem turned out not to be with the anti-mirror components, but rather with the bullet shielding components).

Version 12.8

The attempt to fix the garbage collection problem using the "waste basket" approach in version 12.7 was a failure. I can tell this pretty easily by comparing XanderCat against Spitfire. Therefore, version 12.8 will take a new approach to fixing the problem.

After more research, it appears as though the problem caused by the skipped turns is not so much with timing (or insufficient time) causing shielding misses, but rather a problem with how opponent wave objects are created when the opponents bullet was fired on a skipped turn! Fixing this may be enough to make the shielding work even with the missed turns, plus there may be a latent benefit of eliminating/reducing tracking errors in general. Therefore...

Changes in this version include: Framework Changes

  • Removed the "waste basket" utility.
  • Added a skipped turn simulator that can be used during testing.

XanderCat Changes

  • Updated created wave objects from opponent bullets fired when scans are missed (for example, if there are skipped turns) to flag them as estimated (the system doesn't know exactly on what scan the bullet was fired because we don't have back to back scans).
  • Bullet shielding controller no longer accepts estimated opponent waves as valid waves to shield against. This won't prevent hits on us but will prevent a hit from an estimated wave from being seen as a shielding failure (as it's really a scan failure).
  • Adjusted shielding energy level condition for shielding scenario to accept reduced effectiveness on first couple of rounds to account for skipped turns early in the game (I didn't fix the skipped turns problem, I just worked around it).

Version 12.9

Kind of wrecklessly throwing this version out there without solid vetting. :-P

  • Fix some bullet shielding failures.
  • Remove ram scenario. XanderCat will no longer try to ram low energy opponents who are not firing. The movement was degrading bullet shielding effectiveness due to opponent data pollution.

These are battles that XanderCat should be able to successfully bullet shield against (screenshot from RoboJogger) Skotty-xandercat-bs-failures.png

Note: Nothing I can do about Seraphim. After some analysis, I discovered that XanderCat's bullet shielding strategy is not flawed on Seraphim; rather, Seraphim is actively countering it against XanderCat specifically. I'll exclude him from further analysis.

UH OH! At least one bot I broke XanderCat against. 12.2 APS on one battle against simonton.mini.WeeksOnEnd 1.10.4. Well, that's what happens when you have a multi-mode bot you don't test well enough before releasing to the rumble. Doh! Hopefully the improvements against other bots make up for it.

Version 13.0 (planned)

  • Switch to updated Xander Framework v3.
  • Fix an exploitable vulnerability in the tracking systems.
  • New statistics-based distancing technique for surf drives. This is actually somewhat revolutionary for XanderCat -- not just a tweak -- and it will give the drive far more authority to adjust distance than it has ever had before, from maintaining max distance possible all the way up to essentially ramming (a point of interest that I just removed the Ram drive components in the prior version, but this change would bring similar behavior back as a possibility). Will require some thorough testing prior to release due to the significance of the change.
  • Fix bug in wave surfing framework that could result in NullPointerException.
  • Tweaks to fix whatever corner cases I might have broke in 12.9.
  • TBD

Future Version Possibilities

Possible Features

  • Update gun data roll procedure.
  • New drive system for wave surfing? This was tested and so far has not proved advantageous, so the likelyhood of it making it into the final version is dropping.
  • Add 2 new segmenters to the guns.
  • Possibly update how danger is modified based on distance.
  • Figure out how to pummel PrairieWolf.
  • Add tracking of certain types of "errors" to help with improvements (for example, keep and report on a count of how often the robot runs into walls, or fails to reach it's intended location)
  • Modify segmenters?
  • For logged battle stats against each opponent, instead of keeping a single average for stat values, keep two sets of stat values: one for the best battle against them, one for the worst battle against them.
  • Segmenter changes? (possibly a new type of segmenter)
  • Try out a "performance-based distancing equation"?
  • Implement several speed improvements?
  • Maybe tweak some other parameters?
  • Improve bullet shielding protection?
Retrieved from "http://robowiki.net/w/index.php?title=XanderCat&oldid=36373"