XanderCat

XanderCat
Author(s)	Skotty
Extends	AdvancedRobot
Targeting	GF / Linear / Circular / Anti-Mirror
Movement	WS(GoTo) / Anti-Mirror / RamEscape / IdealPosition
Released	2011-5-20 (v 1.0)
Best Rating	#8 (v 11.6)
Current Version	11.16
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.

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 I can beat it quite badly due to 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 suring 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.

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
RamScenario --> Ram Escape Drive, Linear Gun
  |
  v
MirrorScenario --> 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         The Anti-Scarlet Gun

Ram 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 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 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. 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).

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 alot with a rammer, but the ram scenario happens earier in the component chain and thus superscedes 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 embued 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-Scarlet 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, thus the name.

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 essense 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 upperhand 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, 1890 PL)	1.1%	Not Enough Data		Not Enough Data
11.6	8 / 953 (85.14 APS, 1890 PL)	< 1%	Not Enough Data		Not Enough Data

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

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 earlist 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 11.0

This version includes a modification to the Xander framework to make it easier to use precise MEA. MEA for each wave is now stored with the wave itself. And per a setting in the Configuration, you can now set usePreciseMEAForMyWaves and usePreciseMEAForOpponentWaves. When false, the common approximation by bullet velocity calculation is used; when true, a predictor is used to determine the maximums.

In addition, a new resource has been introduced -- the FactorIndexer -- which handles converting between factor angles and indexes. Like all resources, it is available through the Resources class. Unlike other resources, it is defined by an interface, and you can change the implementation through the Configuration. The default implementation is known as the BalancedFactorIndexer, which evenly splits all bins between the counter-clockwise and clockwise maximum escape angles.

The framework was also changed to make guns more efficient. Previously, the gun-related code was sloppy about creating multiple wave objects for aiming. Now that creating a wave is quite a bit more expensive when Precise MEA is enabled, this needed to be improved. For now, the solution was to creating a temporary wave cache in the WaveHistory, such that repeated requests to get a wave for the same snapshots and fire power pull from the cache. This cache is cleared out at the beginning of each turn. In addition, targeters are now passed a wave instead of just a bullet velocity when aiming. Despite these changes, the gun code is still not as efficient as it should be, and will likely see additional changes in later versions.

• Use honest precise MEA for the guess factor guns. Previously, I was just capping the ranges.

Version 11.1

This version is a general maintenance release focusing on optimization, cleanup, code size reduction. May also include minor gun and/or drive tweaks.

• Fix CPU performance issues in the gun system, and minor optimization across the board.
• Remove old paint code that the Xander Painting Framework can take over for.
• Remove some old experimental functionality that was not in use and had no useful impact when it was tested.
• Turn off "distancing dropoff" effect against difficult opponents.

Version 11.2

Sanity check release. Version 11.1 had a performance drop without any intended change in functionality. This version was released to verify original score and ensure proper source roll back. Intended v11.1 changes will be reapplied in a later version.

• Revert to source code used in 11.0.

Version 11.3

This version reapplies version 11.1 changes with the version 11.1 bug fixed. The problem was in the cache used in the WaveHistory for improving the efficiency of the gun system. The cache was caching waves, and it did not work correctly with virtual waves. I have modified the system to only cache the calculated MEAs, which was all I really needed the cache for in the first place.

• Fix CPU performance issues in the gun system, and minor optimization across the board.
• Remove old paint code that the Xander Painting Framework can take over for.
• Remove some old experimental functionality that was not in use and had no useful impact when it was tested.
• Turn off "distancing dropoff" effect against difficult opponents.

Version 11.4

• Update KD Tree related components in the xander.gfws package to allow for multiple KD Tree implementations.
• Switch from Levy's KD Tree to Rednaxela's 3rd Gen KD Tree.

Version 11.5

This version consists of minor tweaks to hopefully slightly improve overall score and performance against some of the top robots. More than that, this version will serve as a measure of my latest sample set I test with to see how closely score changes in my sample set match up to score changes in the Rumble. (Note: I now run a minimum of 20 to 30 seasons with my sample set -- quite a few more seasons than I used to use -- in order to get a more stable and accurate reading on how various changes affect the robot against competitors.)

