# What is the standard technique for shifting the frames of a sprite according to user input?

From my own experience, I developed two techniques for changing the sprites of a character that's reacting to user input -- this in the context of a classic 2D platformer.

The first one is to store all character's pixmaps in a list, putting the index of the currently used pixmap in an ordinary variable. This way, every time the player presses a key -- say the right arrow for moving the character forward -- the graphics engine sees what's the next pixmap to draw, draws it, and increments the index counter. That's a pretty common approach I believe, the problem is that in this case the animation's quality depends not only on the number of sprites available but also on how often your engine listens to user input.

The second technique is to actually play an animation every key press event. For this you can use any sort of animation framework you want. It's only necessary to set the timer, the animation steps and to call the animation's play() method on your key press event handler. The problem with that approach is that is lacks responsiveness, since the character won't react to any input while the current animation is still being played.

What I want to know is whether you are using one of these techniques -- or something similar -- in your games, or whether there's a standard method for animating sprites out there that's widely known by everybody but me.

• "animation's quality depends not only on the number of sprites available but also on how often your engine listens to user input." I don't understand the problem here - why wouldn't you listen to user input every frame? As for the second approach, you could make the animations be interruptible if you wanted. – Nathan Reed May 27 '13 at 20:29
• @NathanReed It's not that you wouldn't listen to input every frame. It's that game framerate can be variable, while 2D animation depends on a fixed timestep between frames. Failure to take this into account (either fixed game framerate, or compensation for delta time) will result in animation playback fluctuating. – RavensKrag Jun 28 '13 at 18:27

You should really keep the code for advancing animations and taking input separate.

In general, you want to keep drawing and input as separate as possible. Most games still animate when there's no user input. (The notable exception being rougelikes.) The structure of code should reflect that one does not depend on the other.

I suggest using some sort of state machine which keeps track of which animation currently needs to be played.

Then, you can just update the active animation each frame. The animation should be updated before each and every frame is drawn to the screen, not on each input tick. That way, animation will be smooth regardless of user input.

Remember to check the delta time between frames if you're not using a fixed framerate though. Animation assumes that frames will be seen at certain times, so letting the game loop advance the frame count whenever it decides to draw to the screen will give you problems if the time between game ticks is not the spacing the artist intended.

The problem with [just running an animation on keypress] is that is lacks responsiveness, since the character won't react to any input while the current animation is still being played.

You probably want to stop the current animation when the input state changes. Though, if you cut one animation and start up one which is quite different, it will jerk

In fighting games, this is called a cancel.

It can be useful if you want the animation to feel faster or punchier, but it's not always what you want. For smoother transitions, you'll need to make transition frames, or limit when certain transitions can occur. Both techniques are used in fighting games. Understanding framedata is critical to high-level fighting game play, so you might want to poke around in the fighting game community to better understand this animation style.

This is why a state machine is very helpful. It will allow you to define transitions between different states, and callbacks for when the transitions occur.

It might not be standard to use an official state machine library for this, but why roll your own when a state machine library can do the job for you?

• Nice answer. Do you really develop fighting games? I would like to know how do you handle the action triggers and the state updates. Actually I am doing all that stuff hardcoded, but I am researching script techniques to do this with XNA. – Emir Lima Nov 13 '13 at 14:28
• I do not, but I've studied them a bunch, because I think they have some of the best frame-by-frame animation in games. Also, techniques like "cancels" are important to other types of game animation as well. (As well as playing fighting games.) I think you'll have to decide exactly how to implement this on your own, as it might be too specialized of a question for stackexchange. But feel free to post a new question about it, instead of a comment like this. – RavensKrag Nov 16 '13 at 3:38

I solve this problem by keeping the animation code and the drawing code separate. I have a series of images for each part of the animation, and the code merely selects which one to draw. The drawing is handled elsewhere. My game loop, simplified for a single animated image, looks something like this:

1. Process user input. This might alter the position where the sprite is drawn.
2. Run animation code. If it's time for the next image, change the current sprite index. If the user did something, reset to the base image.
3. Blank the screen.
4. Draw whatever image is at the current sprite index.

This mostly aligns with your option #1, but the key difference is the graphics engine does not change which sprite to draw. Separation of concerns is a Good Thing.

I'd recommend you that you split the Input, Action, State and Animation in separate systems/layers.

For instance:

Input 'tap forward twice' Action 'DoRunForward' State 'RunningFoward' Animation 'RunningFoward'

The Animation layer would only concern in handle the animation logic. Rotate, scale, translate, flip images, run the key frames in the sprite sheet, execute loops etc.

It would be the State layer that would process the gameplay logic. Move the character, play sounds, change the character animation etc.

It's easier to implement state changing in the middle of a running state this way.

You can also use 2D Bones Animation. For the ”theory” you can read this. It's 3D but it can be applied to 2D by just ignoring the Z-axis.

There are some frameworks for different languages:

• There is also Spine.JS that comes with a editor to simplify creation of 2D animated sprites. The tool is not free, but is a huge timesaver and easy to work with. You bring them into game by using runtimes. The system also allows for animation blending and loads of other stuff. – joltmode May 28 '13 at 8:46