Melee Gun Thrashing

I've observed a few times Neuromancer's gun thrashing pretty badly - sometimes doing a full circle before firing. I'm currently trying to avoid this by accounting for an extra of max(time-till-gun-turns-to-angle,time-till-gunheat-is-0) in my PIF time, but I wonder if anybody else has come up with some way to avoid this problem?

So is your firing condition just that the previous tick's aiming completed? And if it didn't, you re-aim? That's all I do and I haven't noticed thrashing, but I don't watch as many Melee battles as I probably should. Projecting extra ticks in the PIF seems like a good idea. Maybe also try adding a factor into the kernel density evaluation that penalizes angles that will make you fire late?

Yeah, that's it. I'm hoping that the extra PIF ticks will cause more spread in the enemy movement, correctly accounting for the increased uncertainty, but I think with the sample sizes we are looking at that isn't really good enough. Perhaps there are points hiding in not going for angles which will take a 180 degree gun rotation, although I really doubt it...

Not sure if you did this already but you could try to bind the targeting to the gun heat. The closer it comes to zero gun heat the less it changes the once found target/area. But i guess if your gun shoots 'blind' you have to weight the new (maybe better target) to the couple of turns you might loose. Because especially in the beginning of the battle 'trashing' is not that bad if your radar detects an enemy that is sneaking up to you (in this case i wouldn't call it trashing - its more likely an emergency reaction). Overall i would guess your targeting is a little to picky dependent on your movement and battle state. Its like 'oh this one is nice ... no wait this one ... oh hang on, this one looks nice ... hello what are you doing right behind me?' :) So i guess you can just let the targeting more space (dependent how many opponents left) to pick a target/area and should be fine.

I found I was waiting for this tick's targeting to align to within 40/distance of the current gun angle before I would fire, so now I just wait for the current (getGunTurnRemaining() == 0 && getGunHeat() == 0) and then I fire. This will lower my accuracy, but I will fire much more often, so I'm interested to see what will happen!

I guess this makes no difference. If the targeting is sound, it should be within 40/distance on this turn as it is at zero at the next turn. Anyway, this will not solve your trashing issue :). If the gun is on its way to lets say PI and the next turn the targeting decides no its not PI its PI/2 your gun will trash between the targets and will not shoot at all for the time it 'trashes' between two headings.

I think the trouble is if there is say a peak at 3*PI/4, and another at 7*PI/8, and both are almost of the same likelihood, then even though the gun can easily turn to both, if they keep changing which is better then I might never end up shooting. Now, as soon as I have a single tick which the best angle changed less than MAX_GUN_TURN_RADIANS, I will fire next turn. Although it seems I have lost some score with this version, so maybe it was better before??? I know I need to do some serious work on my gun, it matches vs all the top bots I get much lower bullet damage.

Yes thats how it works if you take gunTurnRemain() before fire() (worst case is checking against 0) but with 40/distance you have a good value that it happens very rare. You just have to decide whats better for you - shooting one tick earlier (with 40/distance) or shooting more precise with one tick later (zero check). I spend quite a while on this issues and finally decided to go all the way with zero check. You also have to decide what bullet power to use - the one that is used to calculate the angle or the current one. Both have some pros/cons to. Shooting if the last target is not the same as the current target is also something you have to decide.

Hmm its hard to explain for me right now but even with zero check you can end up with not firing. If your gun targeting constantly decides to change the target/area your gun will never (at least less often) be zero as you wish. That mostly happens on loose radars, every time the radar sweeps to the opposite side and finds a better target the gun begins to rotate to this point - the radar sweeps back and decides oh this target is better (consider the movement as well) so the gun has not finished its turn and gets a new target - and so on.

A quite good test to see if your gun has trashing issues related to your movement is putting your bot against 9 Sitting ducks. If he misses some shoots or break the fire frequency to often you have something to change.

If it comes to score, my experience tells me that +-0.3 after 5000 battles translate to no change at all. I see you have a 0.04 difference and this is clearly equal to the last version. In melee it depends on what start battles you get to bring all the pairings up. I have seen jumps of 0.8 score even after 15k battles just because the start battles where to easy.

Maybe it helps: i have a test bed of some sample bots (always the same) and let it run 100 rounds ... i call it 40k/100k+ challenge. 40k = 100 firsts 100k+ = dmg. If your bot loose just one round he has some radar/movement issues. If he gets less than 100k dmg the gun need some changes. To be one of the top bots i guess you have to try 110k+ or more. I use this challenge almost exclusively to decide if i had made progress or not, because it runs fast and has almost every battle state i have to take care of in it. I might be wrong with it but it served me well so far.