My sample set indicates a 0.30 score increase. My sample set excludes certain types of robots, so overall I would expect -- if it's a good sample set -- the Rumble score change to be less than what I get with the sample set. I'll guess maybe half as significant. So what I will be hoping for here is a 0.15 APS score increase. However, I have no expectations, and would not be overly shocked if I see a result quite different from that, possibly even a score drop. Once this version has enough battles run for a stable score, I will then refine my sample set until I find a set that as closely as possible reflects what happened in the Rumble.

Changes in this version include:

• Increase Anti-Scarlet gun data roll from 0.005 to 0.015.
• Decrease flattener visit weight percentage from 33% to 15%.
• Switch out DefenderSpeedSegmenter for the LateralVelocitySegmenter in the guns.
• Improved how battle stats are averaged from battle to battle against the same opponents -- all battles are now weighted equally (note: the saved battle stats are only used for diagnostics; this will have no effect on performance).
• Fix naming mistake for configuration MEA settings (has no effect on performance).

Version 11.6

If the results for 11.5 in the Rumble so far hold, the changes from the previous version 11.4 resulted in a scratch. Some ups and downs, but no overall score change. This is not entirely consistent with my test set of robots, so I will be looking at some significant changes to my test set.

For this next version, I will be comparing versions 11.5 and 11.4, and taking a close look at the opponents where I had the greatest score difference between the two versions, both in the positive and negative direction, and put a bunch of those into my test group. I will then focus on adjusting XanderCat for the updated test set such that there are positive score changes without any significant negative score changes over 20+ seasons. Once that is achieved, XanderCat 11.6 will be released into the Rumble.

While a lot of my usual ideas haven't yielding any notable improvements, I had an idea cross my mind that I wanted to try out. It showed improvement on my revised test set (+0.30 in 20 seasons) and now it's time to see what effect it has in the Rumble (if any).

Changes from previous version:

• Revise drive bounds for self.

Rumble Results

I was hoping this version would solidify my place ahead of mue.Ascendant 1.2.27, who XanderCat had been trading places with in ranks due to nearly identical scores (flip-flopping between 9th and 10th). Happily, this version did that and then some, placing XanderCat slightly ahead of kc.serpent.Hydra 0.21 and barely squeaking into 8th place. (will I be trading ranks with Hydra now?) This version in particular marks a milestone as it is the first time I have reached 85 APS. Ironically, after trying many complex changes, it was a simple change in this version that got me there.

Version 11.7

Version 11.6 showed about a +0.20 improvement in the Rumble. This is a good correlation with my last test set, so I will keep my last test set mostly as is for version 11.7 development.

Changes in this version:

Xander Framework Updates:

• In AbstractXanderRobot, initialize the RobotProxy object earlier such that it can be used in the configure() method implemented by any subclasses.
• In the ComponentScenario class, allow the same component to serve multiple functions. This allows, for example, a modified RaikoGun to serve as both a Radar and Gun in the MC2K7 challenge.
• Add methods isAdjustXxxForYyy() to the RobotProxy class.
• In the GunController class, do not issue a GunFiredEvent when the setFireBullet method is called unless gun heat <= 0. This prevents erroneous GunFiredEvents if a gun attempts to fire bullets when they are not actually able to.
• In the LinearEquation class, fix a couple of corner case bugs for lines of the form x = b and y = b. Also, when computing a line intersection between two parallel lines that do not intersect, return null instead of a double[] filled with Double.NaN values.

XanderCat Updates:

