How can I avoid "Moonwalking"

Question

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.

Answer 1

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:

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:

• The Animator's Survival Kit
• Drawn to Life (vol. 1, vol. 2)
• Cartoon Animation
• The Animator's Workbook

Answer 2

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.