Guaranteed Hit?

Jump to navigation Jump to search

Guaranteed Hit?

"Guaranteed Hit Targeting" is a term I've only seen mentioned on this page. Based on the fact that Polylunar likes to get in close and ram, am I right to assume that a target cannot evade a bullet if it's fired under a certain distance? Or is there more to it, being a team-only targeting method?

Enamel 32 (talk)00:21, 24 July 2018

hit rate of max escape angle based random targeting is roughly bot width in radians / max escape angle

max escape angle never changes for the same bullet power, and bot wdith in radians is roughly 18 / distance. Then, as long as the distance is close enough, random hit rate can be close enough to 1, making a hit guaranteed.

note that the actual hit rate formula is harder to calc when edge cases are considered, but the main factors affecting hit rate are still covered.

Xor (talk)02:40, 24 July 2018

I use asin(botWidth / (distance - 18)) which takes bot width and the square shape of the bot into account(Isn't it better than botWidth / distance) but I am pretty sure that everybody else uses the formula which calculates the exact width.

Dsekercioglu (talk)11:09, 24 July 2018

asin(botWdith / (distance - 18)) is incorrect because when distance = 18 it gives NaN instead of PI.

if you assume a bot is a circle then asin(botWidth / distance) is correct; if you assume a bot is a square then atan(botWidth / (distance - 18)) is correct as long as absolute bearing from source to target is 0, 90, 180 or 270 degrees.

however, a moving bot is neither a circle nor a square, that’s why precise intersection is used.

Anyway, botWidth / distance is fine as long as distance is far, and the result is almost the same as the asin/atan version.

Xor (talk)11:45, 24 July 2018

It gives a NaN but a distance less than 36 is impossible in robocode. botWidth / distance is always incorrect, asin(botWidth / distance) is always incorrect too but it less incorrect however, asin(botWidth / (distance - 18) is correct in four cases and gives higher results than all other imprecise formulas which always results in closer results to the precise one.

Dsekercioglu (talk)12:00, 24 July 2018

a distance less than 36 is impossible in robocode, but a correct formula should give correct result in this case. So I prefer the atan approach.

asin approach is incorrect by geometry as well.

however trigs are always expensive, so using 18 / distance is acceptable since it gives similar result.

Xor (talk)17:30, 24 July 2018

I haven't checked it in Java but asin(positive infinity) results in positive infinity which is true for the bot width formula if we assume that the bullet starts from the robot location. The same case also happens with Traditional MEA when bullet speed is 0.

Dsekercioglu (talk)17:51, 24 July 2018

Wrong. Infinity means nothing in radians. Valid values are 0~2pi or -pi~pi or so.

An angle should never be infinty radians.

Xor (talk)17:55, 24 July 2018

If it means nothing can't we assume that the traditional formula is completely wrong since with a bullet velocity of 0, it will return positive infinity.

Dsekercioglu (talk)18:02, 24 July 2018

Bullet velocity = 0 is another geometrical situation. But in this case, distance < 36 should still fit in to your image. Or, it must be wrong.l

Xor (talk)15:00, 25 July 2018

Ah, thanks. I like to think of "bot width" as a "radar shadow" or "cross section" in this sort of scenario since "width" already has an established (and constant) meaning.

Enamel 32 (talk)00:01, 25 July 2018

This is a very belated comment of mine, but I'll note that Polylunar's "Guaranteed Hit Targeting" is a good bit more sophisticated than those distance-based approximations. It runs two iterative simulations of the enemy bot's movement. One for the case of maximally clockwise-around-self movement, and one for maximally counterclockwise-around-self movement, and performs precise intersection calculations to determine the range of angles where a shot will intersect the robot. Then, there is a check for whether these two ranges of angles intersect with eachother. If so, aiming within that overlap is considered a "guaranteed hit", and so Polylunar will aim in the center of that overlap when such overlap exists.

I think it's technically not quite a perfect guarantee due to some unusual scenarios the simulated paths may not account for, but it's quite close. One of the main corner cases is how, while the simulation accounts for walls, the simulated enemy does not have wall avoidance. This detail likely doesn't affect things too much for Polylunar since the distance you have to be at for guaranteed hits to even be possible, doesn't give an opponent much time to actually collide with a wall anyway, let alone avoid a wall in a fashion that gives a narrower escape angle range.

Rednaxela (talk)10:54, 15 June 2021