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.
-
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\$– doppelgreenerCommented Sep 20, 2012 at 11:27
-
\$\begingroup\$ @JonathanHobbs Yes, I want to learn how to program animations well. \$\endgroup\$– mrkCommented 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\$– doppelgreenerCommented Sep 20, 2012 at 12:00
1 Answer
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 aGame Element
- A
Game Element
is a visual element in the game-world - A
Sequence
is a collection of orderedFrames
- 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.