Saturday, April 20, 2013

Understanding Mecanim

One of the more promoted features of Unity 4 is Mecanim, a visual interface for building animation state machines.  It's a very powerful tool that has benefited the production of my game, but the initial learning curve can be kind of steep.

Through working with the tool, I've developed a handful of tricks and best practices that have greatly improved my workflow.  In this blog post, I'll share a few tips.  However, this post will assume that you have a basic understanding of Unity's interface and how to set up your state machine.


A few months ago I dug into Mecanim for the first time.  Naturally, I had no clue what I was doing, and thus I created this mess of a spaghetti web...

This is a very BAD way to get the job done, but at the time it was decent enough.  However, this state machine uses the bare minimum of animations that we were planning, and adding anymore here would have just made the whole thing even more confusing.

Thus, before creating the second iteration of the state machine, I did some sleuthing to see how one is actually supposed to use Mecanim.  A personal revelation was the discovery of Sub-State Machines, which basically allowed me to chunk the overall machine into several miniature chunks.

As you can see, my second attempt ended up being much cleaner.  Each of the blue nodes contain a smaller sub-state machine, which makes following the transitions from one animation to another much easier to read (at least for me).  For example, upon double-clicking on the "Jump" node...'ll see a relatively simple state machine that determines what happens when the player jumps or falls off a ledge.  However, I still had a few problems with this iteration.  While it was much more extensible than my first attempt, I still found it rather inefficient.

Because my game is a side-scrolling platformer, the player must ALWAYS play a jump animation when jumping.  Therefore, every time I added a new animation node, I had to remember to hook it up to both jumping animations...which got rather tedious.

Up until this point, I've refrained from using the "Any State" node, as I didn't quite understand how to use it properly.  Because a transition an "Any State" can occur from literally any state, I didn't know how to prevent Mecanim from repeatedly calling an animation over and over again.

In the above .GIF is depicting the player's death animation being initiated.  It never has a chance to resolve itself because the state machine is set up to transition to the death animation from any other animation.  In other words, the death animation is transitioning into itself repeatedly.

The solution?  Use LateUpdate to turn the parameter off.  The LateUpdate function is called after every object has completed completed its update for a frame, which means that the parameter will be guaranteed to turn off after the Animator Controller has transitioned to the death animation.

By learning that, I've polished up the state machine again, and it's finally starting to come together.  However, it still could use some more polish...

Until then, thanks for reading!