The best way to manage sprite sheet animations?

I can't really visualize how you end up with nested if statements, but would it help if you bundle the animation details into a separate class?
For each animation you make an object that sets up the animation.

Then build a mapping from attack_type to animation (by an array, a block of code, or attaching the animation to the attack_type itself).
Code then becomes something like GetAnimation(attack_type)->StartAnimation() or so.

Is this the best way to go about animation

No.

would you recommend something
a bit more graceful?

Yes.

All games should be data-driven.
You should have sets of data, whether in files or in code, that tell you what parts of the atlas to draw, speed, and all other information you need to know given just a single animation ID.


L. Spiro

Just adding..

I find the logic for animation switching can become quite complex depending on the sophistication of character interactions. I actually rewrote my animation class to be as simple as possible trying to minimize conditional switching as you mentioned.

Something like:

Character[Ryu].PlayAnimation(UpperCut, facing, [...optional parameters here...] ); // optionals would be like conditional play-speed(ie: underwater), etc..

(Depending on character - all my logic would be kept in a player or character class for determining animations)

Where PlayAnimation uses enumerated animation UpperCut, which is assigned the animation index. The Player plays a strip of animation from the sprite sheet based on predefined speed, position and so on which are also loaded from a file corresponding to the sheet. If you use a sheet packer, you may need to set up an editor to adjust the extraction boxes for each image you would normally use in an animation strip [otherwise you could even simply write the strip info into a text file or into header]. Also you could have it produce test play-back of the selected animation strip you're working on and provide additional information to save to file such as speed (or even frame timing for particular frames if you wanted).

It may be handy to also map out on paper - different conditions in which animations can or can't be triggered. ie: different animation triggered when ducking or jumping or running or idle. And then quickly switching animations to adapt to new user input. This is where it becomes very difficult to avoid complex if-then stuff.

Hmmmm....

The problem with preset animations is that they need to be able to change instantly. Some animations need to be cut off, while others shouldn't

allow for anything to interrupt them. My nested if statements are there because there are so many possible positions for the character to be in.

The current player can run, walk, crouch, roll, wall slide, slide, wall roll, etc. He also has different weapons and status effects which can change his

current animation, so there's all these conflicting variables. I do, however, keep all the animation stuff in its own method, so there aren't animation

changes all over each class, as that would cause mass confusion.

Are you essentially saying that I should map an ID to each animation, then just do something like call animation.Play(ID)?

EDIT: renman29, I think you pretty much understand what my problem is! My animation class itself is rather cohesive and takes

care of all the animation stuff, but it's the actual logic telling the animations WHEN to switch I'm having problems with. It

actually works fine and doesn't glitch for me, but it's a right tangled mess of nested ifs!

The problem with preset animations is that they need to be able to change instantly. Some animations need to be cut off, while others shouldn't
allow for anything to interrupt them. My nested if statements are there because there are so many possible positions for the character to be in.

The current player can run, walk, crouch, roll, wall slide, slide, wall roll, etc. He also has different weapons and status effects which can change his
current animation, so there's all these conflicting variables. I do, however, keep all the animation stuff in its own method, so there aren't animation
changes all over each class, as that would cause mass confusion.

Are you essentially saying that I should map an ID to each animation, then just do something like call animation.Play(ID)?

Essentially yes. In detail it may look like so:

Things like "walking", "running", "holding weapon", etc. belong to the behavior state of the character. The player controller (in case of PC) or AI (in case of NPC) decides to eventually change the state, considering the current state, situation, and demands. Here may e.g. "want to jump" (demand) be suppressed due to "currently in air" (state). As can be seen, part of the state can be driven by external sub-systems like collision or even the animation system (e.g. an animation track that is bound to a state variable).

For animation playback then look at the current behavior state and map it to one of the animation clips. If it is the same clip as before then continue it, otherwise blend / switch to the new one. However, the playback stores which clip is played and where the playhead currently is. This means that a specific animation frame in a specific clip is picked. Its descriptive data (the "data driven approach" already mentioned in above posts) is used to determine the image frame and belonging offset (from virtual origin to frame origin) and size. These things are set into corresponding slots of the game object. Because the animation frames can be understood as keyframes on a timeline, the variable values associated with the frames can be understood as animation value tracks. Notice please that the playback essentially copies values from the tracks into bound slots, not necessarily knowing for what exact purpose.

