This simple method has worked fine so far for getting the enemy to look at the player's position. However i decided to add some extra code to get the enemy to gradually rotate towards the player using this method:

Now the problem i am having is that when the player moves for example from 360 degree target to 1 degree then the enemy rotates the long way round to move to the 1 degree instead of simply adding 1 degree. Any help on how to correct this problem would be welcomed. I have a picture below:

\$\begingroup\$@Dialock Thanks For the suggestion it works like a charm for rotating 2d sprites. However i also have a body in farseer that needs to be rotated using forces and since this function sets the rotation some extra work will need to be done to get it to work properly by converting to force.\$\endgroup\$
– ReeFeb 19 '13 at 22:17

\$\begingroup\$@Dialock Just replaced all my rotations with your suggested method, it now works fine with farseer for steering. I forgot about the old SROT method when applying transformations it appears that i can get much more efficiency with farseer by setting rotation first for my enemies. Sorry about all of the notifications.\$\endgroup\$
– ReeFeb 21 '13 at 1:33

\$\begingroup\$there's a problem with your suggestion in that the enemy gets stuck in a rotation. However you managed to help me figure the problem out. Instead of multiplying the difference by -1 its better to make an if statement for when the rotation is >180 and another for when its<180. When the difference is >180 we need to minus 360, if it is < 180 then we need to add 360. This approach gives us the residual left and right turning <=180. Thanks for your help :)... ooh and the rest of your solution is fine, just had to remove the if(math.abs) bit.\$\endgroup\$
– ReeFeb 18 '13 at 23:12

You're probably better off not representing your orientations as angles in the first place, for a couple of good reasons: for one, because there's an inevitable discontinuity of representation somewhere; but even more importantly, because it leads to a host of unnecessary trig calls — the Atan2() call here is one example of that, but there are no doubt a host of Cos() and Sin() calls down in the rendering engine somewhere. Instead, I'd recommend representing orientations (and in particular, the enemy's facing) as a (normalized) vector of the direction they're pointing in; this lets you determine which side of your enemy's facing the player is on by doing a simple dot-product test between the vector from enemy to player and the normal to the enemy's facing, and since the normal to a 2d vector (x,y) is just the vector (y, -x), this leads to the following code that replaces all of the awkward code above with two multiplies and a compare:

(Note that this code assumes a world where X points rightward and Y points up - that is, where the positive Y axis is 'left' of the positive X axis. If your world works the other way, you'll want to flip the TurnRight() and TurnLeft() calls. Also, you'll need to complicate this slightly to handle the case where your enemy is already facing in the correct direction, but I presume that's already being handled somewhere else.)

\$\begingroup\$Wow! That looks like a very nice solution! I used cross-vectors before, but this solution seems much simpler. Does this approach also work if you don't have a point to focus, but a direction instead?\$\endgroup\$
– TaraMay 3 '15 at 17:12

\$\begingroup\$NVM, made a mistake. Your answer should be the accepted one since it's a lot simpler. Also, to fix the case when the enemy is already facing the desired direction: Weight the rotation speed by the dot product between the currend direction and the desired one.\$\endgroup\$
– TaraMay 3 '15 at 17:20