Finished walk cycle, now how do I actually move it?

[theremin]

Hi all,

I created a walk cycle animation for a nurse character that I made, and I'm having trouble figuring out how to actual move the character on screen in my game. I'm wondering if anyone has any advice or pointers for me. There are plenty of books and tutorials about creating walk cycles, but I've found very little information about actually setting a completed walk cycle in motion.

The main issue I'm having is figuring out how to strike a balance between speed of sprite movement, frame rate, and position of the character's feet. As far as I can tell, I have three different options. But I'm pretty new to this, so perhaps I'm missing something obvious?
"CHUNKY"
This was my first attempt. The feet plant firmly in place (which is good), but the animation isn't as smooth as I would like it to be.
Forward motion: 2 pixels per frame
Frame rate: 8 fps

"SLIDE"
This was my second attempt. The motion is much smoother in this one, but the problem is that the feet "glide"; each time a foot plants, it sort of slips/slides backward as the sprite moves forward. I created this by using the same 8 frames from the "CHUNKY" animation, but the frame count is doubled: each frame is simply duplicated and pushed forward 1 pixel to create the intervening frames.
Forward motion: 1 pixel per frame
Frame rate: 16 fps

"SMOOTH"
This is my most recent attempt. The motion is smooth, and the feet stay firmly planted, so... yay? But there are 16 unique frames, so it will be a lot of extra work to create all of my sprites like this (and a lot of work to create other non-walking animations with a consistent smooth look). Furthermore, I almost wonder if it's "too smooth" and loses some of its retro feel because that. A 16-frame walk cycle seems a bit excessive for pixel art -- or am I wrong?
Forward motion: 1 pixel per frame
Frame rate: 16 fps



