Location: Samples/08 Animator Controllers/02 3D Game Kit

Recommended After: Weapons

Learning Outcomes: in this sample you will learn:

How to remake an Animator Controller based character to use Animancer instead.

How to fix some of the problems with Unity's 3D Game Kit Lite.

How to use a Custom Fade Easing instead of the default linear fade.

How to prevant Root Motion from moving the character in a direction the player doesn't want to go.

Summary

This sample demonstrates a practical application of the Conversion page by decomposing the Animator Controller based character from Unity's 3D Game Kit Lite and re-implementing similar behaviour using Animancer's Finite State Machine system.

Sample Scene

Unfortunately, licensing restrictions (and file sizes) prevent the assets used by this sample from being included with Animancer so in order to actually see it in action you will need to:

1. Create a new project.
2. Import the 3D Game Kit Lite.
3. Fix any compiler errors you get from the packages it sets up. Often you can just open the Window/Package Manager and update anything causing errors, but you may need to search the errors online to see how other people solve them.
4. Import Animancer.

Otherwise you'll only be able to read through this documentation and the sample scripts.

The sample scene contains both the Mecanim character and the Animancer character so you can swap between them for comparison (it starts with Animancer by default).

Overview

The Mecanim character is based around a single Animator Controller:

There are 8 main states the character can be in:

1. Respawn
2. Idle
3. Locomotion
4. Airborne
5. Landing
6. Attack (MeleeCombatSM)
7. Flinch (Hurt)
8. Die (EllenDeath)

The Animator Controller contains a few StateMachineBehaviours on certain states, but it's mostly controlled by the PlayerController component. This is a poorly designed setup because even though it uses the concept of a Finite State Machine, it still violates the Single Responsibility Principle by keeping the individual logic of all states in that one huge class instead of separating their concerns into multiple scripts. The practical problems this causes are explained later on in their relevant sections.

Animancer instead uses a code based Finite State Machine with a central Character script and a separate CharacterState class for each of those states like in the State Machines samples. Many of the states directly reference their AnimationClips while some of them use Mixers to blend between multiple animations.

The key difference between the original PlayerController and this sample's Character is that the former is responsible for managing everything the character can do while the latter is only responsible for things common to multiple states like gravity and turning. For example, if you want to know what's involved in the Animancer's AirborneState, you can go to that script to see what it does. But if you want to know what's involved in the Mecanim AirborneSM, you need to examine the Animator Controller and also find the PlayerController.FixedUpdate and OnAnimatorMove methods which contain logic for input blocking, attacks, movement, turning, audio, and a time out to idle. Most of those things aren't relevant when the character is in the air, but you can't be sure of that without going through them all so it would be very much harder than necessary to find and fix any bugs or add new functionality to the character.