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?
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:
Sprite is the collection of Sequences that represent a
Game Element is a visual element in the game-world
Sequence is a collection of ordered
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.
Sequence has a unique combination of
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).
Animation represents an action that the sprite is doing. Examples are: Idle, Walking, and Jumping
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# 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">
<anchor x="0" y="0" />
<rectangle x="0" y="0" w="96" h="96" />
<anchor x="0" y="0" />
<rectangle x="0" y="128" w="96" h="96" />
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.