Animation controllers: giving our entity an attack animation;

Attack Animation

First, let's create the animation itself in Blockbench. Choose File>Open Model>yourModelFile and choose the Animation workspace in the top right corner. Now, unlike the walk animation we already created, our attack animation will consist of a single frame, because Animation Controllers have a "transitions" feature that blends two following animations smoothly. After you're done, name your animation animation.entityname.attack, choose Export Animations and replace your old animations file in res/animations.

Note: you can find Animations documented on and For Behavior Animations, refer to Events.

< As you see, the attack frame is created fully under the keyframe '0'.

Now for the actual

Animation Controller.

Create res/animation_controllers/entityName.animation.controller.json. Let's go over the overall structure of an animation controller:

  • The animation controller's identifier is controller.abimation.skele_yaklin.attack(There's an error on the screenshot). We'll define it in the .entity file like a normal animation.

Animation controllers are State Machines, which means they work on states. Every state is mutually unique, but they can transit between each other.

  • "initial_state" defines the state that the entity will spawn with;

  • "states": {} includes every state's object.

Let's go through the states themselves:


  • The "animations" array includes all animations the same way as "scripts/animate" in the .entity file. If you put an animation shortname like this "walk", the animation will play all the time during which the state is applied. Here we moved { "walk": "query.modified_move_speed" } from ".entity/scripts/animate", which means that if the state is currently applied AND the entity is moving, the walk animation will play.

  • The "transitions" array controls in which state the current state can transit in. For example, in this scenario, if variable.attack_time > 0 turns true, the state will change from "default_state" to "attack_state".

(You can see more about queries here, in the Resource Entity Definitions tutorial.)

  • "blend_transition": 0.1 means that the states will transit between each other smoothly, resulting in a smooth visual blend.

  • "attack_state" is very similar, with the exception that the animation, "attack", is run all the time the state is applied. The state transits back to default when attack time is 0 again, or, in other words, the entity no longer attacks.

A note from the author: The showcased animation controller is a great example of a resource animation controller, also being a great way to implement attack animations. There are some less efficient or much more complicated methods to achieve the same goal out there, but I've been using this one ever since I, myself, found out about it.

Resource and Behavior file edits

Now, let's define the animation controller and the attack animation in the .entity file. The animation controller shortname should be included in "scripts/animate", so it's active all the time:

Lastly, let's give our entity the ability to attack. The needed components are:

  • "minecraft:nearest_attackable_target", which chooses the mobs the mob will attack;

  • Attack AI: We'll use "minecraft:behavior.melee_attack" right now, you can see other attack AIs in the Vanilla Example behavior files.

  • "minecraft:hurt_by_target" makes the mob attack back any entity that hits it.

  • "minecraft:attack" defines the value of the damage the entity deals.

I included these attributes in the "tut:wild" component group.

Behavior Animations

Animations and animation controllers are typically defined in the Resource pack. However, there's a certain type of those files that are to be located in the Behavior pack. They are thus called Behavior- (or server- ) Animations.

Behavior animations are able to execute slash(/) commands and to trigger events from the entity behavior file.The syntax is similar to normal resource animations and animation controllers, which are used to run visual animations. Behavior Animations are located in bhv/animations/ and Behavior animation controllers in bhv/animation_controllers/ . The file name is not important, but the animation identifiers are.

Behavior Animation;

Here's an example of a Behavior Animation, that executes multiple slash commands on an entity:

This animation file includes two animations:

"animation.grufallo.revenge" and "animation.yaklin.on_summon".

  • When the animation is triggered, things happen based on the timeline. After "0.0" seconds has passed, the entity will execute the /effect command. Note that after every keyframe (like "0.0", "2.0", etc) either a string with a single command or an array [], including multiple strings with commands, must stand.

  • On the first tick of the animation the entity executes a /say command, and another one after 1 second. Note that slash commands can only be the ones that can be executed from chat.

Here's an example

Behavior Animation Controller

, that can be used to track AFK players. (You can scroll the code box for better readability)

  • "controller.animation.player.afk" is, of course, the identifier.

  • If the Molang query !query.is_moving returns false(the player isn't moving), the state transits to the "stand_still" state.
    (You can see more about queries here, in the Resource Entity Definitions tutorial.)

  • When the state gets entered, "on_entry" gets triggered, which runs the following slash commands.

  • "animations" includes the Behavior Animation's shortname that is to be ran during the whole time the state is active, just like in Resource Animation Controllers.

  • If the player is moving again, the state will transit to "default" again.

The commands "on_exit" will be executed.

You can also trigger a behavior event (defined in the entity behavior file>"events": {}) on the entity which runs the command. Here, on the "0.2" keyframe, the entity runs the /tag command and then runs the "jdot:tagged_alt" event, which removes or adds some component groups. For more info see the Behavior events definitions Page.

"0.2": [

"/tag @s add TAG",

"@s jdot:tagged_alt"


Defining behavior animation' Shortnames in the Behavior file;

Just like resource animations and animation controllers, Behavior animations and animation controllers need to be assigned a shortname and called in "scripts>animate". For resource ones, it's done in the .entity file (res/entity/entityname.entity.json), but for behavior ones it's done directly in the entity behavior file: bhv/entities/entityname.json/"description: {}. (For more information on the behavior file and the "description" object see the Entity behavior definition Page.

Here's an example:

The "description" object in a behavior file is where the entity's identifier and some configurations are stored. After the "is_experimental" config we added "animations" and "scripts"/"animate", exactly like in an .entity file.

  • "revenge" is the shortname for the animation with the id "animation.grufallo.revenge".

  • The animation with the shortname "revenge" gets ran if the entity isn't alive in scripts>animate, or, in other words, when the entity is dying, or, in other other words, when the query returns true. (You can see more about queries here, in the Resource Entity Definitions tutorial.)

  • Animation controllers can be ran the same way as in the .entity resource file.

You can find out more about animation controllers by checking out these guides:

  1. Entity Events documentation - this one is written in a tutorial form;

  2. Other documentations related with animations:,

  3. SirLich's Entity Commands Tutorial(a.k.a Bhv Animations);

Your progress so far:

What you've done:

  • Learned to use client Animation Controllers;

  • Added an attack animation and AI to your custom entity;

  • Learned to execute commands through server-side animations and animation controllers.

What are you to do next:

  • Create custom sounds;

  • Add particles to animations;

  • Potentially create custom particles;