THE RUNTIME MODE PHASE. USE THE COMPONENTS "CNBanimLinker" AND "CNBinputAdapter"

We will drag a “CNBPlayerPrefab” to the scene or we will create in the scene a new “GameObject” and we will add scripts with functionality responsible for input system and controller (components “Controller2D” + “Player” + “Player Input” + “BocCollider2D”), in addition to the component “CNBInputAdapter” that uses information of the previous ones to solve, in an automatic and encapsulated way, which animation to reproduce in every moment and to implement the auxiliary methods exposed in “CNBanimLinker component”, necessary for the operation of the system.

Any character to which a “CNBanimLinker component” has been included in the “EDITOR MODE” phase will automatically coordinate with the “CNBInputAdapter” component. The scripts with input and controller system functionality (components “Controller2D” + “Player” + “Player Input” + “BocCollider2D”) will be in each case those used by each developer and the only configuration work will be to send to the “CNBInputAdapter” component the necessary information about the “player input” and “controller” variables that, adapting to the needs of each case, in the example included are reduced to the character speed and a “bool” that indicates whether or not it is in contact with the “inGrounded” ground. In this way, the level of encapsulation of the controller and animation systems of the “character” is maximum and, this non-dependence of one and the other, maximizes the ease of implementation, scalability and automation of the system.

The “CNBanimLinker” component includes the core functionality of the animation system. The creation and initialization of a “CNBanimLinker component” in the model to be animated will automatically generate the new states, transitions and animation parameters required to call the exposed auxiliary method “ChangeAnimationState(AnimData newStateAD, bool random,int indexNotRandom =0, int indexMin = 0, int indexMax = 0)” and by choosing the appropriate parameter combination, the system will autonomously be able to automatically find an animation that reaches the level of detail of ‘ATTACK_NODIR_JUMP’ or ‘MOVE_RIGHT_CROUCHING’. In the “CNBInputAdapter component” we will explain the flexibility to call the desired animation in an almost fully encapsulated way, with the help of only some “Player Input” and “Controller” information that we are using in each case. What makes the difference from the point of view of ease of use, reliability and reusability is:

• You will never again have to call "Animator.PlayClip("string name")" or "Animator.setBool("string name")", this means no more error-prone and difficult to debug "magic strings".
• With a well-designed "asset" of type "AnimationSO" to get all the relevant information in the original names of the "AnimationClips" we want to use, we can rename as many animations as we want at the click of a button. With the new names adapted to be recognized by the system, just press a button and, in a few seconds, a "CNBanimLinker" component will be added and initialized to obtain and store in data structures all the information needed to call the right animation at the right time.
• The editor workflow to rename clips, add the "CNBanimLinker" component and initialize it, is independent of the runtime workflow to call the desired animation at the desired time.
• The runtime workflow code is encapsulated depending very little on the "player-input" and "controller" information (e.g.-bool "isGrounded") to work correctly.
• Creating a new "CNBInputAdapter component" that fits our needs is easy by inspecting the included example and creating a class derived from it, thanks to the flexibility and ease of calling the auxiliary methods exposed in both "CNBAnimLinker" and "CNBInputAdapter".
• Once the new "AnimatorController" component is created you have the states, transitions and parameters created and stored in data containers where you have all the information needed by the auxiliary methods to call the desired "AnimationClip" at the right time.
• But, as it is impossible to create from scratch an animation system that fits 100% to the creator's needs, you can think of this situation as a really advanced starting point from which to make the necessary detail adjustments.

The main role of the “CNBInputAdapter” component is to collect the necessary information from the “PlayerInput” and the “Controller” and use it to solve the “state” in which the character is, without worrying about the animations, but with this information and thanks to the auxiliary methods exposed, we will have the necessary information and functionality to automatically find the animation to be played.

All the info shown in the inspector but the "Anim Asset Type" field are there for debug purposes. If you are animating 3d models  "Anim Asset Type" must be set to "MODEL 3d" and if you are using sprite sheet animations must be set to "SPRITESHEET".

Three “Enum” type variables are created in the component, representing three state machines. Depending on the information of the “PlayerInput” and “Controller”, each of these state machines automatically determines in which state of basic information, additional information type “PlayerInput” and additional information type “Position state” we are and chooses an animation that meets these three conditions. The elements of the three “Enum” have names equal to the categories of basic information, additional information type “PlayerInput” and additional information type “Position state”, established in the “asset” of configuration “AnimationsSO” that is being used, so we have a correspondence between the state according to the information of the “PlayerInput” and “Controller” and the name of the basic information, additional information type “PlayerInput” and additional information type “Position state” of each animation. 

The routing is to choose the desired animation type according to the external input and controller data updated in the “Update()” automatically.

“CNBAnimLinker” exposes a versatile helper method ‘MMBPlayClip(string typeName, bool random, int index)’, and this is the method that the ‘CNBInputAdapter’ component uses after deciding which index passes all the category checks and additional information set in the parameters.

This encapsulated and automated roadmap, makes a really easy to use, reusable and reliable “CNBInputAdapter component” that you can easily adapt to specific needs, once you understand the ways to use the new information available to create auxiliary methods that fit those specific needs.

The product we have developed adapts to all scenarios, since it is a matter of creating from scratch new “AnimatorControllers” adapted to the configuration stored in an “AnimationsSO scriptable object asset” and creating the data structures to store all the necessary information for the exposed auxiliary methods to work. It is, objectively, an advanced starting point that takes advantage of the virtues of “MECANIM” giving an effective solution to its main problems.

The “CNBInputAdapter” component included in the “asset” is an example of the way in which this product can be used since it is impossible to fit all scenarios (2D, 3D, complexity of the additional information, information available from the “controller” to determine in which “state” we are in each moment, “PlayerInput” system, etc). The example script included in the asset is for the use case of a complex 2D game (climbing, swimming, blocking target, attacks in different positions, etc) with a controller also included and using the new Input System. In this example you can move, run, swim, climb, block target, when you attack standing, while jumping or crouching, choose the right attack animation, etc, and everything is done almost automatically and in an encapsulated way. In the asset I only include the script because the animations I use are not ours, but we will make a video of how you can implement our solution if you have those animations or similar.