Skip to content

Animation Montages / Play Montage

At a glance

Montage asset: an animation asset with slots, sections, notifies, and playback control - Play Montage node lives in: Blueprint API / Animation / Montage - Target: a SkeletalMeshComponent - Returns: exec callback pins, not a pawn or pose object - Failure signal: the On Interrupted pin can fire when playback is interrupted or fails to start - Official docs: Animation Montage, Play Montage

The one-minute version

  • A Montage is for controlled actions: attacks, reloads, emotes, interactions, hit reactions, ability casts, and other authored one-shot or sectioned animations.
  • Play Montage plays a Montage on a specific Skeletal Mesh Component.
  • The node does not output a pose. Your Animation Blueprint must include a matching Slot node/layer where the montage can affect the final pose.
  • Slots decide where montage animation is inserted, often full body or upper body. Sections let Blueprint jump/start at named pieces of the montage.
  • On Completed means the montage finished without interruption. On Interrupted includes interrupted playback and common "did not play" cases.
  • Use montages for actions that start from gameplay events. Use state machines and Blend Spaces for continuous locomotion.
  • In multiplayer, replicate the gameplay event/state that should cause the montage, usually with a server/multicast or replicated variable pattern. Do not assume a local Play Montage call runs everywhere.

What a Montage actually is

A Montage is an animation asset built for runtime playback control. It can contain animation segments, sections, slots, and notifies.

AttackMontage
-> Slot: UpperBody
-> Sections: Start, Combo_1, Combo_2, End
-> Notifies: EnableHitbox, DisableHitbox, Footstep

The asset alone does not make the character attack. Gameplay code or Blueprint calls a play node, and the AnimGraph has to include a slot path that receives the montage.

Character input Attack
-> Play Montage AttackMontage on Character Mesh

Animation Blueprint AnimGraph
-> Locomotion pose
-> Slot "UpperBody" or "DefaultSlot"
-> Output Pose

If there is no matching slot in the AnimGraph path that reaches Output Pose, the montage can be requested but have no visible effect on the final animation.

What Play Montage does

The Blueprint node creates an async callback proxy that tries to play the montage through the mesh's animation instance.

pseudocode of the engine behavior - not engine source

function PlayMontage(Mesh, Montage, PlayRate, StartPosition, StartSection):
    if Mesh is None or Mesh has no AnimInstance or Montage is None:
        trigger interrupted/failure path
        return

    if ShouldStopAllMontages:
        stop existing montage playback as requested

    started = AnimInstance.Montage_Play(Montage, PlayRate, StartPosition)
    if StartSection is set and started:
        jump to that section

    bind montage ended/blend out/notify callbacks

The output pins are events:

Pin Beginner meaning
Out The request node finished setting up. Not proof the montage reached its end.
On Completed Playback finished and blended out without being interrupted.
On Blend Out Montage started blending out normally.
On Interrupted Montage was interrupted or failed to play.
On Notify Begin / End Montage notify or notify window callback fired.
Notify Name Name of the notify that triggered the notify callback.

If you need to know "did my attack window open?", notifies are usually better than guessing with Delay.

Slots and sections

Slots are the bridge from montage playback into the AnimGraph.

AnimGraph:
    Locomotion State Machine
    -> Slot "UpperBody"
    -> Output Pose

If the montage uses UpperBody but the AnimGraph only has DefaultSlot, the pose path does not match your intent.

Sections are named ranges of the montage. They let Blueprint start from or jump to a specific part:

Play Montage
Starting Section = "ReloadLoop"

or

Montage Jump to Section "Combo_2"

Use sections for combo chains, reload loops, charge/release actions, or any montage where gameplay chooses the next authored segment.

Why use a montage instead of a state?

Use a state machine state for modes the AnimBP owns continuously:

  • idle/walk/run;
  • jumping/falling/landing;
  • swimming/climbing;
  • dead or knocked down if it is a persistent mode.

Use a montage for event-driven actions:

  • attack once;
  • reload;
  • interact;
  • emote;
  • hit reaction;
  • ability cast;
  • melee combo section.

The quick path is putting every attack inside the locomotion state machine. The concrete cost is transition clutter: one-shot actions start competing with movement/falling/death transitions, and combo timing ends up spread across state rules instead of inside the montage's sections/notifies.

When it fails (and what failure does)

Common "montage did not play" causes:

  1. Mesh target is None or wrong. You called Play Montage on the wrong Skeletal Mesh Component.
  2. Mesh has no live AnimInstance. The mesh is not using the expected Animation Blueprint / Anim Class.
  3. Montage is None or incompatible. Wrong skeleton, missing asset, or bad reference.
  4. No matching slot reaches Output Pose. The montage plays through a slot the AnimGraph never uses.
  5. Another montage stops it. Should Stop All Montages, slot conflicts, or a later play call interrupts it.
  6. Play Rate is zero or not useful. Playback cannot visibly advance.
  7. Network call is local only. You played it on one machine but expected all machines to see it.

The Play Montage node can signal failure/interruption through On Interrupted. It does not fix the AnimGraph, select a slot, replicate itself to everyone, or apply damage for you.

Multiplayer note

Animation is usually presentation driven by gameplay state. If an attack is authoritative, the server should own the attack decision/hit result. Clients can play local prediction or cosmetic animation, but the game result should not come from "my client played a montage."

Common patterns:

Client presses Attack
-> Run on Server RequestAttack
-> server validates
-> server sets replicated attack state or calls multicast cosmetic event
-> each relevant machine plays montage on its local mesh

Root motion montages have additional network handling, but the Play Montage call itself still has to be triggered on the machines that should show it.

The pattern everyone actually uses

Basic attack:

Character Input Attack
-> Branch CanAttack
-> Play Montage
   In Skeletal Mesh Component = Mesh
   Montage to Play = AttackMontage
   Starting Section = "Attack_1"

Play Montage outputs:
    On Notify Begin "EnableHitbox" -> enable melee trace/hitbox
    On Notify End "EnableHitbox"   -> disable melee trace/hitbox
    On Completed / Interrupted     -> clear IsAttacking

AnimGraph:

Locomotion State Machine
-> Slot "DefaultSlot" or "UpperBody"
-> Output Pose

Combo section:

Attack input during combo window
-> Montage Jump to Section "Attack_2"

Use montage notifies for the combo window and hit window instead of hard-coded Delay nodes.

Lookalikes - which one do I want?

Tool Use when Watch out
Play Montage You want callback pins for completion, interruption, and montage notifies on a mesh. Needs mesh target, AnimInstance, asset, and slot path.
Play Anim Montage Character-level convenience for a character's mesh. Fewer callback conveniences than Play Montage.
Montage Play in AnimInstance/C++ You are controlling montages from code or AnimInstance logic. Same slot/asset requirements still apply.
State Machine state Animation mode is continuous and rule-driven. One-shot actions can clutter locomotion state machines.
Blend Space Continuous speed/direction chooses between samples. Not for authored combo sections.
Animation Notify An animation should fire a timed event. Not a replacement for starting playback.
Ability Task Play Montage and Wait Gameplay Ability System ability should play/wait for montage. Ability-system-specific flow.

Rule of thumb: montage for event-driven action, state machine for current mode, Blend Space for continuous sample blending, notify for exact timing.

Going deeper