|
One of the problems with StatisticalTargeting is dealing with multi-mode bots like PrairieWolf and Ares. Once you have gotten some data in your stat buffers on these bots they tend to switch mode and your data is useless. After a while you have some average data that probably isn't very effective against any of the modes of the enemy. |
|
Visit count stats is simple and powerful. But if you save stats between battles you might find that the files tend to grow quite large as you fight more battles aginst an enemy. Here's a way to limit the size of your saved data files. |
|
One way of dealing with this problem is by adding some decay to your stats so that you "forget" older data. The most well known approach to this is RollingAverages introduced by Paul Evans with his SandboxLump eons ago in Robocode time. Rolling averages is very effective though not always applicable to your particular stat gun design. If you have a gun designed along the lines of the FloodMini gun you are using visit counts which doesn't lend themselves to rolling average calculations. For these guns I (PEZ) have designed the following approach for stat decay instead. Let's say you are using a guess factor gun much like the one of VertiLeach/Code. It's derived from the gun of Tityus which in turn was designed after I had looked at the FloodMini guess factor gun. It's the use of int arrays with visit counters that I found simple, elegant and useful. To add decay to this gun look at the visit incrementor inside the Wave class of VertiLeach:<pre>wAimFactors?[(int)Math.round(Math.max(0D, Math.min(AIM_FACTORS - 1D, |
|
Let's say you are using a guess factor gun much like the one of VertiLeach/Code. To add decay to this gun look at the visit incrementor inside the Wave class of VertiLeach:<pre>wAimFactors?[(int)Math.round(Math.max(0D, Math.min(AIM_FACTORS - 1D, |
|
The trick is of course to set the max value correctly since it's not as easily figured as with rolling averages. You'll have to experiment some to get it right I guess. And what's right against one enemy might be wrong against some others. I guess that if you add VirtualGuns to this you can use some different maximums and let the VG array figure out what works or not against a given enemy. |
|
If you set MAX_FACTOR_VISITS to 255 the visit count buckets will never grow above byte size and this sets a much lower limit on how big the files get. |
|
An added benefit with this approach is that it offers a way to limit the size of your saved data files if you are saving the stats to disk. In the above code I am using integer arrays and they tend to grow and grow in size as I am fighting more rounds against an enemy. But if I set MAX_FACTOR_VISITS to 255 the visit count buckets will never grow above byte size and this sets a much lower limit on how big the files get. This was in fact why I came up with this scheme to begin with and I only a few seconds later realized it offered stat decay functionality as well. |
|
An added benefit with this approach is that it offers some StatsDecay. Rolling averages is very effective for this though not alwats applicable VisitCountStats designs. The trick is of course to set the max value correctly since it's not as easily figured as with rolling averages. You'll have to experiment some to get it right I guess. And what's right against one enemy might be wrong against some others. I guess that if you add VirtualGuns to this you can use some different maximums and let the VG array figure out what works or not against a given enemy. |
|
I think i've missed something... but: If you are just decrementing all the others, rather than incrementing the one you want, the actual results will be the same, you aren't decaying anything. The only difference is it is like using a compressed axis on a graph, the proportions are wrong, but the most visited count will still be the same. -- Tango Of course it's decaying. Think of what's happening if you set the max visits constant to 10. It means you have a shallower memory which is only capable of remembering the most recent visits. -- PEZ Where does time come into it? I don't see where there is any distiction between old data and new data. -- Tango Good question. I don't know the answer. The idea is to keep a shallow memory. Peaks never are allowed to grow too much higher than its neighbours. And this should make it quicker to correct when (if) enemy behaviour changes. -- PEZ The only thing i can see is that data is lost once it is decremented past zero. Prehaps that is key to how it works. -- Tango PEZ, I think Tango's question above would be more properly worded as this: without a floor on your stats what has changed? Isn't decrementing every factor but the one the bullet hit in the same as simply incrementing the proper factor, especially if you allow negative nubers in your array? I suppose if you had a floor value in your array that this would make more sense (say nothing below zero). I would imagine then that you would not want your MAX_VALUE bigger than 10 - 20. That way if a bot switched movement modes on you, you could pick up the new movement in 20 waves or less. With no floor value, you could potentially spend hundreds of Waves bringing the proper value up from negative numbers. -- jim There is a floor. -ve values are not allowed. I think when that is taken into account there is some decay, although i haven't worked it out properly to see how well it works. Decay is much slower on curveflattening bots, though, because the MAX_VALUE is for each factor, so if they are shared evenly it takes longer to reach it. -- Tango Exactly. There is already a floor. Otherwise this technique wouldn't achieve any decay at all and no file shrinkage either. Whatever decay there is will be much slower against good flatteners, but these tend to stick to the flattening mode, and if they don't then we have a not-so-good flattener to fight and quicker decay again. The real challenge might be PoisonMovement?, but we don't have many (or any) such opponents yet. -- PEZ |
Let's say you are using a guess factor gun much like the one of VertiLeach/Code. To add decay to this gun look at the visit incrementor inside the Wave class of VertiLeach:
![[Home]](/images/RoboWiki.png)
wAimFactors[(int)Math.round(Math.max(0D, Math.min(AIM_FACTORS - 1D,
((sign(bearingDelta) * bearingDiff) / maxBearing) *
(AIM_FACTORS - 1D) / 2D + (AIM_FACTORS - 1D) / 2D)))]++;
(It boils down to wAimFactors[visitIndex]++). To add decay to this we instead do:
registerFactorVisits(wAimFactors, visitIndex)And implement that function like so:
public void registerFactorVisit(int[] factors, int index) {
if (factors[index] < MAX_FACTOR_VISITS) {
factors[index]++;
}
else {
decrementTheOtherFactors(factors, index);
}
}
void decrementTheOtherFactors(int[] factors, int index) {
for (int i = 0, numFactors = factors.length; i < numFactors; i++) {
if (i != index && factors[i] > 0) {
factors[i]--;
}
}
}
What happens here is that visit counts never will exeed MAX_FACTOR_VISITS. When we are about to increment a visit count that has reached this maximum we instead decrement the surrounding visit counts.
If you set MAX_FACTOR_VISITS to 255 the visit count buckets will never grow above byte size and this sets a much lower limit on how big the files get.
An added benefit with this approach is that it offers some StatsDecay. Rolling averages is very effective for this though not alwats applicable VisitCountStats designs.
The trick is of course to set the max value correctly since it's not as easily figured as with rolling averages. You'll have to experiment some to get it right I guess. And what's right against one enemy might be wrong against some others. I guess that if you add VirtualGuns to this you can use some different maximums and let the VG array figure out what works or not against a given enemy.
-- PEZ