I'd like to use skeletal animations in my 2D game, and since I already use Box2D as the physics engine, I'd like to enable (but not enforce) ragdoll animations as well. I need some help in figuring out how the Animation and Physics entity components relate to each other.

How should data be represented on disk? Should the actual model/ skeleton be different from the animation? Here's what I currently have in mind: each texture has a corresponding Box2D body (forearm.jpg and forearm.body, for example). I also have a separate hero.model file that references the *.body files, and several *.anim files that reference the model and the textures.

The reason I don't think I should reference the textures in the model directly, but reference them in the animation, is so I can have the character blink (for example): its head would be one body, but different sprites can be pasted over it at different keyframes as to make it blink.

Should I actually move the limbs while animating? While the character is still alive (and ragdoll should be off), what should I do with the physical limbs? When I animate, should I just render the sprites with the correct transform, or should I actually move the physical limbs to their current position according to the animation? If yes, how can I get over the fact that Box2D doesn't handle moving bodies directly too well?

How to enable more complex communication? Architecturally speaking, how should I implement communication between the Animation and Physics components so that interaction is kept to a minimum, but to also be able to do create more complex entities, like for example a wheel on a robot being rendered with the rotation of the physical wheel, while the rest of the robot is rendered according to the animation's keyframes.

  • \$\begingroup\$ The answer is already in your question, activate the ragdoll-physics stuff when the pawn is dying and deactivate the animation at the same time. \$\endgroup\$ Dec 29, 2011 at 11:46

1 Answer 1


You should do as Maik said.

Often it happens that skeletal animation is quite decoupled by the skeletal it moves: you may find that the limbs of a qadrupede move rougly in the same way if it paces, be it a dog or an horse. This means that you may find it useful to move the skeletal animation responsibility to an external entity by connecting the "animator" with the "puppet" when needed.

This strategy let you to "recycle" animator instances (insofar as possible), combine them to be behavioural (say inverse_leg_walk + atrophied_arms_walk for a TRex vs leg_walk + arms_walk for a man) and so forth.

As you can seamlessly switch between walk and run or jump, you may switch to ragdoll animation and detach your animator when the ragdoll stops (if you are looking to free resources as fast as possible)

  • \$\begingroup\$ Thank you for the answer. I wasn't exactly clear in my previous question, so I rewrote it. Could you please take another look at it? \$\endgroup\$
    – Paul Manta
    Jan 7, 2012 at 9:05

You must log in to answer this question.

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