Does anyone have any advice? Am I missing something obvious? The only person I've been able to find talking about this "foot slipping" issue on the Internet is this fellow right here, but unfortunately his advice wasn't enough to help me solve this. It seems like I should be able to get smooth motion with an 8-frame walk cycle (isn't that what everyone does?), but for some reason I'm really struggling with this.

Thanks for your help! 

[Mike]

This a problem I have myself with my own games.  What I normally do is the sliding technique but I know that's not right.  The way I see if the only way to get this working right is to set a speed for your characters before you animate them.  Then based on that speed decide the beat for the walk/run.  Anyway for me it's a lot of trial and error.  The best thing that can be done in this situation is to not go too final with your animation before you test it in game.

Honestly I would love to hear more solutions for this because I hate that sliding feet thing.

[Kasumi]

It's possible to do an 8, 4, or even 2 frame animation that doesn't slide. But fewer frames will certainly make the movement more jarring.

The amount the character's foot on the ground moves every frame during the loop would have to be the same, and have to match the walking speed.

For instance: The character's resting foot moves back two pixels each frame in the animation. Each animation frame is displayed for 1 frame in game. The character must move at 2 pixels per frame. You can't avoid slight sliding with a slower speed, though. If the animation frame is displayed for 2 game frames, the character would have to move 1 pixel per frame. But that would mean the character would move a pixel every frame, while the character's foot would move only move two pixels every other frame because of the animation creating some jerkiness.

(pixels per frame to move character) = (Number of pixels the foot moves back each frame)/ (Number of game frames each frame of animation is displayed)

Or, you update the character's position only on the frame when the animation is updated, and you move the character by how many pixels his grounded foot moved backward.

Either way, you can plan it out regardless of how many frames are in the walk cycle or your character's speed. You just have to do some math with this in mind.


The foot in this moves back two pixels each frame except the last frame it touches the grounded where it only moves back one.

I'm actually not sure it's worth it to do this, but I guess it depends on the sort of game. If it's a game like Little Computer People it may be worth doing, but for an action game with acceleration you can't really avoid sliding in all cases while the speed is changing.

[theremin]

Thanks for the replies, this is good information. Basically, I've learned that I wasn't missing anything obvious, and it's hard to get right

[PypeBros]

..., but for an action game with acceleration you can't really avoid sliding in all cases while the speed is changing.

Technically speaking, you can. what it costs is a more dynamic animation rendering where you only move to the next frame if the offset is above the move offset of that frame, or accumulate pixel fractions otherwise.

There are cases where it doesn't matter, especially when you go for a cartoon animation as it's well-known that cartoon characters move their legs immediately at full speed in the air until the regular physic laws realise what they're doing and propels them forward. But imho, we're better to keep that for slippery grounds and have non-sliding animation everywhere else. Initial Mario running animation was supported by a "slippery floor makes me dizzy" mention on the arcade cabinet, afaik.

[theremin]

Technically speaking, you can. what it costs is a more dynamic animation rendering where you only move to the next frame if the offset is above the move offset of that frame, or accumulate pixel fractions otherwise.

I'm curious what you mean by this. Can you explain in more detail?

[Kasumi]

Hmm. I guess I had thought that would lead to choppiness. I was projecting my own project and thinking for something like a Sonic project where the character moves around 8 pixels a frame, it doesn't really work. I wouldn't want to halt updating his position on screen to wait for animation frames in this case, and I wouldn't want to skip animation frames to catch up with movement either, so I deal with sliding. It's definitely fine for slower movement, however.

theremin: The animation should update only when the character has moved two pixels. The character is traveling at a speed of one pixel per frame. On the first frame, he has "moved" one pixel, but I don't update his actual position on screen or his animation. The next frame he is to move another pixel. When this is done, I update his position on screen and his animation. This also has the bonus of automatically and properly changing the character's animation speed to match his movement speed.

[rikfuzz]

You're probably not going to even notice it in game, especially there's any scrolling going on.  I wouldn't advise updating the frame as infrequently as the sprite, unless it definitely won't suffer for it (input lag, choppy gameplay etc) which it almost certainly will depending on game type.  You don't get many 6/12fps games these days! 

[PypeBros]

Hmm. I guess I had thought that would lead to choppiness. I was projecting my own project and thinking for something like a Sonic project where the character moves around 8 pixels a frame, it doesn't really work.

It all depends on how many frames you've got in your cycle and how many pixels your animation move between two frames. I did it with my appleman walk cycle: , which is 8 frames for the cycle and moves by 2 pixels every frame.

Ideally, in-game, it moves at 1px/frame (60 fps) -- which means it actually stays in place for two frames, then move 2 pixels away, then wait for 2 frames, etc. It has also a "charge" move where it moves at 2 px/frame (thus updates position on screen with every frame) for some steps and then continuously slows down back to 1px/frame.

The movement then goes that way:
F0: move by 1.5 pixels is deferred, render frame A at (100,100) (defer = +1.5)
F1: move by 1.5 pixels is applied, render frame B at (102,100) (defer = +1.0)
F2: move by 1.4 pixels is applied, render frame C at (104,100) (defer = +0.4)
F3: move by 1.4 pixels is deferred, render frame C at (104,100) (defer = +1.
F4: move by 1.3 pixels is applied, render frame D at (106,100) (defer = +1.1)
F5: move by 1.3 pixels is applied, render frame E at (108,100) (defer = +0.4)
F6: move by 1.2 pixels is deferred, render frame E at (108,100) (defer = +1.6)
...

Visually, this "step, pause, step, step, pause, step, step, pause ..." is perceived as a continuous movement and (imho) is more coherent than if I had some sliding of the character at varying speed while keeping the animation speed constant.

Of course, slowing down the walk to e.g. 1/2 pixel / frame would start showing its limit and if such a large range of speeds is desired, I'd need another animation (and likely, the apple wouldn't tip-toe the same way it walks). Same for going much into a faster move (you can't increase your walking speed indefinitely without changing the way you move your limbs). So it offers *some* flexibility, but it's not a silverbullet for shooting all the situations.