So basically, a problem I've had in past attempt at making games (little playing around with stuff): how to do a correct, non-sloppy way of planning the flow of animations/control?

Let's take an example: you have a character, that can walk in the 4 cardinal directions, and can attack. It's that simple. Obviously, you can only walk in one direction at the same time, and let's assume you can attack when not moving in a direction only.

How would you take upon implementing this? Don't know if I'm clear, but what'd your thinking process go like?

I always end up with a huge mess of ifs and else ifs to get the animations to represent what is actually supposed to happen after moving in a direction, ie. character after having moved up, will maintain it's upwards facing (will stay on the "up" animation); Have the facing direction when moving be consistent: if you start walking left, it gets the left animation, correct. Then you start walking upwards at the same time, or downwards, and you'd like the animation to keep @ being left. You start walking up, up animation. And as you start moving left or right after starting to move up, you maintain up animation.

See what I mean? I'll be here for clarifications on the question, sorry if confuse.

For 4 directions it'd not be that hard to do something "decently structured", but when things start adding up, it becomes so confuse!

Edit: Another thing I hadn't thought about: I was simply, upon WASD, altering the object's velocities, and handling all the animation stuff through what velocities were involved. Which leads to wrong things I had thought about, such as if I get pushed, it'd walk left stupidly instead of backing off facing the direction it had.

Another edit: What I want is an answer of the sort: "First, for movement, you'd have a look at all the possible directions, and have an int or such indicating what's the current direction. Do a big switch, and inside of each direction, you'd have ifs for further x and y, but not z, because that's gonna be englobed in whatever. Then you should also have another control layer directly on the input handling to help filter unwanted actions or combinations, such as, you don't want to press A and D and have the velocities cancel each other out. For such, you'd have some further "status" for the object..." something of this kind! Thanks!


The way I would do it would be to have my character object have it's own render method, and a member variable to hold direction data. You could make an enum to define the different possible states if you wanted to. Then within the render method, check what state the direction is in (possibly using a switch/case) and render the corresponding sprite.

Wherever you handle your input, have that method update the character object's direction. This way your main code remains readable and uncluttered, but if necessary, you can delve into the character object's implementation if you need to know exactly how things are done.

Unfortunately, I can't think of a better way to do this other than using if-statements to set specific states based on specific inputs. But maybe someone more clever than me can come up with a better way.

EDIT: Ah, I slightly misunderstood your problem. If you want to keep the original sprite state when pushing two direction inputs at the same time, I would just check to see whether the direction state was already set to a "moving" value wherever you check your input. If it's already set to something, then don't set the new one.

  • \$\begingroup\$ That's not quite what I wanted. Wanted something more geared to the "how should you think in order to do it in a more correct way", but regardless: what I do is I have every object be ran through getDrawFrame() which returns the clipped texture to be drawn. I only change the logic to get the correct frame to be drawn. But that's beside the point. Your answer wasn't very straight to what I need, but thanks for the input! \$\endgroup\$ – GigaBass May 22 '13 at 20:49

For every animation have a name for it like "left" or "up" and a sprite sheet associated with it and all its rects for the images. Then keep a variable of the state like the number 0 for attacking and the numbers 1 through 4 for the directions and also keep a variable with the frame the animation is on.

Then just render the next sprite from the current animations sprite sheet and change the frame number.If a player pressed the left key change animation to 'left' for example.

  • \$\begingroup\$ That much I already have done long ago, that's very simplistic! \$\endgroup\$ – GigaBass May 31 '13 at 7:27
  • \$\begingroup\$ @GigaBass isn't this what you wanted: a simplistic, easy to implement animation system - there you go! \$\endgroup\$ – alexpinho98 May 31 '13 at 12:45
  • \$\begingroup\$ I think my main post's "Another edit" explains it well with the example \$\endgroup\$ – GigaBass May 31 '13 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.