JOIN THE DOTS - EASY ANIMATOR CONTROLLER

"EASY ANIMATOR CONTROLLER" proposes, in a first stage, an interface to rename the set of "AnimationClips" you want to use in your "GameObjects", so that the new names encode all the essential information that the system now recognizes and stores in data structures.

In a second stage, taking advantage of this information, automate the creation of an "AnimatorController" from scratch, with as many states as "AnimationClips" renamed in the first stage, sub state machines, transitions and appropriate parameters. In this second stage new data structures are also created to store all the essential information of these states, sub state machines, transitions and parameters making available to our scripts the necessary information to choose the animation we are looking for at any time through an "interface" composed of simple auxiliary methods.

All this automation is preset through parameters exposed in a single "scriptable object" (type "AnimationsSO"), greatly facilitating the saving of the configuration "assets" and avoiding, to a large extent, touching parts of "EASY ANIMATOR CONTROLLER" that may break its functionality.

It takes little time in the world of game development to realize that one of the "elephants in the room" is the animation of your GameObjects. The system provided by Unity is called "MECANIM" and everyone who has dealt with it, has either spent a lot of time to achieve a reasonable result, or has directly thrown in the towel.

"MECANIM" is complicated mainly for two reasons:

1. "MECANIM" requires a lot of setup time in the editor to set states, associate "AnimationClips", create transitions, create parameters and link them to scripts.
2. The functionality of "MECANIM" is seriously hampered by exposing essential methods to control the flow of animations whose argument is the literal value of a string. By using literal values directly in our code, we sacrifice readability, scalability and maintainability and expose ourselves to potential bugs.

animator.PlayClip(string hopeThisNameExists)

animator.SetBool(string hopeThisNameExists)

animator.SetTrigger(string hopeThisNameExists)

animator.SetFloat(string hopeThisNameExists)

Starting with the second problem, it would be unfair to say that "MECANIM" forces me to base my animation system on the intensive use of "magic strings", a common practice, but not recommended in programming. And it would not be fair because there are alternatives, but the truth is that since no alternative is proposed to us, this is the way most developers work with "MECANIM".

Encode three levels of information into the name of the animation clips I want to use is the beginning of the solution to the aforementioned problem of the intensive use of "magic strings" at the heart of "MECANIM".

The potential of "MECANIM" after this paradigm shift is huge in aspects such as adaptability, maintainability, scalability, clarity, reliability and automation.

The information encoded in the new animation names includes three “Information Levels”:

1. Basic information level. It represents the “Main Category”.  Every “AnimationClip” must belong to one and only one main category of type MOVE, RUN, IDLE, ATTACK, CROUCH, SWIM, CLIMB, etc. “Idle” main category must exist and must be only one animation clip with this main category.
2. Additional information level of type “Directional Input” (UP, DOWN, RIGHT, LEFT, etc). If it exists, it is added to the basic information (EX. MOVE_RIGHT, MOVE_UP). If the animation clip does not have a relevant relation with a direction, it is coded as “NODIR”.
3. Additional information level of type “Position State” (JUMP, CROUCH, DASH, IDLE, WALK, etc). It is added to the basic information + additional information of type “Directional Input” (EX. ATTACK_NODIR_CROUCH, EX.-SWIM_FORWARD_WALK). We went with “Position State” but this info level usage and existence is for two main use cases and the best explanation is one example for each one. 1.- EX. ATTACK_NODIR_CROUCH case when I have attack animation clips in different flavours, normal, while jumping, while dashing and in crouch position. In these cases, I need this additional info level to trigger the right animation in every case. 2.- EX.-SWIM_FORWARD_WALK case when I will create a sub state machine for the SWIM animations so I will spend the main category with SWIM and I will need this third info level to select if I swim at normal speed SWIM_FORWARD_WALK or I swim fast SWIM_FORWARD_RUN. if the main category + input category are enough to choose the right animation, it is coded as “NOPOS”.

These 3 info levels are enough to choose the right animation in complex animation systems like the example we explain in the documentation document provided.

After giving a solution to the second problem, we have laid the groundwork to solve the first problem that we defined as "requiring a lot of setup time in the editor to set states, distribute them in substate machines if needed, associate AnimationClips, create transitions, create parameters and link them to scripts. With all the information that our scripts now have, stored in data structures, we can create new "AnimatorControllers" from scratch in an automated way based on preset parameters in "AnimationsSO" type configuration "assets" so the amount of time consumed when creating "AnimatorControllers" from scratch is reduced to the time needed to press a button.

"MECANIM is the default system provided by Unity, it is true that it is in some aspects a kind of "black box" that makes it difficult to debug in situations of failure or unexpected result, but it is a functional "finite state machine" with a multitude of configurable parameters in the editor (safe trial and error) to achieve a very high level of detail in the calibration of the animations, very difficult to achieve by giving up the system.

"Unity Mecanim Animator Controller" has, in our opinion, more lights than shadows and therefore, we are not in favor of giving it up because, although the two main problems are really important and weigh down the system, they have a solution and once solved, the potential of the system is maximized to give a solid, scalable and fast response to the animation needs of developers.

https://www.jointhedotsmapgenerator.com/easy-animator-controller