I built this animation controller as a pipeline solution for animation transfer between models in Unity. The project I was working on required four hero characters to share a majority of their animation cycles while still having several unique animations. To accomplish this one of my teammates, Tyler Niemi, created each of the required animation cycles including each attack chain on a dummy model. We used this model as a container for all the animation clips to be transferred to each hero model.
Using Mecanim offered us the benefit of separating the code for the game from the calling of animation clips which allowed us more flexibility in adding and modifying character animations. To add another animation state, I simply had to request the programmers add an additional boolean variable be broadcast to the animation controller based on the current game state. This means that the animation system could be modified at will without touching the code of the game in most cases. This helped both for production speed and for debugging purposes.
Using the legacy animation system in Unity would have required over five times the amount of animation clips that the Mecanim system required to achieve the same results.
Part of the power of Mecanim on humanoid rigs is the fact that each model only requires an avatar and an animation controller to work. The avatar is simply a container set to path to each bone in the original rig's skeleton. This means any rig can be used with any naming convention so long as there are bones to map to the avatar's required set.
Our hero models were then created and imported with only a skeleton and no animation data on it. The avatar maps the animation rotation data from the original clip to the right bone for us. Each hero model was given a ragdoll and then with scripts, the ragdoll was deactivated for play. When the character dies, the script turns the ragdoll back on and adds a force to the hips and the character goes from being an animated character to a ragdoll.
To handle all of the animation states with a single animation controller, we made use of layers in Mecanim. Because we were doing a fixed-camera, side-scrolling action game, we didn't need to use blend trees. We needed our animations to be snappy and responsive from state to state with minimal transition frames. To accomplish this, I created a layer for each category of movement. The base layer was for idle animations. As shown above the base state is a transparent state which does not contain an animation clip. The boolean parameters list controls everything as the player script reports to the controller which combination of parameters is currently true. The transparent state on each layer allows us to path to a state or back to transparent to seemingly hop to another layer. If the player script reports that the player is currently not idle, the idle layer sits in the transparent state allowing an animation from another layer to completely overwrite the animations and the idle layer waits for the script to report a character in the idle state again.
The layers contain both a left and right state for each action so that we can cheat the character pose toward the camera. The animations were created so the character opens to the camera, but if we just let the player capsule turn the character around to face the opposite direction, you will see the character's back. To alleviate this issue, we created a mirrored version of each clip on import. The mirrored clip is fed to each state that faces the given direction while the others receive the default animation data. This allowed us to manage half the number of animations for a fixed camera, allowing us to iterate faster with only one set of animation curves.
Complex actions like jumping were made much simpler through layers. We needed to handle a jump and fall animation allowing the character to change facing in the air as well as get into the jump state from every other state (i.e. idle, running, crouching, or attacking). Creating a controller with pathing from every other state gets overly complicated to visualize and to manage, but layers allowed us to simply change layers from any other layer through a boolean change effectively allowing us to path to a movement category from any state.
Mecanim also allowed us to get certain animations for free. For example, this look layer plays a looking up animation to allow feedback for the player to understand they will attack up. When the boolean report the character is no longer looking up, Mecanim's animation blend system will blend the head back into the default position, allowing us to do things like stand up from a crouch or look straight without needing to play or build an animation for it. Layers like this also make use of the avatar mask to mask the animation only to the bones needed. In this case, the characters head is the only bone that will play the animation allowing things like the attack or run animations to control the other bones of the body without the look animation blending rotation information with them. This also allows the animator to silo his animations without needing to animate the whole rig for discreet motion.
One of our characters had a tail that needed animations mapped to it. The Mecanim humanoid avatar doesn't handle anything extra on the rig, but there is a simple work around for added parts on a model. Each animation clip allows for a custom mask for the rig so that you can expose additional bones like a tail to bake animations to. Should a character without a tail find itself outside the transparent state of this layer for any reason, the animations won't make a difference because that character does not have the bones to receive the animations which is a nice fall back safety measure for this type of animation control. The tail simply has two states, one for idle and a different one for every other type of action. This system is easily extendable because you could tie a different tail animation to each action by adding another state off the transparent state with the appropriate transitions. This is a great way to grow the complexity of the animation system without causing undue pathing stress.
And finally, the attack layer contains all of the chain attacks for each character. The player controller script handles the delay for pressing the attack button again and getting the next animation in the chain through changing the boolean to the correct chain step. The controller is quick enough to path from one step back through the idle state to the next step without any performance lag, but I added a fall back transition between each state allowing the controller to path directly to the next step if needed. This allows for any variance in timing of button presses and the update of the script and prevents players from losing attacks.