Nice example!

Hope you're okay with some rambling because I've got some notes about diagonal movement: it's generally a good idea to watch out for your diagonal movement speed. Moving along the x or y axis alone both provide the same player speed, but if you're moving on x and y at the same time, then the resulting diagonal movement vector comes out longer than intended. It actually turns out to be a pretty significant difference if we use the Pythagorean theorem to check:

Length of axis-aligned movement (x=0, y=1) = sqrt(0^2 + 1^2) = sqrt(0 + 1) = sqrt(1) = 1 _________________ Length of diagonal movement (x=1, y=1) = sqrt(1^2 + 1^2) = sqrt(1 + 1) = sqrt(2) = 1.41 |

So by default, diagonal movement is almost one-and-a-half times as fast as your intended speed! This is fine for non-time-sensitive games, but it can be a noticeable problem in action games, because it means that moving diagonally gives you an unintuitive (and very-video-gamey) speed advantage.

To fix it, you can do the following, or something similar:

// tunable max speed, in any aribtrary direction speed=2 // default state for frame: no movement // these are "input x" and "input y" values: ix=0 iy=0 // offset input x/y to represent buttons held if (btn(0)) then ix-=1 end if (btn(1)) then ix+=1 end if (btn(2)) then iy-=1 end if (btn(3)) then iy+=1 end // THE IMPORTANT PART: if (ix*ix+iy*iy>1) then // movement vector is longer than 1 unit! // normalize it: dist=sqrt(ix*ix+iy*iy) ix/=dist iy/=dist end // finally, apply the input direction to the player x+=dx*speed y+=dy*speed |

In the case of 8-direction movement, the diagonal vectors always end up being (0.707,0.707) with optional negation for each axis. This is because 0.707 is the square root of 0.5:

length of adjusted diagonal movement (x=0.707, y=0.707) = sqrt(0.707^2 + 0.707^2) = sqrt(0.5 + 0.5) = sqrt(1) = 1 |

[Please log in to post a comment]