Let me explain my question:

I have a sprite sheet with the different frames of the animations. Each animation has 8 frames.

Based on the player's input, I modify the character's coordinates, thus I also modify where the given frame of the animation should be rendered. Based on if the character is running or walking, I either speed up the animation or slow it down (since while running he should take 3 steps per second, and 2 steps per second when walking, so I play 12 frames per second when he's running, and 8 when he's walking).

However in the case of the walk cycle, I also get an unwanted side effect: the character "moonwalks". This means that while the X and Y coordinates are changing, thus the character is moving forward, his current sprite does not change at that instance. This gives the impression that the character is sliding or skating on his feet.

I'm trying to create something similar to Prince of Persia or Flashback. As I see they don't have this problem in their animation, and I wonder how could I eliminate it in mine.

I can not simply just speed up my walk cycle animation, since a fast walking looks weird. Maybe I should have more frames in my animation? Is there a simpler way of doing it? When I search for sprite sheet animation algorithm I find so little.

Update: I have added an image to demonstrate the issue. As you can see, the character does this weird sliding.

enter image description here

  • \$\begingroup\$ The original Prince of Persia (from 1989) achieved its fluent animations by only allowing transitions from one animation to another when the animation cycle was finished. The result looked really well but resulted in very clunky controls. \$\endgroup\$
    – Philipp
    Jul 27, 2016 at 9:09
  • \$\begingroup\$ I am not sure if I understand your question correctly. A video would really help a lot. \$\endgroup\$
    – Philipp
    Jul 27, 2016 at 9:10
  • \$\begingroup\$ @Philipp Your first suggestion seems okay, but I wonder if there's any other options. I've updated the question with the animation. \$\endgroup\$
    – Letokteren
    Jul 27, 2016 at 9:18
  • \$\begingroup\$ Looking at the gif animation I would say that this is just a poorly animated walk cycle and not a technical problem. \$\endgroup\$
    – Philipp
    Jul 27, 2016 at 9:20
  • \$\begingroup\$ youtube.com/watch?v=yPqKJDpwjSM If you look at the original DOS version, you can see that there is still a bit of sliding. That's just the way with sprite animations. If you can find some way of incorporating 2D Inverse Kinematics, you can completely eliminate the sliding issue. \$\endgroup\$ Jul 27, 2016 at 12:29

2 Answers 2


If I recall correctly, both Prince of Persia and Flashback (as well as its predecessor, Another World/Out of This World) only allowed movement in set 'steps': if the player ran or walked, they would move a predetermined amount of space (i.e. 8 pixels for a single step, or 32 pixels for a running stride). They were effectively tile-based, and the player's avatar was confined to moving increments of one tile. As mentioned by Philipp, this led to very smooth animation but could feel 'floaty' as players didn't have absolute control over their avatars. Clever level design stopped this from being an issue - as well as the fact that the terrain didn't scroll (the action just moved from screen to screen).

The animation is the problem here, rather than anything programmatic. I've opened up your .gif file in Adobe Fireworks, and I can see that the feet are only changing position every four frames while the floor is moving at a constant rate, which looks to be four pixels per frame. The player's stride appears to be around the right length - 40-odd pixels - but because the feet don't move as fluidly as the ground, it looks like they're sliding.

I took the liberty of putting together a gif showing your character walking over a stationary floor. The stride looks a little odd:

walking animation

Prince of Persia and Flashback both used rotoscoping for their animation, which gave them their fluidity. I don't suggest you go down this route yourself, but you really need to study how people walk- your animation doesn't seem very natural at all.

To really address the issue, you'll need to re-animate your walk cycle. However, for a quick fix you could:

  • slow down the movement of the terrain (though I suspect you'd end up with rather jerky scrolling)
  • add more frames to your walk cycle (the foot in contact with the floor needs to animate at the same speed as the floor)

I'd be inclined to take the second approach, though it means more work.

Animation is hard. Even harder than programming. But if you really want to make your game look good, you could do much worse than invesing in some books on the subject. I've added a few links to ones I personally recommend below. The only way to get better at animating is to practice, so don't worry if your early efforts don't work out.

Animation books:

  • \$\begingroup\$ Thanks for the book recommendations! I was looking for something like this, since I wasn't sure if the fault is in my algorithm or in my sprites. It is really one of my first efforts at animation. Maybe I should start with something little instead, because even this took me like two weeks. In the mean time, I was checking other games' animation frame by frame, and as I see this sliding/skating thing is not uncommon, but is very visible in my case since it's trying to mimic real life more than the usual. I will check out these recommendations nevertheless, thank you again! \$\endgroup\$
    – Letokteren
    Jul 27, 2016 at 10:59

A lot of games with walking animations (2D and 3D) suffer from this problem, and big ones, not just indies.
I think it would be solved fairly easy by having the animation system support marking the spot where each foot touches the ground in each frame.
Then the algorithm that moves the animated sprite should just make sure that the same spot E.G. left_foot is always in the same place in relation to the background.
This would of course create problems with the time between frames, which the animator could not control anymore, but I think with some adjustments and collaboration between artists and programmers, it could be done effectively.

I see one restriction arising from this, which is that consecutive frames where both feet are on the ground, should have both reference points fixed and not moving relative to each other. But that's how walking in the real world works, anyway.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .