Performance Enhancing Bug

I started working on a mini-sized GF gun which I plan to have both an anti-RM and anti-WS component. First, I used Raiko's gun as a base, and then I added Bin Smoothing from Vyper. The problem was, I forgot to change the array type from int to double, so the bins couldn't hold decimal values and got rounded down. One would think that this would have a harmful effect, but it actually had a significantly positive effect on my robot's score against surfers. I thought that maybe the smoothing was too heavy, so I tried lower smooth factors, and I even tried getting rid of the smoothing altogether, but I still couldn't replicate the score increase.

Any ideas why this happened? Could it be something about the decay rate instead of the smoothing? Has anyone else ever noticed this?

That's very interesting. Since lower smoothing factors didn't replicate the score increase, I believe key difference is most likely the shape of the smoothing rather than the extent of the smoothing. I can think of two changes in the shape of the smoothing that may be caused by integer rounding and may be significant:

1. Depending on what kind of smoothing you used, the integer rounding may have caused several bins at the center of the hit to be incremented by the same value. It's possible eliminating the bias towards the center of the 'hit' may be of benefit in targeting surfers perhaps. To confirm/refute this hypothesis, you can keep 'double' but modify your smoothing code to keep a 'flat' region around the center of the smoothing.
2. The integer rounding would reduce the influence far from the 'hit' to zero. It is possible that small influences from excessively distant 'hits' may have a detremental effect, possibly making your targeting more predictable. To confirm/refute this hypothesis, you can keep 'double' but modify your smoothing code have a sharp cutoff for the maximum distance from the 'hit' that it gets smoothed into.

For the sake of easy reference, below is all immediately relevant code. The weight is 4 if this is a wave fired the same tick that an actual bullet was fired, and 1 otherwise. Notice that the actual smoothing is done by raising the difference between the current GF and the visited GF to the power of 0.3. I tried factors of 0.1 and just 0 (effectively the same as not smoothing at all), with little success.

int gf = GF_ONE;
try
{
	do
	{
		waveGuessFactors[gf] *= 0.995;
		waveGuessFactors[gf] += (weight * Math.pow(0.3, Math.abs(gf - (int)(GF_ZERO + Math.round(Utils.normalRelativeAngle(Math.atan2(enemyLocation.x - firePosition.x, enemyLocation.y - firePosition.y) - absoluteBearing) / bearingDirection)))));
		gf--;
	}
	while (true);
}
catch (Exception ex)
{
}

I highly doubt your first hypothesis, because every other GF than the one that was actually visited would be increased by 0. Unless of course, the wave has a weighting of 4, but even before I added weighting, the int arrays performed better.

Your second hypothesis has the same problem. Any GF other than the visited GF would get rounded down to 0, under normal circumstances.

Yeah, the first hypothesis was only applicable to greater-than-1 weight for most kinds of smoothing, which I had thought to be likely.

The second hypothesis still isn't ruled out by that however. "Any GF other than the visited GF would get rounded down to 0" is in fact the most extreme version of what I describe in the second hypothesis.

Now that I know you are using a weight of 1 however... and thinkning about your decay... I'm now quite certain that the real cause is not anything about the smoothing, but the decay. Specifically, applying the operation "foo *= 0.995" where "foo" is an integer in the range 1 to 199, is equilivant to a decrement-by-one operation. When your weight is 1 and your array is an integer one... this means that your decay might as well be "foo *= 0.0" because you're immediately completely erasing the last data point when the next arrives.

That makes a lot of sense. Thank you for your help. I guess I'll have to try out decay rates until I find one that matches the performance of the bug.

Has anyone ever made an AS gun that only took one wave into account at any given time?

It looks to me like you have basically made your gun only keep the latest hit index at each segment, so basically a segmented version of MirrorMicro's gun. A rolling depth of 0 makes sense as to why it would be good against surfers - it is basically how a standard VCS anti-surfer gun is made. Fairly coarse segmentation, and low rolling averages.

If you want to keep that performance, but with lower codesize, you could probably get rid of the bins at each segment and instead just store a single value which would represent the last GF you saw. This is basically what I do in DrussGT for the movement, except I keep the last few GFs as well as a little info like the rolling depth and the segment weighting.

Also, weighting real-bullet waves higher than tick waves helps too, right?

Do you think I would be able to fit a Virtual Guns system in 100-200 bytes? Or will I just have to sum the different buffers like Vyper?

Against surfers, yes. Real waves are more meaningful since surfers react to waves.

Against flatteners, no. The more data you use, the harder it is to flatten all statistics.

I'm not sure I agree it won't help against flatteners. I think you're saying that because flatteners are specifically surfing your firing waves, it might help to use virtual waves so they can't surf as well. But it's kind of an arms race where the gun always has the advantage, so using firing waves may still help your gun more than it makes your gun more surfable.

Along the same lines, Random Targeting is the most "unsurfable" targeting strategy, but my Anti-Surfer gun still outperforms that vs everyone.

I've wondered about a random targeting scheme that only shoots within precise MEA. Have you tested that vs. your anti-surfer?

No, but I've been curious about that too, only for one bot in particular... ;)

I've found myself wondering about the reverse recently... if a sufficiently advanced (I have some tricks in mind...) random-movement surfer (note, not active flattener) could outperform usual methods against some of the strongest anti-surfer targeting that a few bots have...

This I actually have spent a substantial amount of time working on. All sorts of extra randomization of surfing stats, fully random surf stats that get completely regenerated each time you get hit, or every so often, mixes of random and normal surf stats and flatteners, and so on. I thought a totally new movement profile every time you get hit would have a lot of potential, but I just didn't get it close to outperforming my existing stuff.

Pure random targeting is sound according to game theory, assuming there is only 1 wave flying at a given time.

With 2 or more waves, shooting at all GFs with the same probability may not be the optimal strategy. A weighted random targeting might be stronger.

True, although I'd hate to have to evaluate that function. It could probably be done with Monte-Carlo though, although it would be VERY VERY slow due to the precise predictions that would have to take place. Maybe some sort of high-speed precise prediction lookup table could work here.

If you already have the waves running a VG shouldn't be that much more codesize, just another thing to check when the wave breaks. Of course, it is important to have your VG only work on real waves otherwise it is pretty useless against surfers and bots that react to bullet fire.

Should I even bother using non-bullet waves against surfers?

I ignore them in DrussGT with my anti-surfer DC/KNN gun, but it's really your call.

FWIW I use virtual waves against surfers, but with a lower weight than in my main gun.