• Improved the capabilities of my anti-mirror components (at the expense of more memory used and a little more processing). Yeah, it didn't need it, but it's my only claim to fame. :-) The new components should be able to accurately detect mirroring bots that use a time delay in the mirroring; I know there is at least 1 bot in the rumble that does this, though I can't remember which it is.
• When sending out next wave to hit event to OpponentWaveListener classes, determine the next wave to hit by time to hit rather than by distance.
• Bump the gun selector rolling hit ratio significance up from 25% to 35%. (to be further tweaked at a later date, as I haven't fleshed this parameter out fully yet)
• Track wall hits and robot hits. I may be occasionally hitting the wall, so there is a chance for improvement there. I'll be able to tell that for sure after a good number of battles I can look back on.

Version 11.7.1

• Revert gun selector rolling hit ratio significance back to 25% to verify whether or not this was the sole contributing factor to the score change from previous version (I expect this to be the case). (Note: I have plans for making this parameter dynamic in the next version)
• Fix the tracking of wall hits and robot hits (forgot to add the listener).
• Add tracking for drive usage percent. In particular, I'm looking for which opponents the mirror drive engages for, though it's of interest for all drives.
• Update framework so that the DriveStats class can provide a list of all possible drives, and not just the ones that get used in the battle.

Note: Early indications from a couple of quick test runs suggests that XanderCat is hitting the wall quite a bit (average of 48 hits per battle!) If this holds true for a larger number of battles and I verify I didn't make any mistake in the calculation, then there may be a significant bump to be had from fixing this.

Version 11.7.2

Okay, it wasn't the gun selector rolling hit ratio that dropped my score in 11.7. Now I'm thinking I'm getting more false positives with my expanded anti-mirroring components. This version will scale that back.

• Change anti-mirror components to only track back about 3 ticks instead of 50. This should make it roughly equivalent to what existed in 11.7. I thought there was at least 1 opponent that used a mirroring delay, but I'm not seeing it now, so scaling it back can only help. Maybe I'll work on trying to eliminate false positives in the detector some other time.
• Update wall hit tracking to track damage taken, not just a count of wall hits. (after checking the docs, it appears the only downside to hitting a wall is taking damage, and damage taken depends on speed when the wall is hit; if I only ever hit the wall at a speed of 2 or less, then the wall hits won't matter; for the sake of an easy upgrade, I kind of hope I'm running into the walls at high speed.)

Version 11.8

Changes from previous version:

• Tweaked drive parameters to eliminate most instances of XanderCat running into walls (not perfected -- reduced to maybe a 1/4 to 1/3 of what they were -- took a sledge hammer to the problem to see if it makes a difference first, before fine tuning on it)

Version 11.8.1

• Adjusted virtual hit ratio significance again. A minor tweak partly done just to verify how closely my new test bed is to the entire rumble (latest test bed is 58 robots that I typically run 10 seasons on).

Version 11.9

• Change how movement is predicted into the future for the purposes of gun aim. I currently predict 1 tick into the future when aiming my guns. Previously I had a crude prediction that just continued the robot's current velocity and heading. In this version, the prediction also takes acceleration/deceleration and turn from the previous tick into account.

Version 11.10

This version and every remaining version in the 11.x line are pre-releases of the upcoming version 12.0 to validate various changes before there is an official version 12.0.

This version validates changes to the framework segmenter interfaces and the corresponding segmenters that use those interfaces that will be used from here forward. My only expectation for this version is that APS does not decrease from the previous version.

Version 11.11

Removed some diagnostic code from previous version. Updated functionality of acceleration segmenter used in guns. Framework updated to support separate FactorIndexers for self and opponent -- what XanderCat uses wasn't changed, but it's possible bugs could have been fixed or introduced from the change. Seeing some unexpected results in my small scale local testing. Releasing to the rumble to see what happens there...

Version 11.12

Updated framework to allow for custom functions for how to roll data in guess factor guns and wave surfing drives that use factor arrays. The old way used a simple hard coded linear function, while the new way allows a function defined by an interface. For this pre-12 version, I replaced the old linear means for rolling my drive data by a new function (guns unchanged for this version).

Version 11.12.1

Tweak of one of the data roll parameters.

Version 11.13

Diagnostics release where drive data roll was completely turned off.

Version 11.14

Drive data roll turned back on with new parameters.

Version 11.15

Reverted to old data roll parameters. Still about 0.3 APS below where it was in version 11.11, an issue I am looking at more closely now but don't have an explanation for. This seems to have happened when I switched from a dumb simple drive data roll implementation to one driven by an interface allowing the function to be swapped out with ease. It will take some deep digging to analyze why this had any APS impact, as the function class I used should have been identical to the old method. Despite the APS drop, performance against Diamond and DrussGT in particular is quite good. At this point, I don't anticipate any more releases until I do something significant and release version 12.

Version 11.16

Added workaround for minor bug that was resulting in an occasionally Exception in all versions since v 11.11. Also added some minor diagnostic output to trace the original glitch (which still exists, it just doesn't result in an exception anymore; with the added diagnostics, I might be able to fix the source of the glitch in a later version)

Version 12

Anything new in 11.10 and later is also considered new in version 12.0, as version 11.10 and later 11.x versions were just early validations of certain v12 concepts.

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

• 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).

Probable New Features:

• New drive system for wave surfing.
• Updating drive data roll parameters, including the use of a new non-linear roll function to replace the previous linear function.
• Update gun data roll procedure.

Possible Features

• 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?