| name | godot-animation-tree-mastery |
| description | Expert patterns for AnimationTree including StateMachine transitions, BlendSpace2D for directional movement, BlendTree for layered animations, root motion, transition conditions, advance expressions, and state machine sub-states. Use for complex character animation systems with movement blending and state management. Trigger keywords: AnimationTree, AnimationNodeStateMachine, BlendSpace2D, BlendSpace1D, BlendTree, transition_request, blend_position, advance_expression, AnimationNodeAdd2, AnimationNodeBlend2, root_motion. |
AnimationTree Mastery
Expert guidance for Godot's advanced animation blending and state machines.
NEVER Do
- NEVER call
play() on AnimationPlayer when using AnimationTree โ AnimationTree controls the player. Directly calling play() causes conflicts and jitter. Use set("parameters/transition_request") or travel() instead.
- NEVER forget to set
active = true โ AnimationTree is inactive by default. Animations won't play until $AnimationTree.active = true.
- NEVER use absolute paths for parameter access โ Use relative paths like
"parameters/StateMachine/transition_request". This ensures compatibility when nodes move in the hierarchy.
- NEVER leave
auto_advance enabled for interactive states โ It causes immediate transitions. Use it only for automated sequences like combo chains or death-to-respawn.
- NEVER use
BlendSpace2D for 1D blending โ Blending only speed? Use BlendSpace1D. Blending only two states? Use Blend2. BlendSpace2D is specifically for X+Y directional inputs (strafe).
- NEVER update
AnimationTree parameters every frame without a guard โ Setting parameters via set() every frame regardless of change causes cache invalidation and potential stutter. Check equality first.
- NEVER use deep, nested
BlendTrees for simple logic โ Every layer adds CPU overhead. If logic can be handled in a StateMachine or a simple script-driven Blend2, do it there.
- NEVER forget to handle
await get_tree().process_frame when updating parameters synchronously โ Sometimes the tree needs one frame to reconcile state before the next parameter change takes effect.
- NEVER rely on
auto_advance for long cutscenes โ If an animation is interrupted, auto_advance can put the character in a broken state. Use Method Tracks to signal state completion instead.
- NEVER use
Sync groups for animations with wildly different lengths โ It forces one animation to play at an extreme speed. Use TimeScale or separate layers for mismatching cycles.
Available Scripts
MANDATORY: Read the appropriate script before implementing the corresponding pattern.
Do NOT Load references/advanced-graph-recipes.md unless nested combat graphs, IK look-at, or deep BlendTree layering are in scope.
Guarded AnimationTree parameter writes โ prevent redundant set() churn every physics frame.
Programmatic AnimationNodeStateMachinePlayback via travel() / start().
Trigger: multi-machine travel / request queue. Centralizes travel requests across nested playback paths without calling AnimationPlayer.play().
Trigger: locomotion + combat (or air) sub-machines. Nested StateMachine parameter paths and playback handoff.
Trigger: aim/look-at beside the tree. LookAtModifier3D / IK that must not fight bone tracks the tree owns.
AnimationNodeOneShot for recoil, blinks, and hit reactions.
Runtime playback speed for bullet-time or haste multipliers.
Bone filter masks on Add2/Blend2 for upper/lower body separation.
Interactive combat layer mixing inside BlendTree graphs.
CharacterBody motion extraction from AnimationTree root motion.
Sync groups for multi-layer clips that share length (e.g. walk + reload).
Hierarchical StateMachine / nested parameter path architecture.
Visualize current states, travel paths, and blend values at runtime.
Method-track โ dispatch_event(name, metadata) signal bridge; decouple VFX/audio from graph code.
Swap tree_root hero vs crowd graph when VisibleOnScreenNotifier3D culls off-screen actors.
Decision Tree (replace inline tutorials)
Core Concepts (compact): AnimationTree owns an AnimationPlayer via anim_player; root is StateMachine / BlendTree / BlendSpace; parameters use relative "parameters/..." paths; set active = true once in _ready.
@onready var anim_tree: AnimationTree = $AnimationTree
@onready var playback: AnimationNodeStateMachinePlayback = anim_tree.get("parameters/StateMachine/playback")
func _ready() -> void:
anim_tree.active = true
Do not paste full StateMachine/BlendSpace editor walkthroughs โ author graphs in the AnimationTree editor, then drive them with the scripts above.
Expert insights (WHY โ keep in body)
- Advance conditions vs travel โ WHY: bool conditions auto-fire transitions;
travel() is explicit pathing. Use conditions for damage/death events; travel for locomotion intent.
- BlendSpace2D cost โ WHY: 8-way blending samples multiple clips. Use BlendSpace1D for speed-only; Blend2 for two-state crossfades.
- Parameter guard โ WHY: redundant
set() invalidates tree cache every frame. Route writes through sync_parameter_manager.gd.
- Method tracks โ WHY: gameplay should listen to dispatcher signals, not parse animation names. See animation_event_dispatcher.gd.
Deep recipes (on demand)
Reference
Progressive disclosure: open Official Documentation links only when researching a specific API;
load Related Skills when routing work to a peer domain โ do not preload the whole lattice.
Official Documentation
- Using AnimationTree โ Canonical BlendTree / StateMachine / BlendSpace graph workflow that drives an AnimationPlayer without calling
play() yourself.
- Introduction to the animation features โ When to graduate from AnimationPlayer-only clips to an AnimationTree for blending, travel, and layered presentation.
- Animation track types โ Method and value tracks that fire gameplay events (footsteps, hitboxes) from clips the tree is already blending.
- AnimationTree โ
active, tree_root, anim_player, root-motion getters, and the parameters/* path contract used throughout this skill.
- AnimationNodeStateMachine โ Authoring nested locomotion/combat graphs and wiring transitions before code calls
travel().
- AnimationNodeStateMachinePlayback โ Runtime
travel(), start(), get_current_node(), and travel-path inspection for code-driven state changes.
- AnimationNodeStateMachineTransition โ Advance conditions,
auto_advance, Sync, xfade, and priority rules that prevent sticky or immediate unwanted transitions.
- AnimationNodeBlendSpace2D โ Directional strafe/aim blending via
blend_position (use BlendSpace1D when only speed is needed).
- AnimationNodeBlendTree โ Layered Add2/Blend2/OneShot graphs for upper-body aim, combat overlays, and filter masks.
- AnimationNodeOneShot โ FIRE/ABORT request enum for recoil, hitreact, and other high-priority non-looping overlays.
- AnimationNodeTimeScale โ Per-subtree playback speed for haste, stun, and bullet-time without mutating Engine.time_scale.
Related Skills
Prerequisites
- godot-animation-player โ AnimationTree owns playback of clips authored on AnimationPlayer; track layout and ownership must be correct before blending.
- godot-input-handling โ Stick/keyboard vectors and actions that feed
blend_position, advance conditions, and travel targets each physics frame.
- godot-signal-architecture โ Safe wiring for method-track dispatchers and animation-finished style signals without lifecycle leaks.
Complements
- godot-2d-animation โ Sheet/cutout and 2D locomotion presentation that still uses AnimationTree BlendSpaces or simple travel graphs.
- godot-state-machine-advanced โ Gameplay FSMs that should own intent while AnimationTree owns presentation travel and blends.
- godot-physics-3d โ CharacterBody3D / move_and_slide integration for AnimationTree root-motion extraction.
- godot-characterbody-2d โ Fixed-timestep 2D locomotion inputs that drive StateMachine travel and BlendSpace positions.
- godot-tweening โ Tweening TimeScale or blend amounts when bullet-time and combat mix ramps should be interruptible.
- godot-combat-system โ Hitreact/combo layers that consume OneShot requests, upper-body Add2 masks, and nested combat sub-machines.
- godot-debugging-profiling โ Profiling and logging discipline when validating travel paths, blend values, and off-screen
active culling.
Downstream / consumers
- godot-genre-action-rpg โ Locomotion + combat stance trees and ability cast OneShots built on these graph patterns.
- godot-genre-fighting โ Frame-sensitive combo auto-advance and masked upper-body attacks depend on transition and BlendTree discipline here.
- godot-genre-shooter-fps โ Aim/reload overlays, recoil OneShots, and look-at modifiers layered over locomotion BlendSpaces.
Master
- godot-master โ Library router and mirrored module entry for cross-skill discovery.