Later then the renderer looks at the corresponding slots for the offset, size and frame, and performs rendering of exactly this one set-up.

In the above solution the sub-systems player control / AI, animation, and rendering are not aware of each other. They communicate indirectly by reading and writing a couple of common variables.

 

EDIT: renman29, I think you pretty much understand what my problem is! My animation class itself is rather cohesive and takes
care of all the animation stuff, but it's the actual logic telling the animations WHEN to switch I'm having problems with. It
actually works fine and doesn't glitch for me, but it's a right tangled mess of nested ifs!

Can't you put that into the animation object too?
It is supposed to know everything of a single animation, not only startup, but also switch to another animation.


I have also been pondering whether a state machine for the character state and/or animation state would be useful.
It would allow you to express what options to switch exist (by transitions between states). Since states and animations are probably tightly coupled, you could also code switching between animations in a state transition.

I'm still kinda in that twisted nest of if-then boat myself. It works but it becomes quite complex with all the conditions that can exist.

The tricky thing is getting it to decide what portions of animations to select under a wide variety of conditions that will result in legal smooth motion with so many possible outcomes that don't make sense in some situations -- and still make the character reactions look quick, responsive, and animate fluidly.

For example - a tiny sample:

case HEROSTATE.blablabla:

......

...

if (((isJumping == false) && (slow_fall)) || (inWater && previous_jump_pressed == false)) //if not already jumping and didn't just press jump in previous loop:
{
doubleJumping = false;
if (jump_pressed) // more logic elsewhere
{
int jump_type = 0; // 0 is normal, 1 is duck roll,...

if (duck_initialized)
{ //if in duck mode:
if ((!left_down) && (!right_down)) { animationPlayer.PlayAnimation(jumpUpAnimation); animationPlayer.frameIndex = 2; ducking = false; duck_initialized = false; customAnimator.animation = null; isGrounded = false; }
if ((!rolling) || ((Math.Abs(velocity.X) < 2)))
{
if (left_down)
{
if (facing == FACE_LEFT) { animationPlayer.PlayAnimation(rollForwardAnimation); velocity.X = max_speed.X * -2; }
if (facing == FACE_RIGHT) { animationPlayer.PlayAnimationBackward(rollForwardAnimation); velocity.X = max_speed.X * -2; }
rolling = true;
jump_type = 1;
}
if (right_down)
{
if (facing == FACE_RIGHT) { animationPlayer.PlayAnimation(rollForwardAnimation); velocity.X = max_speed.X * 2; }
if (facing == FACE_LEFT) { animationPlayer.PlayAnimationBackward(rollForwardAnimation); velocity.X = max_speed.X * 2; }
rolling = true;
jump_type = 1;
}
}
else jump_type = 1;
}
if (jump_type == 0)
{
velocity.Y = -jumpPower;
isJumping = true;
if ((inWater) && ((animationPlayer.animation == jumpForwardAnimation) || (animationPlayer.animation == jumpUpAnimation))) animationPlayer.frameIndex = 0;
}
}
}
else if (isJumping)
{

....

... etc..

So I map the possible behaviors and conditions on paper first and use that to figure out how to build conditions.

ie: flip-roll from ledge -- relying on falling state and playing fall animation would be faulty.

Based on suggestions I'm thinking maybe it's possible to set legal animation bridges between frames in other ways which again I'm thinking may still require conditional inputs such as velocity, water-interaction state, grounded-state, jump-state, crouch-state(ie: just starting, far enough into, just ending), knowledge of surrounding objects and Booleans set to qualify legality of certain transitions. Right now I actually have it choose frame transitions differently depending on what's happening as it enters another animation to satisfy what the player wants to do.

Any inherent complexity to a problem cannot be removed. What we used to do is to partition a complex problem into couple of less complex problems that are interconnected. When I look at the code in the above post I see that decision making, state control, animation playback as well as transitions all is handled at the same place. Moreover, the approach is less data driven then it can be. Don't get me wrong: There is no silver bullet that makes this kind of thing a breeze; one ever will have to run a bunch of condition checks in the one or other form as long as complex situation handling is wanted. And of course we want to please the players, don't we?

a) In this code snippet

 if (left_down)
 {
    if (facing == FACE_LEFT) { animationPlayer.PlayAnimation(rollForwardAnimation); velocity.X = max_speed.X * -2; }
    if (facing == FACE_RIGHT) { animationPlayer.PlayAnimationBackward(rollForwardAnimation); velocity.X = max_speed.X * -2; }
    rolling = true;
    jump_type = 1;
 }

