0
\$\begingroup\$

Say you are using C/SDL for a 2D game project. It's often the case that people use a structure to represent a frame in an animation. The struct consists of an image and how much time the frame is supposed to be visible. Is this data sufficient to represent somewhat complex animation? Is it a good idea to separate animation management code and animation data? Can somebody provide a link to animations tutorials that store animations in a file and retrieve them when needed. I read this in a book (AI game programming wisdom) but would like to see a real implementation.

\$\endgroup\$
3
  • 3
    \$\begingroup\$ This question seems too vague to answer, and you're asking two things at once. You should ask what you're trying to accomplish: do you want to know how to program animations well or something? Ask that. \$\endgroup\$ Commented Sep 20, 2012 at 11:27
  • \$\begingroup\$ @JonathanHobbs Yes, I want to learn how to program animations well. \$\endgroup\$
    – mrk
    Commented Sep 20, 2012 at 11:38
  • 1
    \$\begingroup\$ Okay. Read this section of How to ask questions the smart way Describe the goal, not the step - then say what you want to achieve and ask how you can accomplish it. :) That would be a starting point for a good answerable question. \$\endgroup\$ Commented Sep 20, 2012 at 12:00

1 Answer 1

4
\$\begingroup\$

Is this data sufficient to represent somewhat complex animation?

Yes. When you get down to it, everything on your computer is just data.

Is it a good idea to separate animation management code and animation data?

Absolutely.

Can somebody provide a link to animations tutorials that store animations in a file and retrieve them when needed.

I develop a pair of projects for animating sprites in a data-driven way. There's a sprite maker (not recommended), and a sprite library for XNA that I think works quite well. Here's a copy of some of the documentation. The high-level concept is quite portable:

  • A Sprite is the collection of Sequences that represent a Game Element
  • A Game Element is a visual element in the game-world
  • A Sequence is a collection of ordered Frames
  • A Frame is a rectangular section of an image

That is to say that menu items, HUDs, buttons, text, loading screens, all of that is not a Sprite because they do not exist in the game-world.

Also, each Sequence has a unique combination of Set, Animation, and Rotation where:

  • A Set indicates the set of the sprite to use. This can be used for a second, complete set of Sequences for the sprite. Examples are: (full health, half health, and almost dead) or (sword, vs spear).
  • An Animation represents an action that the sprite is doing. Examples are: Idle, Walking, and Jumping
  • An Orientation represents the direction the sprite is facing. Examples are: (left and right) or (0, 45, 90, 135, 180, 225, 270, and 315 degrees)

Any of the above can be left as "Default" if they aren't useful for your application. Every frame can be accessed by using a 4-dimensional array like so:

frame[set][animation][orientation][frame#]

Where the frame# indicates the progress through the sequence. When the Animation changes, the Frame counter restarts at 0. When the Set or Orientation changes, the Animation and Frame counters do not change, the current animation just continues in the new set or orientation. Each Animation indicates which Animation should follow, once completed. For a looping animation, the animation will refer to itself. For a ping-pong animation, there will be a second animation that uses the same set of frames, only in reverse. And for animations continuing on to greater things, they point elsewhere. Whenever an animation completes, either a flag will be set to indicate this, or an event will get fired to allow the game to take any required actions (like start moving after standing up).

This concept can work well for frame-based animations, but will require some more thought to be functional for skeleton animations.

My SpriteLib project consumes XML that looks something like this:

<sequence set="Axe" animation="been hit" orientation="N">
    <frame image="Vlad.png">
        <anchor x="0" y="0" />
        <rectangle x="0" y="0" w="96" h="96" />
    </frame>
    <frame image="Vlad.png">
        <anchor x="0" y="0" />
        <rectangle x="0" y="128" w="96" h="96" />
    </frame>
</sequence>

And splits the SpriteDefinition from the SpriteAnimator because you can have multiple sprite animators working off the same sprite definition.

This is just one way to think about 2D animations, but hopefully it will give you a place to start.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .