Talk:Maximum Escape Angle

I feel weird about not crediting Albert for the text on this page. I like removing sigs from topic pages, in general, but should we maybe add a "Credits" Subheading to pages like this to recognize the original / primary author? --Voidious 00:38, 12 November 2007 (UTC)

It is a wiki... the point is to have no designated author. It is probably best to just credit original authors on the discussion pages when moving the old articles. The exception would be archived articles that are no longer active, which should be kept in their original form. That NanoLinearTargeting page, for example, was still active and useful, so it had to be wikified. I'll put a credit to Kev on the discussion page for Linear Targeting. -- AaronR 00:45, 12 November 2007 (UTC)

Yeah, I tend to agree with you, but the fact that we did have the credits there for so long makes is what makes me think twice. Putting a credit note on the Talk pages seems cool with me; I definitely think the pages look cleaner without sigs cluttering it up. --Voidious 01:06, 12 November 2007 (UTC)

Hey AaronR - I liked your clean-up of this page, except for one thing: why replace the semi-colon as super-comma stuff near the top of the article? I think it's a little more clear that way, as long as you know that semi-colons can be used that way (in place of a comma for lists of lists). =) --Voidious 01:06, 12 November 2007 (UTC)

While semicolons can be used in certain contexts for lists of lists, they don't work grammatically in exactly this case. I'll try to edit it to be more clear. -- AaronR 01:25, 12 November 2007 (UTC)

Deleting my previous comment here. I still am not convinced my usage was incorrect, but I prefer the phrasing we have now, in any case. =) --Voidious 01:35, 12 November 2007 (UTC)

Imperfect Animated GIF of MAE

The main lack in this is that the robot never tries to turn in the opposite direction once it has started turning in the one direction. Those side wedges might be filled in a bit if it did. This shows it at different initial velocities, and is projecting ahead 24 turns.

http://www.tfsnewworld.com/csdgn/files/MAE.gif

— Chase-san 08:29, 25 January 2011 (UTC)

Hmm, interesting. I was doing some work on a movement table system here, and I though I'd compare it's movement paths when your picture there (for initial velocity of 8)

http://rednaxela-robocode.dyndns.org/data/MEA2.png

It seems that turning in the opposite direction once turning is not required to fill in those wedges. Simply slowing while early in the turn (the cyan section) works.

--Rednaxela 03:15, 20 February 2011 (UTC)

Unfortunately this still doesn't settle the argument of whether slowing down during turns helps achieve better MEAs since in our prediction algorithms we generally are allowed to turn back in the other direction =) --Skilgannon 06:02, 22 February 2011 (UTC)

I've been using the asin(Vbot/Vbullet) formula for ages. But in my mind it should be atan(Vbot/Vbulet). Am I right?

It is not a big deal to over estimate MEA with asin. but the over estimate could be as bad as 30% for bullets with fire power equal to 3.

asin formula is when your opponent move perpendicular to your head on angle atan formula is when your opponent move perpendicular to your hit angle ;)

However, the first one is greater, therefore the max (of them).

I am arguing that the asin(Vbot/Vbullet) formula has an assumption in its derivation, which leads to the overestimation of the angle. The easy way to see that use of the asin is wrong is to assume that bullet speed is equal to the bot then asin gives 90 degrees, but you will never hit the bot this way, by symmetry MEA in this case is 45 degrees. Note that atan does it automatically.

90 degrees is correct, since you know the bot is restricted to that half of the field, since if it came towards you your bullet could catch up with it. To make it a little more absurd, what if the maximum bullet speed was 7, and bot speed was 8? According to the atan formula, your slow bullets will still hit the bot, even though a real strategy could be for the bot to run away faster than the bullets go. The asin formula is not defined in this case, which makes more sense, since the bot might never get hit (assuming infinite field size of course).

Let's rephrase this: if you were the bot making the movement (not the firer), then what angle would be optimal for you to move at? Well, the one that lets you access the largest MEA, of course. What gives you the largest MEA? Not having a component of your movement going towards the fire location. Think of the x and y components separately, for the atan movement path if the bullet is fired on x axis then by orbiting the fire location you are reducing the x component of your distance to the fire location in the hopes of increasing the y component more. However this tradeoff is not worth it since it makes the bullet hit you sooner, meaning you cannot access the higher MEA.

