Animation Integration in Unity Animator Controller
Animator Controller is not just a list of animations with transitions. It's a state machine living alongside game logic and with careless setup becomes source of most animation bugs in project: jerky transitions, animations stuck in wrong state, Blend Tree out of sync with movement speed.
Animator Controller Architecture for Real Project
Typical error during project growth: everything in one layer, all states in flat list. Works for prototype with five animations, breaks at thirty. Correct structure—several layers with explicitly assigned Avatar Mask and Blending Mode.
Base Layer—locomotion and idle. All movement from root: Blend Tree by Speed (idle → walk → run → sprint). Root Motion or In-Place—by gameplay requirements. This layer always works.
Upper Body Layer—attacks, aiming, interactions. Avatar Mask: upper body. Blending: Override. Activates on attack state entry, doesn't interrupt lower body locomotion. Important: this layer Weight must be controlled through code (animator.SetLayerWeight(1, 1f)) on activation—otherwise zero-weight layer is completely ignored.
Additive Layer—hit reactions, breathing, aim sway. Blending: Additive. Animations in this layer overlay above everything without replacing. Breathing cycle with 0.02 amplitude on Y-axis on spine—imperceptible directly, but character without it looks static in idle.
Sub-State Machine used for combo systems and complex sequences. Grouping states inside Sub-State Machine makes graph readable and allows reusing same transition logic for multiple characters.
Parameters and Transitions: How Not to Get Jerky
Parameter type affects transition behavior. Float with dampTime 0.1–0.15—for everything speed-related and smooth changes. Bool—for states (isGrounded, isAiming). Trigger—for one-time events (jump, strike). Integer—for state indices (0=idle, 1=walk) but in most cases worse than Float.
Transition settings often left default causing problems:
Has Exit Time—when enabled, transition waits for current animation completion. Good for attacks (don't interrupt mid-swing). Bad for locomotion (character doesn't respond instantly). Enabled by default—need to disable for most states.
Transition Duration—in seconds or normalized time. 0.1–0.25 seconds for most locomotion transitions. 0.05 or less for fast reactions (landing, block reaction). 0—instant transition, needed for death and teleport states.
Interruption Source—determines if new Trigger can interrupt current Transition. Current State—current state can return control. Next State—next state can be interrupted. Both—used in combo systems with cancel window. Ignoring this parameter causes Trigger to be "swallowed" during Transition and attack registration fails.
Blend Tree for Locomotion: Root Motion Setup
1D Blend Tree by Speed—standard for forward movement. But strafing requires 2D Blend Tree. 2D Freeform Directional type gives best result for eight-directional locomotion: forward, backward, left, right and diagonals. Parameters: VelocityX and VelocityZ, updated from code with dampTime.
Compute Thresholds → Compute from Root Motion Speed automatically sets thresholds from clips. Works correctly only if clips have Root Motion. If using In-Place animation—thresholds must be set manually, otherwise Blend Tree interpolates incorrectly.
Layer Sync: if Upper Body Layer uses same states as Base Layer (e.g., separate idle with weapon for upper part), use Sync checkbox on layer. Sync copies State Machine from base layer but allows different Motion for each state. Saves time and doesn't desynchronize transitions.
Animation Rigging Above Animator Controller
Animation Rigging (package com.unity.animation.rigging) adds procedural constraints above key animation. Two Bone IK for legs and arms, Multi-Aim Constraint for head during aiming, Chain IK for tails and hair.
Rig Builder component added on Animator object. Constraints work in Rig layer order—important for dependencies: shoulder first, then forearm, then hand. Each constraint weight (0.0–1.0) managed through code or Animation Curve—convenient for smooth Foot IK enabling on landing.
Integration Timeline
| Task Scale | Estimated Duration |
|---|---|
| Basic Animator Controller (idle, walk, run) | 4 to 8 hours |
| Multi-layer controller with combat system | 2 to 4 days |
| Full Animation Rigging integration | 3 to 5 days |
| Existing controller refactoring | 1 to 3 days |
Cost depends on state count, transition complexity and existing code management. Calculated after project audit.