Well, the problem with that is that I’m using animation blending on the arm, and I want the enemy actor in most cases to ALWAYS be constrained to the hand. So if the enemy is defined in relation to the player root (0,0,0 in relative space) then he’s always going to remain in that position no matter what the mesh does… and that means creating separate swing/sway animations to make the enemy track the player’s hand for every possible configuration of his arm when blending anim states. I realize I probably didn’t communicate that clearly enough; if I define the enemy in relation to the player’s root, he only moves when the player’s root does, and I really want him to move far more than that, since I want the player’s animations to drive him around, though not always in a totally scripted fashion (i.e. it’s not always an exact predetermined sequence of events that’s playing out, it’s based PARTIALLY on the player’s blending when moving around).
What I ended up doing was something similar to what I was originally describing with the enemy being defined in relation to a bone and using constraints on him. It winds up working like you’re describing, except that the enemy is defined in relation to a non-zero point on the player. It admittedly DOES make animation more complicated (as the player moves the constrained hand in ways that aren’t meant to move the enemy, I have to work in some offsetting animation on the enemy’s root), but the state blending is so much smoother.
I’m pretty happy with the end result, though: Dropbox - FlipJumping.webm - Simplify your life
I do appreciate the feedback though! Even though I didn’t do it exactly, knowing that “build the animations in a space that shares the same constraints as the game will, and then export those animations individually for each skeleton” is the Right Way To Do It enabled me to move forward with this!