Talk:Polylunar

It sure is funny poking at updating this team I wrote in 2009, to use more of the framework of a more advanced bot I made in 2010, in the year 2021. :)

"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?

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.

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.

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.

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.

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.

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.

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.