Upgrading arm animations

I'm going to take some time to talk about the feature I'm currently implementing into TGE - a drastically improved (IMO) arm animation system. The stock system is amazingly simple - no horizontal motion, blended vertical motion. I want to bring this up to the standards of modern FPSs. The key feature here is torso twisting. But I also want to go far beyond that and make a more complex system than one where each weapon has its own horizontal and vertical blend animations.

The reason for this complexity is partly because I believe that it's better to have a complex system that scales well than a simple one which breaks down under tress. The standard arm animation system is an example of the latter. If you want to make an FPS of reasonable scope, then you might want to include up to ten weapons. But you might also want to include one or two melee weapons, grenades, and the ability to duel-wield any two weapons.

That last one is the kicker. Say out of ten weapons you only have three that are duel-wieldable, but each is held in a little different way. With three weapons, two melee weapons, and grenades that can all be duel-wielded interchangeably, that's a lot of animations to make. Not just that, it becomes a lot of coding work to switch between them at the right moment.

Okay, so I'm making some major assumptions and probably logical fallacies (I know of a very easy way to reduce all that coding I mentioned...). But that's the other part of why I want a complex system - my game does fit the above description, and I don't want to have to make and code multitudes of animations. Additionally, I want the game to be very moddable, both in terms of creating new weapons and new races. If someone goes and adds a new race with a bunch of new weapons, we don't want that poor guy to have to go back and create new animations for all the stock characters. It would be better to have a system working off a few very basic, more generally applicable animations that can apply to the new weapons just as well as the normal ones.

Now, into the specifics. Basically, the system breaks arm animations down into three parts.
1. A torso twist animation, blended. This may just animate one spine node, but it gives a horizontal animation range. One animation is defined for each stance if needed (stand and crouch might be the same; prone won't).
2. A pose animation, not blended. This pose puts the nodes of the upper body into a specific pose for holding weapons, and provides the vertical range of animation.
3. Arm animations, blended, which define the pose of each arm individually. They also animate vertically alongside the pose animation.
Aside from his, the head has its own horizontal and vertical blend threads.

What does all this give you? I'll describe a way this system might be used.
Say your FPS has two weapons, a rifle and a pistol. You can dual-wield two pistols, single-wield one, or single-wield the rifle. At any given time holding a weapon, you might have it at your hip or aimed. You might also be standing upright or leaning. And, your character might be right or left handed. If you were to do all these poses with standard arm threads, you'd have 24 animations to make (quote me on that, I did the maths). And you wouldn't have torso twisting.
My way, it would break down like this:
-One torso twist animation
-Four pose animations, with the torso facing or leaning to the left or right (depending on handedness)
-Twelve arm animations: holding rifle, bracing rifle, or holding pistol for each arm, aimed and not aimed
That's cut 24 animations down to 17. That's not extremely impressive (though as the amount of weapons increases, the savings increase). But there are more benefits than just the amount of animations. If I had a particularly strong character, I might want him to hold a rifle in one hand and a pistol in the other (or two rifles!). I can do this using the animations I've already made, whereas before I'd have to go and make new ones specifically for these situations. I could also hold two pistols and aim one of them.

Another highly game-specific benefit of this system is in the case of multiple-armed characters or creatures (multiple, in this case, meaning more than two :P). Take a four-armed mutant and try to apply the above example to it. Now you've hugely increased the number of standard animations needed, because each possibility for one set of arms can be applied to almost each possibility of the other set. That's a shedload of animations. But with the system I'm designing, you just need to double the number of arm animations required, to make he same poses for the second set of arms.

The idea of making an animation per arm isn't new - check out this blog for an example of the same sort of thing. I plan to go a little further, though.

What I'm talming about now is the mention I made of the head's blend animations being in addition to the torso and pose animations. This allows the head to be moved around independently of the body (and therefore weapon aim). This has two implications. First, NPCs can have more detailed interaction with the world, as they can turn their heads to look at things, or to say things (how often in movies do characters shout over their shoulders while blasting away with their guns?).
Secondly, and more importantly to me, recoil can be dealt with elegantly. Most recoil solutions simply bump the character's aim up, as if their arms are attached to their head. I plan on making the weapon's aim jump up, while the character looks straight ahead. Your aim them gets desynchronised with your crosshair, and recoil actually becomes a nuisance. When you're not firing, your arms realign themselves to the direction your head is pointing.
Last, and of lesser importance but which I think is really cool - you know in HL2 when you aim at a friendly, your weapon is put down? I plan on doing something similar, but simply by lowering the character's aim while keeping their head level.

Now, the purpose of this blog - any questions? I plan on releasing this as a resource, so I want to know how I can make it as good as possible. I also want to hear everyone's scathing criticisms - why complexity isn't worth it, why this will never work, why it's too costly an addition to the already-bloated Player class (well, at least by virtue of it being an extension of ShapeBase...).

And since no blog is complete without glorious technicolour: