Godot Animation

Problem

Godot 4.x animation work often fails not because clips cannot play, but because the wrong tool owns playback. AnimationPlayer, AnimationTree, and Tween overlap in practice, so state machines may not take over, parameter paths can silently no-op, and editor keyframes can fight code-driven tweens. This skill maps those choices to a concrete workflow: author keyframed clips, drive runtime blending with a state machine, and use code tweens for one-off UI or object moves.

How It Works

It picks the tool by job:
- AnimationPlayer stores keyframed tracks such as transforms, properties, and method calls.
- AnimationTree blends or transitions between clips at runtime using state machines or blend spaces.
- Tween is created in code with create_tween() for short, fire-and-forget interpolation such as UI fades, pops, and one-shot offsets.

The core pattern is to build clips first, then make AnimationTree the playback owner: set active = true, bind anim_player, and use an AnimationNodeStateMachine or AnimationNodeBlendSpace2D as the tree root. Code can then switch states via playback travel or blend parameters, while animation_finished plus call/method tracks handle clip events. For 2D sprite sheets, use AnimatedSprite2D with SpriteFrames, or keyframe the frame property in AnimationPlayer.

Boundaries and Pitfalls

Use it for animation playback, blending, and tweening, not for movement logic, UI layout, or shader effects. Common gotchas include leaving AnimationTree.active false, writing parameter paths that do not exactly match tree node names, and calling AnimationPlayer.play() on tracks already owned by an active tree. In Godot 4.x, there is no 3.x-style Tween node; tweens are code-created, one-shot objects, and sub-property paths such as modulate:a and position:x must be used to avoid overwriting sibling values.