There is a programming concept known as the Single Responsibility Principle which states that every class or function should have responsibility over a single part of the functionality of the overall application. This is extremely helpful for developing complex systems in a way that is easy to maintain as the application grows, yet Animator Controllers do not support that concept. Instead, these God Objects are responsible for all the animations a character can perform, which makes it very hard to tell how things interact with each other:

• Looking at a script won't tell you which Animator Controller it's supposed to interact with.
• Looking at an Animator Controller won't tell you which scripts it's supposed to interact with.
• You can't see which parts of an Animator Controller are used by a script without reading the whole thing.
• You can't see which transitions use a particular parameter by looking at it (or even tell if the parameter is still used).

Not being able to easily understand how things are supposed to work together means you can't easily modify, expand, or debug your systems.

The Animator Controller in Unity's 3D Game Kit has one parameter called AirborneVerticalSpeed and another called VerticalSpeed. Looking through the whole Animator Controller reveals that the first one is used in a Blend Tree and the second appears to be unused, but the only way to make sure would be to remove it and hope that you can actually spot whatever it breaks (if anything).

Animancer minimises those problems by giving you the freedom to define individual aspects of a character wherever they make the most sense. A script with a Jump Animation field in the Inspector obviously needs a jump animation, or if it doesn't have a jump script then the character can't jump and doesn't need that animation. If there is a problem with the way the character jumps, that script is the most likely culprit. This flexibility opens up many possibilities:

• The Directional Sprites examples use Directional Animation Sets to manage their animations in groups of up/right/down/left (including or excluding diagonals) variations of each action instead of treating every animation separately.
• The Weapons example defines the character's movement animations in their states as usual, but manages all of the animations for drawing and attacking with a weapon as part of each weapon prefab.
• The Hybrid Character example manages the character's main animations with an Animator Controller, but keeps the animations for a mini game entirely separate from it.

Teamwork

Since the responsibilities of Animator Controllers are so broad, the team members responsible for working with them also inevitably get mixed up. Artists need to set up the animations and tweak the transitions to look right, but the logic of the parameters and transitions need to be developed in conjunction with scripts written by programmers. This wastes a significant amount of confusion and wasted effort as changes in one area often have unintended consequences in other areas. It also makes it difficult for multiple team members to work on a character at the same time because there is no real way to merge their changes.