Guaranteed Hit?

Jump to navigation Jump to search

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

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:Polylunar/Guaranteed Hit?/reply (7).

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