I'm implementing a platformer in C++ using SFML and a port of Artemis. Right now, I'm currently working on a System that will animate my sprites. My understanding is that in ECS, components should only ever hold raw data (no resizable containers, objects, etc), but the best way I can conceptualize an AnimationSystem would be that every Entity that needs to be animated will have an Animation component, which would contain a list of Frames. Each frame would just hold data -- the x and y position within the texture, the width and height of the frame, and the relative duration of the animation.

If I implement that, the code will work just fine, but I feel like I'd have broken some golden NO-OBJECTS rule of entity design. I've implemented animations in other fashions but they don't have quite the capability --- I've not been able to put multiple animations on a single altas, or have animations where the frame width and height could change.

Has anybody had any experience with this? I'd like to get some guidance here :)

Each frame would just hold data -- the x and y position within the texture, the width and height of the frame, and the relative duration of the animation.

I'd store just an id or reference string ("running", "standing", "crawling") in the animation component and have the animation system use this information to play the right animation. This system would eigther own a list of the actual animation data you described, or share it with the higher level structure that is responsible for creating it. Does that sound possible with your design?

juliean - I believe I'll integrate the tags you've suggested into phil's solution in order to segregate different animations within a single atlas. thanks!
phil_t - I think that is the solution I am looking for. I've just started reading through your blog as well, it's a pretty good resource.

Use a vector to store each frame.

Generally agreed that there isn't anything against using a vector, and it is good use in some cases, I'd still say that some reference to the animation, in combination with what phil_t suggested, specially the paramters which I forget to mention. Its a matter of case, good thing you mentioned one should not stay away from vectors etc.. completely.