Bad design.

Mecanim is broken and needs to be fixed properly

Generally speaking, Unity has a coherent design philosophy that provides a nice workflow. Essentially you make GameObjects in the Editor, then when you hit play it makes a working copy of the object. Any changes that are made to that object during runtime are not reflected on the original. Your scene is preserved, your prefabs are preserved, yet your game play objective is met.

There are a couple of notable exceptions to this rule that I have encountered.

Navigation meshes. You can only generate these in the editor, and have very limited access to them with scripts. This is a bad design choice, and should be fixed.

However, to work around this I just use the RAIN NavMesh implementation (free on the asset store!), which has been done properly. It provides you with the editor tools to generate NavMeshes in the editor, but it also gives you complete access to the NavMesh library at runtime. It’s also faster. It’s just plain better than the built in Unity NavMesh solution in every way I can think of. Because RAIN exists the Unity NavMesh implementation doesn’t bother me so much… but it’s still wrong.

Bad design.
Bad design.

The other one is the one that really grinds my gears. The Mecanim animator. Their implementation makes no sense. It’s billed as a major feature of Unity’s engine, but it’s underpinned by a simply bad design choice. To make things worse, despite being aware of the issue, the response from Unity has been to patch it with dodgy hacks and work-arounds, rather than solving the actual problem in a way that empowers developers to do their job.

Bad design.
Bad design.

Mecanim Animator

At some point during design someone decided that the Animator component itself would not be cloned off to a working copy like normal Unity GameObjects. Rather, just the animation parameters and the current state of the machine would be individual.

Bad design.
Bad design.

Consequently any changes made to the animator are permanently saved. As such, if someone was to use a script to fiddle with their animation state machine it would have unintended permanent consequences.

To prevent this, virtually none of the animator data structure is exposed to scripts. You cannot access States, Transitions, BlendTrees, Clips… you know, everything useful.

Bad design.
Bad design.

This has serious consequences. Consider the situation where I have several attack animations, but my character has various attack speeds depending on which particular weapon they’re using, such as in Borderlands or Diablo. The attack animations need to be played back with an animation speed such that the animation play length matches the attack speed.

For example, WeaponA has attack speed of 1.5 attacks per second. The attack animation that applies to that weapon has an original length of 3 seconds. To make that 3 second long clip play in 1.5 seconds, I need to make sure that the speed of that clip is set to 3/1.5=2. To do this I need access to both the length of the clip, and the speed parameter of the motion in the attack animation state. Unity currently gives me access to neither.

How should this work? The same way almost everything else in Unity works. The actual animator component that is on a given character should be a working runtime clone of the original, and any changes to it in script should be reflected immediately in game play, but not saved permanently. This way I can change whatever the hell I please in runtime scripts, without any permanent ramifications. They could expose everything.

Unity acknowledge that this problem exists – so in the 5.1 release they have a solution whereby you can drive the speed variable with an animation parameter, just tick a checkbox! Hurrah?

No. This is a hack solution to a problem that shouldn’t exist.

Bad design.
Bad design. On a side note, disastrous public bathrooms are 90% of what you get in a Google image search for “bad design”.

Fix it properly. This solution will only fix a very small subset of the problems that you should be able to solve through manipulation of the animation state machine at runtime. Give us tools that allow us to do whatever we please with our game while it is running.

I appreciate that there can be a certain level of “protect the user from themselves”, and that there are sometimes limitations or efficiencies that we might not fully understand. But in this instance, it really does appear that it’s just a bad design choice that needs to be fixed. Properly. I don’t believe for a second that cloning the animation state machine for each animated character would have disastrous performance implications. Games in other engines have been doing it for years without issue.

What do you think? Do Unity need to address this obvious issue? Am I way off on this one? Is there some missing piece of information I don’t have that would make this all make sense?

3 thoughts on “Mecanim is broken and needs to be fixed properly”

  1. I agree with you completely on Mecanim. We’re trying to do lots at runtime since we’re adding a very extensive modding system in. Due to this, we want so much more control over Mecanim than it provides at runtime.

    Editor time Mecanim is useless to us and this is causing real problems.

    1. Exactly. We don’t need Unity to decide what we should and shouldn’t access at runtime. We are more than capable of making those decisions for ourselves.

      I wonder sometimes if some of the devs at Unity have a skewed perception of the kinds of users they have. On Unity Answers and the forums there’s a lot of posts from kids and students that demonstrate a clear lack of understanding/fundamental programming skills. But the people who use and depend upon Unity in their day to day operations are professionals, and need to be treated as such.

Leave a Reply