> For the complete documentation index, see [llms.txt](https://polyart.gitbook.io/pixel-2d/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://polyart.gitbook.io/pixel-2d/guides/animations-and-state-machines.md). # Animations & State Machines {% hint style="info" %} **Good to know:** Both the Platformer Engine & Top-Down Engine share a lot of functionality. and a lot of times the same techniques can be applied to both engines. {% endhint %} ## Setup Any item that needs to be animated needs a flipbook made out of the individual sprites of each state the character has.

To do that, first import the sprites of your choice. you can also import a sprite sheet. However then you will have a few extra steps.

**Apply Paper2Dtexture** to what you have imported by **Right-Click → Sprite Actions**. If you have imported a sprite sheet, you will also have to **Extract Sprites** through **Sprite Actions.**

Unreal should be able to recognize your sprites and extract them automatically but if that’s not the case, switch Auto mode to Grid mode for better control over your sprite sheets.

Select the sprites that make up one animation and turn them into a single flipbook. Do this with each state for your player/animated object.

You do NOT have to make separate animations facing right and left. We will learn how to flip the animations through code later on.

Next, click on a flipbook to make any changes to animation speed or even the animation itself. You can add and delete frames here without making another animation.

## Inside the Sprite Animation If you are familiar with Unreal and it’s animation tools, you will find the **Sprite Animation** easy to navigate, however knowing animation blueprints before isn't a necessity. Here are elements you will find in the animation blueprints. ### State Machines When you open the animation blueprint, you will most likely start in the **Anim Graph.** Here you can add a state machine with **Right-Click → New Sprite State Machine**. The Sprite State Machine is a container that holds your States, Conduits, Transitions, and Animations. You can also add state machines inside states to help you organise your animations. You can get more information over here:

### States Inside a **State Machine** you will see the Option to add **States** and **Conduits**. We will discuss about **Conduits** with transitions due to their complementary functions.

**States** are objects that hold animations or nest other **State machines**. Every action your character does (walking, picking up, attacking) is a **State**.

In top-down view, you will have 3 states for each action: Action facing up, Action facing down, and Action facing side (we will flip the sprite left and right using blueprints). Inside each of them we are going to add a state machine with all of the actions we expect the player to take.

You don’t have to do it exactly like this, you are free to experiment and find a method that works for you.

Inside each of these states is a respective flipbook connected to the result node.

But how does Unreal know which **State** should be played when? That’s where **Transitions and Conduits** come in. ### Transitions and Conduits *Jormongandr has provided a great answer in this forum if you would like to understand the difference between Conduits and Transitions better* [AnimBP: What is a Conduit and why do you need it?](https://forums.unrealengine.com/t/animbp-what-is-a-conduit-and-why-do-you-need-it/363568/4) #### Transitions Transitions are rules that define when one State or Conduit changes from another. Not all states need to be connected to each other, but each state needs at least two transitions: One to enter into the state and one to exit out of the state.

You can hover over transitions to check if they are empty or correctly coded

{% hint style="info" %} If you see an error with the **Can Enter Transition** Node as shown below, its because the transition will not occur without a rule attached. If you don’t have a rule for this transition, just check the box to set it to **true**. {% endhint %}

Let's create a transition as an example. Say you want the Animation to change everytime the player attacks. First we need to know when the player is attacking. Inside the Player Blueprint let's create a **Boolean** called *IsAttacking?* that is set to true everytime the player attacks, and is set to false when the attack ends.

Now we need to make sure our blueprint can call this variable (a.k.a it can use it to transition in and out of our attack state). For this, we need to use our **Event Graph inside the Animation Blueprint.** Here, we are casting to player character to store the attack bool and other variables as a local variables I can use for transitions.

Double-click on the Walk to Attack and Idle to Attack to create this simple transition for attacking.

You would be tempted to make the Attack to Walk and Attack to Idle transition like this.

However, when you do you notice the animation stops in its tracks. That's because as soon as the Boolean is set to false, the blueprint transitions out of the respective state. You can either fine-tune the code using precise delays or, you can use **Get Relevant Anim …** Nodes and use **Less than** nodes to transition as soon as the animation ends. I have used both types of nodes for the transitions as I will show later.

### Conduits **Conduits** are animation-less States. If you double-click them, you will see that they look more like transitions then states because you can add rules to them as well, but usually setting *Can Enter Transition* to true is enough.

They are used to create branches and streamline animation blueprints. Without Conduits we had to connect Walk and Idle to each type of attack. Though that looks manageable when you only have three attacks, as you need it will become an absolute mess the more attacks you have.

You may have also noticed before that there are two variables defining my player’s attack. The *IsAttacking?* bool defines whether my player is attacking or not and the *AttackType?* Enum (specifically an **E\_AttackList Enum**) decides which type of attack it is going to be.

Instead of creating 6 different transitions with variations of both variables, here’s how our **State Machine** for Melee Attack is arranged. For **Idle/Walk State → Attack Conduit Transitions** we used a local bool connected to the player’s *IsAttacking? b*ool.

For **Attack Conduit → Idle State**, we simply added a **Not** node to the local boolean, so the animation will switch to idle once the attack ends.

Inside the **IsAttacking? Conduit** we also set *Can Enable Transition?* to **true** so that the transitions can occur without an additional rule.

From the **Attack Conduit → Melee/Grenade/Magic** we compare a local **E\_AttackList** enum (*Anim Attack Type?)* to *Melee Attack* with an **Equal to (==)** Node.

A.k.a The player will play the Melee animation if *Anim Attack Type* is set to *Melee Attack*. From the **Melee State → Attack Conduit**, we use the **Get Relevant Anim Time Remaining Fraction** with a **Less than** Node to transition back once the animation finishes playing.

And that completes our transition loop for Melee attack. ## Using Notifies If you want to set up Events triggered by specific animation frames, you will use Notifies. To use notifies, double-click on a state where you have a flipbook attached to the **Result** Node. Here I have opened **MeleeUp** flipbook, which automatically opens up in the **Notify edito**r. We can **double-click** on the frames to check which frame it is, and **Right-click** on them to **Add** or **Move a Notify** to that location.

To make sure you can call this event in the player’s Blueprint: Create two custom events inside your player’s BP that would be triggered by the Notifies.

In your player’s animation blueprint’s event graph, you can call each notify, cast it to your player and use it to trigger your Custom Events.

Now you can use the notifies to trigger your code, like we are using it to spawn a test fireball.

## Left/Right Animation Mirroring You can be efficient and only use one set of flipbooks for both right/left orientations and just flip them 180. First, you need to make changes to your movement code. Start by attaching the *IsMoving?* bool (more information in the Core Game Mechanics page) to two different bools (because the state machine does not like it when the information is collected by a single bool). Then connect both bools to a branch.

Create an Enum Variable out of E\_MovementDirection to store the direction your player will be facing.

You can set the direction any way you want. Here are two examples to start with. The important part is to make sure the **Set World Rotation** Values are the way it’s shown in the example.

Of the two, the upper one is a more polished code though both would work. Especially, by storing everything in variables and using the absolute function, the above code is more bug free and its much easier to change values through blueprints, compared to the code below. In your animation blueprint, go to the transitions for **Up/Down → Side**. Make sure the Side state is called whether the direction enum is set to left or right.

With this, your player should flip depending on which side they are on.

{% hint style="info" %} If your screen starts becoming blank instead, make sure to disable **Use Pawn Control Rotation** in the Camera and Spring Arm Player objects. {% endhint %}