# Is character movement with an animated sprite controlled by the animation itself or moved manually?

How is a walking animation of a given character designed? I can see two possible ways:

The first way is to draw each frame of the animation such that, if the frames are displayed at position (0,0), the character walk but does not really move (I mean: at frame 10, the character is still at the left, upper corner of the screen). This means that one needs a way to move (translate) the frames manually.

The other way is to draw each frame such that their width grows progressively. Drawing the frame i at position (0,0) will give the impression that the character is really moving (not only walking on the same point). This way is the graphic artist that do all the job, but the animation is completely controlled by him, so he can give a specific style to the walking animation.

The first one seems to be the right way to do things, but one would need a way to say: ok, frame 0 last 50 ms at (0,0), frame 1 last 30 ms at (5, 0), frame 2 last 15 ms at (13, 0) etc...

This makes things much more complicated.

What is the best practices? What way do you usually adopt/suggest?

• Please note that this question (and the answers) largely applies to all game animations (vector 2d, 3d models), not just sprites – Clockwork-Muse Dec 30 '11 at 19:46

The first way is the most flexible and industry standard way to handle all sprites. Walking, running, attacking, animated fruit-tiles, what-have-you. The flexibility of this method is the main reason for this.

Imagine you are making a 2D adventure/platformer. You started by having your character be able to walk slowly while charging their weapon (think Metroid) and it was initially intended that he would point in the direction he is walking. But then inspiration hits you. Maybe he should moon walk backwards instead, so that he continually points in the direction he started to charge his weapon in.

With the first option, you can easily do this. If you use the second, you need to make new sprites.

However, there are some other reasons. These spritesheets/images will be smaller in total size. When it comes time to do collision detection, you'll have an easier time of it. (Pixel-perfect collisions are slow, it will be easier to draw a box around a consistently sized sprite.) And finally, you'll be able to take advantage of existing tools that are designed for creating animated sprites in the industry standard fashion. Such as ASEPRITE or Pixen

• Is there something like Pixen for Windows, besides aseprite? – Luke Nov 9 '11 at 15:32

Animated spritesheets, along with translations are the way to go. If you design your sprite classes properly, you will be able to control the flow of each animation exactly the way you want.

Consider a frame, which is essentially a Rectangle that you place at a location in your sprite sheet and "frames out" the remainder of the image. To animate a sprite, the Rectangle moves position in the sprite sheet and then displays the newly framed image to the screen. This transition is programmed and controlled by you.

By defining these transitions, you are creating your animation. The delay between each transition can be controlled, as well as other aspects of each transitions (fade in, scale, etc.).

The first is much better, people told you in other answers, but just to clear your head, yes, the frames may have different timings, frame 1 may pass with 10ms and frame 2 may pass with 30ms, but that should not be a problem.

There's a rule to gamedevelopment, that say to you to NEVER rely on the framerate to do your animations or movements. all we know, a sprite can move faster in a quad core than in a 486. Thats why you should EVER rely on delta time between frames.

How? Well, instead of doing "walk 5 pixels per frame" or doing "pass to the next frame of animation at each frame of the application" this will lead you to different gameplays in different machines. You should do: "walk 300 pixels per second" or doing "pass to the next frame of animation at each 20ms".

In pseudo code, things changes to:

entity.position.x += 5;
// will turn into
entity.position.x += 300 * deltaTime; //Assuming deltaTime is the time between last frame and this frame measured in float seconds.


and

animation.nextFrame();
// will turn into
float time = 0; //Declares this in your class
time += deltaTime / 1000;
if(time > 20)
{
time = 0;
animation.nextFrame();
}


of course there are other ways to doing, but this should help you to get started.

Another reason for the first method is that you won't have to adjust you collision rectangle as the sprite animates.

For example, if you use he second method, where the sprite gets wide, and you use a bounding box for collision, then you'll have to move the collision rectangle to cover the area of the sprite where the player is.

Using the first method, the sprite stays the same size, so your collision rectangle is always in the same position, relative the the sprite.