because "rolling" is set regardless of the value of "facing", I assume that "FACE_LEFT" and "FACE_RIGHT" are the only both possible values. Even if not, the hint I want to give is valid anyway. Well, the inner distinction is made purely to be able to invoke a forward playback or else a reverse playback (the other stuff in the statement block is identical). Now having a 3rd variant of API invocation like

void AnimationPlayer::play( AnimationID selection, bool reverse )

would unify both cases by introducing an additional variable (data instead of code), so that an invocation like

 if (left_down)
 {
    animationPlayer.play(rollForwardAnimation, facing == FACE_RIGHT);
    velocity.X = max_speed.X * -2;
    rolling = true;
    jump_type = 1;
 }

would be sufficient.

b) Another issue with the above example is that the code implements a behavior (oh, we want to roll forward / backward) and knowledge about the animation details (oh, we do not have an animation for backward rolling, so we need to playback forward rolling but in reverse order). Why isn't there a definition for a rollBackwardAnimation clip, where the details of what frames and playback direction are hidden in the definition of the animation clip?

 if (left_down)
 {
    animationPlayer.play(facing == FACE_LEFT ? rollForwardAnimation : rollBackwardAnimation);
    velocity.X = max_speed.X * -2;
    rolling = true;
    jump_type = 1;
 }

.

c) Now, how often is AnimationPlayer::play(…) invoked in a single run through the if-then hell? If it is more than once then obviously some wasting happens. IMHO, however, even 1 invocation is too much, with a similar reasoning as above: Decoupling. If possible the controller should not know about the animation system. From a logical point of view the animation happens later in the game loop when all controlling has been done already.

 if (left_down)
 {
    movement = facing == FACE_LEFT ? rollForwardAnimation : rollBackwardAnimation;
    velocity.X = max_speed.X * -2;
    rolling = true;
    jump_type = 1;
 }

.

d) There is some redundancy in the data here. We have "facing" with 2 possible states, "movement" with 3 possible states (including neither forward nor backward rolling), and velocity.X with 2 possible states (if reduced to be either less than 0 or to the left, greater than 0 or to the right, or equal to 0). Oh, and also "rolling". I do not know all the nitty-gritty of the implementation, but from what can be seen it seems me that

 if (left_down)
 {
    movement = rolling;
    velocity.X = max_speed.X * -2;
    jump_type = 1;
 }

would be sufficient here.

e) Often abstracting the "physical" input is also beneficial. For example, the "left_down" and "right_down" variables smells like physical input for me. If this would be converted in advance into something along

bool actionRequested = left_down || right_down;
int direction = left_down ? -1 : right_down ? +1 : 0;

then the example would come down to

 if (actionRequested)
 {
    movement = rolling;
    velocity.X = max_speed.X * 2 * direction;
    jump_type = 1;
 }

and would already include the original if(right_down) branch.

Of course, now the animation control has to look at the kind of movement and the velocity to be able to pick the correct animation clip. But notice that this stuff is moved out of the character control code, and hence we've followed the problem partitioning principle: We've divided up the complexity, one part is handled in the player control code and the other in the animation control code. Each one has noticeably less complexity than the overall problem.

The above example may not work well as substitute in your exact real project, but it should just show a way of how to approach such a problem in principle. Hopefully it helps :)

haegarr: that's brilliant and quite helpful. :)

Hello again,

Thank you for the code fragment renman29, it was very enlightning. I didn't realize it was taken to this kind of detail.