In the case when the firer is moving and there are multiple bullets in the air each from different locations, it isn't always possible to move perpendicular to the original wave because you are in 2D and can only move perpendicular to one line at a time, and you are trying to dodge multiple bullets. But if you chose to, and didn't run out of space, you could make your MEA right up to the asin(vbot/vbullet), for a single wave at least. And if the enemy gun didn't accept or shoot at these higher angles, you could dodge all of their bullet like this.

You've made one thing wrong — it's the bot, not you, that selects the escape angle. if the bot move perpendicular to you, and your bullet speed is the same — you will not hit him definitely. Whatever formula you use, the fact of not being able to hit will never change, in this case. Therefore it still can't prove it's wrong.

The only way to prove asin formula is wrong is by giving a formula that is greater than or equal to asin formula all the time (and that formula must satisfy the game physics as well)

Anyway, if your opponent moves orbital, not perpendicular, asin formula will make higher power bullet shoot at an angle greater than needed, and lower power the less — decrease hit rate. Therefore using max_vel/bullet_speed withou trig may be better in this case (if you don't cape gfs, it will never be an issue)

Well, the asin gives MEA where M stands for maximum :). Also, there is a hidden assumption that the bullet speed is always faster than a bot (i.e. a bot cannot run away from the bullet) and that the battlefield is infinite.

This asin is probably the oldest formula in my framework. It is dated by 2015 and was used even in an earlier bot. Yesterday, I decided that I am ready to challenge it. Actually, it was part of the effort to calculate the battlefield constrained MEA. I think I finally get it, though it still assumes that a bot can reach max speed instantaneously.

Now I expect my guns to be better especially in melee. I hope they will not shot into a wall when aiming at Diamond hiding in the corner. Hopefully my bot will move up the ladder a bit.

The thing is, if the bot moves slightly away then it increases the bullet flight time, allowing the bot to reach a higher MEA than just an orbit or chord.

Personally, in DrussGT I use a precise MEA since it gave better results. But if you have some limitation on whether the bot can exceed the calculated MEA (for example you log them to bins) then the asin is better, otherwise bots could potentially move to angles you can't shoot at.

Are you using precise MEA to scale? or just to cut. From the version history I think it is the latter, but Understanding DrussGT says former ;)

Both.

I've just calculated it. If it is correct moving away helps.

            latVel = Math.sin(angle) * 8;
            advVel = -Math.cos(angle) * 8;
            timeToHit = distance / (bulletSpeed + advVel);
            mea = latVel / (distance - (timeToHit * advVel) / 2) * hitTime;

This is the formula. It thinks that the bot is moving at full speed and with brute force search I got these results:

Bullet Power 1:

LatVel: 7.762365810207972 AdvVel: -1.9353751647973414

Bullet Power 2:

LatVel: 7.6504380477042835 AdvVel: -2.338973637781894

Bullet Power 3:

LatVel: 7.468643411977614 AdvVel: -2.8669435963624013

Distance doesn't change anything if it isn't zero.

timeToHit is not taking in account that the bullet moves at some angle too, i.e. we need to use bulletSpeed*cos(MEA). In above we assume that 'a' is angle between line connecting bots and the velocity of the target.

The last line is not precisely correct as well. There should be no factor of 2, and you forgot the atan. It should be

 mea = atan( latVel / (distance - (timeToHit * advVel)) * hitTime );

But the last thing could be simplified a bit if you notice that

latVel = bulletSpeed*sin(MEA)

Moving away is always bad idea from the MEA prospective within robocode physics.

Look at the values that he posted for latVel vs advVel, all with the same 8 speed. For a very small reduction in latVel you can get a big increase in advVel. Increased advVel means you get a longer time until the bullet hits, so in that extra time you can add more latVel components, giving you a higher MEA. This is offset somewhat by being further away, so your latVel/distance is slightly smaller so each latVel increases the MEA a bit less. But this is more than compensated by the extra time until the bullet hits.

Aren't we confusing increase time to hit with increase EA? Longer time to hit has an advantage to decrease bot shadow, but it is not nesesary results in increase of EA.

Continuing our discussion of border cases, if bullet and bot have the same speed. The best strategy is run away from the firing bot. The bullet will never catch up, but the EA is the smallest possible here, i.e. zero.