Hello, I am beginning work on my fourth game but the first that will use animation. I've thought over some different methods but none of them seem clean or easy to manage. Is this just the way animation is going to be or is there something I'm missing? Angles I've considered:

• Hardcode everything. Changing things will be a pain, testing tweaks means recompilation (not a big deal, but hey), have to recode everything for each class. It will work though.
• Write some "config" files which would detail all the frames and frame durations of an animation. Better, but I'm not sure how to work out caching the texture data and I certainly can't reload a texture every time I switch images.
• A class devoted to animations - but how would that work? Seems like it would be too "vague" or have to be hardcoded.

I tried searching for information on this topic; all I found on gamedev was posts about 3d skeleton animation, and on Google I got animation creation and images. Thanks!

Quote:Original post by wendigo23
Are you doing 2d or 3d? It is not obvious from your post...

Yikes, you're right. Two dimensional.

Dunno if people will think this is over the top but in my current 2D game I read strings from the level data file that are expressed in a sort of "mini-animation language" (forgive me if that is pretentious) of the form

"[1,2]:[2,3][4,9]<" etc in [frame,duration] pairs. '<' means loop back to ':'.

This is then "compiled" before the game starts into a tiny little "virtual engine" based on a couple of instructions with data in an int array. This has a int Tick(); method that returns the next frame each time it is called.

Rationale is that I have the convenience of a scripted format for animations so they can be changed easily without the any real run-time overhead.

Quote:Original post by Frequency
Hello,
I am beginning work on my fourth game but the first that will use animation. I've thought over some different methods but none of them seem clean or easy to manage. Is this just the way animation is going to be or is there something I'm missing?

Angles I've considered:

• Hardcode everything. Changing things will be a pain, testing tweaks means recompilation (not a big deal, but hey), have to recode everything for each class. It will work though.


• Write some "config" files which would detail all the frames and frame durations of an animation. Better, but I'm not sure how to work out caching the texture data and I certainly can't reload a texture every time I switch images.


• A class devoted to animations - but how would that work? Seems like it would be too "vague" or have to be hardcoded.

I tried searching for information on this topic; all I found on gamedev was posts about 3d skeleton animation, and on Google I got animation creation and images.
Thanks!

I started using XML for my game's config files, using the TinyXML library (http://www.grinninglizard.com/tinyxml/). Its documentation takes some perusing, but once you get the gist of it, it's very nice to be able to use this config file format for anything. I would recommend it for your situation.

As for the functionality itself, at start-time, you'd read in a set of animations into a list of "animation descriptor" classes (for lack of a better term) from a config file (regardless of format). Each one basically is just a recording of frames involved in an animation, and each instance maintains current-frame and timing information.

Thanks for all the tips, guys, these may be integrated into the current design...I think I hit on a reasonable solution while I was a-thinking last night: An "Animator" class that each entity that will be animated will have an instance of. An animation can be called with something like MyAnimator.StartAnimation("MyAniScript.ans"). This will load all the textures and frame lengths and maybe offsets into a container: before an image is loaded from the animation script though, the Animator instance will check a static std::map of all image names that have already been loaded (key) to a texture id (data). If an image has already been loaded, instead of converting it to a texture every time an animation is run which'd be ridiculously expensive, images will be cached and reused next time that image's name is encountered. Though I haven't yet worked out exactly how textures will be deleted besides clearing them all when I'm done with everything or an Animator->delete("thisScript") call...

So then I'll be able to call Animator->Update(deltaTime) which will add to the current running time and select the next frame if need be, and Animator->GetCurrentTexture() to access the current frame's image. Or that's the general idea anyway. I haven't implemented it yet so I'm sure I'll find plenty of surprises, but if it's a good idea let me know so it'll be on the front page for use by others, or if it's a bad idea, scold me so I'll fix it. :)

I haven't thought about the format of the animation descriptor files yet - something as simple as "imagename"|length|xOffset|yOffset might be fine, but I'll consider XML if it gets more complex, or for different config stuff.

Thanks for all the help everyone!