I believe state machines can be useful here, and I started to write a reply, but it somewhat exploded in length, and I wasn't even close to the end.

So instead I wrote it all down in a html file. It's not entirely finished, but please take a look, and let me know what you think.

[attachment=28604:state_machines_animation.zip]

I'd just like to say thanks again for all the swift and very helpful replies. I certainly have a lot to work with here!

In regards to everything that's been said, I've already implemented a few of these concepts. I like to keep my sections

separate depending on what they do. For example, I handle all the input, whether that's from a controller, mouse, keyboard, or

AI command, then convert that into some kind of intent.

The intent can then be worked with once, so everything down the line doesn't have to keep checking for different types of input!

This intent can then drive the states of my entities, so, for example, say it has an enum for its different states (walking, still, jumping, attacking1,

attacking2, etc), the methods called after these checks don't have to check against 10-20 different variables, and instead just

check if the entity's state is a certain way.

For example, if I have 10 separate lines of code that need to know if I'm standing, it's better to have:

if (this, that, something else, another thing, some variables doing stuff, this is on, etc)

{

currentState == PhysicalStates.Standing;

}

//Then further down the code

if (currentState == PhysicalStates.Standing)

{

//Do something hilarious

}

Since every check to see if I'm standing only has to check the PhysicalStates enum. So in that respect, my code is data-driven

to some extent. I also separate the animation completely into its own method, so that the movement, collisions, etc, don't have bits

of animation code wedged in. I originally did that, and it was a nightmare to maintain the animation, especially when adding new

animations in that I hadn't previously accounted for. I'd have to change the code massively to account for a single line.

Using this approach, I then have a ChangeAnimation() method in each entity (abstractly inherited) which separately checks if

the animation should change after all the logic nitty gritty code has been executed.

I hope this helps anyone who's having trouble with animation themselves.

I have to say that Alberth's state machines write-up is immensely helpful! I think that implementing two state machines (one for logical states

and another for animation states) is the best way for me to go. As I previously said, my code worked, but it was a messy jumble of if nests.

It's a relief to know that there's no "simple" solution to this problem. But if I implement the state machine concept, I'm pretty sure there's no way

the animations could go wrong.

I'm also going to change my animation class to simply have preset animations. At the moment, it's more like:

if (currentState == PhysicalStates.Dying)

{

animation.startPosX = 2;

animation.startPosY = 3;

animation.playSpeed = 5;

animation.replay = false;

}

After looking into this, it seems a much more maintainable approach would be to link these variable changes to their own

state, so a newer version could simply be:

if (currentState == PhysicalStates.Dying)

{

animation.Play("death");

}

The "death" animation would then essentially play an animation which was already defined as:

animation.startPosX = 2;

animation.startPosY = 3;

animation.playSpeed = 5;

animation.replay = false;

That's about my take on it anyway! Does this seem like the practical way to go about it? I want to make sure

I fully understand where people are going with this :)

Yep, state machines are a serious tool in the box. But they also bring own problems. One big thing is that they tend to become unmanageable quickly due to state count explosion. That has led to mixed forms (e.g. the state is partly external to state nodes) and variants like the hierarchical state machines.

The "death" animation would then essentially play an animation which was already defined as:

animation.startPosX = 2;
animation.startPosY = 3;
animation.playSpeed = 5;
animation.replay = false;

That's about my take on it anyway! Does this seem like the practical way to go about it? I want to make sure
I fully understand where people are going with this

I'm not totally sure about the meaning of the shown lines of code. A neat thing about data driven design is that code need not necessarily be touched when changing things. Part of it is to load control data with the resources. E.g. if a sprite sheet is loaded then not only its texture but also its frame description table is loaded. If the sprite sheet is used as a flipbook animation, then also the sequence of frames and their basic timing should be loaded with the animation clip.

However, if you have an explicit initialization phase where the control data are written once because of the lack of a full resource loading system, then IMHO its fine so far, too.

You already have a state explosion, it just doesn't look like a state machine, but takes the form of nested if/else branches and assignments, where you handle input, game character state, and animation state all at the same time.