Take Care

edit: not sample melee bots just sample bots

Thank you for the info - I often wonder how other people test their bots =) I know I did a similar technique for 1v1, I test a lot with DoctorBob to get my surfing right, as well as RaikoMicro for my stats systems. It seems to have worked well there =)

However, you have the ways I check for targeting error wrong. The first way (1.9) aims, then checks if the gun is within 40/distance. If so, we fire. The other way (2.0) checks if gunTurnRemaining() is 0, sets gun to fire, THEN aims. So, the second way will fire more than the first way even though it is checking for 0 instead.

Uhh mate stop confusing me :) .. i thought i figured it out and would never think about it ever again :)

The way you describe it was how i was understanding it.

1.9: gun heat has to be zero
calculate angle
check angle (if you check here against zero it almost never shoots, but with 40/distance it will shoot)
fire
next turn: bullet is on its way

2.0: gun heat has to be zero
check angle (zero)
fire
calculate angle
next turn: bullet is on its way

So both versions are the same, they shoot one tick after the gun heat is zero. But 1.9 has the advantage of shooting in cases where the gun is almost pointed to the target where 2.0 has to wait one more turn. If both versions are already pointed to the target then there is no difference. Thats how i understand it and therefor it looks to me that the first one shoots more often and the second one is more precise. Am i wrong with this? Man this stuff really confuses me :)

Hopefully I won't confuse this further, but I think the two options are:

• Style 1:
  • if (gunTurnRemaining() == 0) then fire()
  • re-aim (won't effect angle used in fire())
• Style 2:
  • re-aim
  • if (gunTurnRemaining() < 40 / distance) then fire()

So the first option just sees if your aim from last tick has completed, fires, and then continues re-aiming for next tick (which won't affect this tick's firing angle). The second option requires that the firing angle remains somewhat stable from last tick to this tick. It's also sort of the case that the first option is aiming 1 tick further into the future, since the second option will hold off firing if the aimed firing angle doesn't line up with the next tick's firing angle. FWIW I used to do Style 2 (Dookious, early Diamond, but with 18 / distance) and now use Style 1 in Diamond.

Style 1 makes it a lot easier to deal with firing pitfall.

Sorry, I guess maybe that was clear already. The reason the zero check thrashes less is that it only requires that the last gun turn was <= 20 degrees, while "re-aim and check within threshold" requires that the firing angle somewhat lines up two ticks in a row. (Though 40 / distance is a pretty big threshold, too - I always used 18 / distance.) And while the zero check is more precise, it's also in a sense projecting one tick further in to the future, since the other one is effectively aiming one tick later (by vetoing if the current gun heading isn't close to how we'd aim this tick).

Using Swarm Targeting with gaussian kernel density usually gives a single angle which doesn´t change often.

Gun thrashing means the bot keeps changing its mind every tick. Usually happens when you target the closest bot and there are 2 or more bots with similar distances.

Swarm targeting (which is what I am using) can change rapidly too, because of the discontinuities caused by scanning new robots. For instance, if you are aiming towards a bot, then scan them and discover they moved further away and in a movement pattern you haven't seen before, suddenly it is better to target a bot on the other side completely. Of course, I'm using a square kernel instead of gaussian, I might try a 1/(x^2 + 1) kernel sometime but I've never found improvement over square when targeting.

Uniform kernel gives a bunch of tied best angles. If you use random tie-breaking and recalculate every tick, then the gun can thrash a lot. Generating a random number only once per shot solves the problem. I used it before switching to gaussians.

But it doesn´t solve the problem of turning the gun 180 degress. Besides Swarm Targeting, the only thing my bot does to avoid it is trying to stay near walls/corners.

Most articles dealing with gun thrashing in melee try to lock the gun on a single target.

Hmmm, I weight each hit based on the inverse distance that the KNN point had to the current point, so I don't have that problem. I'm just thinking, that isn't made equal on a per-enemy basis, so if one enemy has KNN points closer together its points will be weighted higher. Hrmmm... at the same time surely those shots are of a higher certainty? Will need to test.

Maybe inverse distance is overflowing kernel density estimation. When KNN distance is too low, classification score tends to infinity. The result is a bunch of tied angles with infinity classification score. Depending on the tie-breaking being used, the gun can trash a lot too.