MOTIVATION
![](https://primary.jwwb.nl/public/n/s/j/temp-yknyrogrkmjpszapxqcm/eaclogo-high-5qy1k5.png?enable-io=true&enable=upscale&crop=1700%2C1912%2Cx0%2Cy0%2Csafe&width=711&height=800)
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:
- "MECANIM" requires a lot of setup time in the editor to set states, associate "AnimationClips", create transitions, create parameters and link them to scripts.
- 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".
When artists create animations and give them a name, there are some that use more intuitive nomenclatures and others that are more chaotic or messy, but in all those names lies a great potential if we analyze them and decipher the keywords they use in the names they apply since the purpose of all of them is to describe what each animation in question does.
This potential is the beginning of the solution to the aforementioned problem of the intensive use of "magic strings" at the heart of "MECANIM". "EASY ANIMATOR CONTROLLER" automates the process of renaming the animations we want to use in our projects by allowing us to replace "magic strings" with new strings already encoded (they encode the essential information needed to categorize the animations and be able to choose the right one at any time) and stored in data structures within our scripts, improving the quality of our code.
The potential of "MECANIM" after this paradigm shift is huge in aspects such as adaptability, maintainability, scalability, clarity, reliability and automation potential. The information encoded in the new animation names includes three “Information Levels”:
- 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, etc.
- Additional information level of type “Directional Input” (UP, DOWN, RIGHT, LEFT). If it exists, it is added to the basic information (EX. MOVE_RIGHT, MOVE_UP), if it does not fit into any category, it is coded as “NODIR”.
- Additional information level of type “Position State” (IN-AIR, CROUCHING, DASHING, SWIMMING, CLIMBING, etc). It is added to the basic information + additional information of type “Directional Input” (EX. MOVE_RIGHT_SWIMMING, MOVE_SIDE_CROUCHING), if it does not fit in any category, it is coded as “NOPOS”.
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, 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" in an automated way based on preset parameters in "AnimationsSO" type configuration "assets" so the amount of time consumed when creating "AnimatorControllers" 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 environment) 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.
We will show and explain in video tutorials, the process of implementing the system in individual projects using different packs of models and animations created by different artists. Only by seeing it in action, you can understand how much time can be saved with “EASY ANIMATOR CONTROLLER”.
Crea tu propia página web con Webador