The trick to avoid that, is to have more than one state machine (one for the game character, and one for the animations). That way you can think and define each aspect separately. The computer will then merge the states in runtime, where you don't care about the number of possible combinations, as there is always only exactly one combination active.

Alternatively, you merge the state machines off-line, but you typically need a code generator for that, and indeed you get the combinatorial explosion back, but it's likely not so big here, as game character states and animation states are tightly coupled. Also, if you generate it, it doesn't matter much as long as it fits in memory and the compiler can process it.

Edit: White space fix

The "death" animation would then essentially play an animation which was already defined as:

animation.startPosX = 2;
animation.startPosY = 3;
animation.playSpeed = 5;
animation.replay = false;

In more conceptual terms, these values should not be defined in the source code. You need to use external data to define your animations, something like json (which has many parsers and is easy to work with and not overly-verbose like XML). Then, you'd define your animations like this:

{"animations":[{"name":"death", "spritesheet":"death.png", "startPosX":2, "startPosY":3, "playSpeed":5, "replay":false}, 
                       {"name":"walking", "spritesheet":"walking.png", "startPosX":1, ...} ...]
}

Obviously, it can be more than that, but doing it that way you don't have to re-compile every time. Then, in your animations constructor (or Init, whatever), you can load all the animations and define them using the animation json file(s).

(Oh, I see Haegarr said this, but I wanted to give an example).

Good luck!

How exactly would you guys recommend going about attaching an animation to a key word? My animation

class contains all the information it needs for different animation strips. But say I made a method that takes a string:

//In animation class

public void SetAnimation(string inString)

{

//Attach this string to a particular animation strip when initializing

//Would only be called once

}

public void Play(string inString)

{

//Play pre-defined animation strip linked to the string

}

What would you guys recommend to link the string to all the variables required for a whole animation: eg. startPosX, startPosY, frames, playSpeed, etc

Don't use strings, use animation objects. It looks like you're programming in Java, maybe an enumeration is best:

public class AnimationData {
    boolean loaded = false; // Set to true if loaded.
    
    public int  startPosX;
    public int startPosY;
    public int playSpeed;
    public boolean replay;
    
    public static enum Animations {
        FOO,
        BAR;
        
        private Animations() {
        }
        
        public final AnimationData animData = new AnimationData();
    }
}

You can reference the animation by the enum value FOO or BAR

The enum value has a 'animData' field contain all stuff you have for the animation.

public void play(Animation a) { play(a.animData); }
public void play(AnimationData a) {
  // use the data
}

play(FOO);

Edit: Added a second play method

I'm going to try this new approach! Should hopefully have quite a bit of free time this weekend, so I can put it to use.

I've started redoing a load of my code to be more data-driven and I've also started working on a state-managing system.

Will keep you updated with the latest. Thanks again for the help :D

If all the animations are quite simple, I would make such arrays like SpritesheetX[animation][frame] and SpritesheetY[animation][frame], then init all them and go through each frame.

(So you can make them loop, non-loop, or like any short enough algorithm (This makes sense when the same sheet is used differently, that is quite common situation I guess))

This doesn't work well for slow animations though just like that.

For a case of slow animations I would make some counter that calls PerformSlowAnimation every, let's say, 10 ticks.

If the game is simple enough (in terms of animations), it might not matter if all animations are synchronized or not (they will be if you do so), and you can divide all animations onto fast, slow, very slow, etc.

If animation has very different frame rate during its life, you can always do a special method for this case. If there aren't much objects with "unstable" animations, you can design its behavior as just an additional functionality, so it doesn't have to work as fast as main method (so you can make if statements for that, switches, virtual calls or calls by pointers, whatever).

(Just want to add) There are occasions when a string matching is (initially) useful - such as external animation editor which may have some unknown # of named animations and behavior definitions which the code knows how to use. You can pre-cache (store ahead of time) a match to a logic(if then conditions) determined animation. If you want to keep the string format, you can use an unordered map or dictionary (hash tables - very fast) to match the name/description with the desired animation. For animations that will switch frequently though you may want to have it store the matches ahead of time (micro-optimization) to the appropriate enums.

Good luck on your mission. :)