Yes, but that description is a mix of DCBot's and Shadow's current method. In DCBot I used the "iterative search" to speed up the trig needed to convert the enemy's past position to the position it would be in the current situation. Doing that step by step is slow, like you mentioned. But then I remembered I could just convert my relative position to the enemy once at the beginning and then the playback of the enemy movement becomes just additions of dx/dy. And the final firing angle conversion is just 1 addition. It's so simple! I don't know how I didn't come up with it earlier. Now that I think of it, I can probably compare squared distances and save a sqrt per step. About the rotated battlefield, I thought about that, but that would reintroduce the trig complexity and would probably end up slower than the original method.  ABC No, no need to introduce trig with a rotated battlefield. You have, instead of your typical if(x < 0  x > width  y < 0  y > height) bounds checking, something like if( m*x  y/m + k < 0  m*x  y/m + k > width  ... I doubt the math is right, but what I'm saying is having a rotated battlefield, instead of translating the point to check a standard battlefield each time.  Skilgannon
