Mark One Dev Log #3 – Overview of the Animation System

Welcome to the third dev log for my game! In this post I’ll provide a brief overview of the animation system running for each character.Before I dive into more details about it in case you want to support my project you can wishlist on Steam using the following link:

Need of different animations

In Mark One all characters are using several different animations at the any given moment. For example, if the player is running he may decide to throw a grenade or dash or he may get hit from an enemy. This presents the need to blend two or more animations together in order to provide:

• A more realistic experience
• Visual feedback to the player of what’s happening at any given moment

Player’s character state machine

In order for everything to work together I’m using a single animation blueprint with one state machine for the player. Moreover, the same animation blueprint is used by several enemies in the game since most of their animations are the same and the have the same skeleton as the player’s character:

Initially, the player’s mesh is playing the Idle animation. From that point onwards, there are several states which are activated based on what’s going on in the game. For instance, if the player is running, then the “Jog” state gets activated. If the player decides to perform his “Sonic Punch” skill the “SuperPunchCharging” state gets activated (Super Punch is the internal name for Sonic Punch and is used throughout the code). Notice that you can enter a state from various points, for example both “Idle” and “Jog” states can transition to “SuperPunchCharging”. This is happening because the player can perform that skill while moving or by standing still.

If we take a look at the “Jog” state we’re going to see that in this state we actually have several different candidate animations to be played:

Here’s what happens when the Equipped Weapon variable changes:

View post on imgur.com

In the video above we’re seeing two different animations blending together in order to achieve the final result. For this state, I’m making sure that the animations blend together in a bone called “spine_03”. That means that the blendspace “BS_Run1D” transforms the bones below that particular bone, while the “Aim” animations transform the bones above that:

According to the bone hierarchy above and the animation blending described in the Jog state, all the bones that have “spine_03” as their parent will follow the “aim” animations, while all the other bones will follow the “Bs_Run1D”.

The same story is more or less hapenning to each state. Each state is referencing the required variables in order to play the correct animation at any given moment. However, the whole state machine provides just the “base” animation for the character.

Anim Graph

In the animation graph I’m getting the result of the mentioned state machine and later I’m blending additional animations that only fire when an event is happening (for example if the player is hit or if the player decides to switch weapons). During these events the state machine doesn’t switch states however the output is completely different as we’re blending animations on top of the given state:

Notice the “Slot X” nodes along the given graph. These nodes allow us to blend montages that belong to specific slots. For example, the UpperBody slot contains the animation that moves the hands of the character when the player is switching weapons.

The same logic with some minor modifications to accomodate specific scenarios is used to play animations for every character throughout the game.

I hope you found this dev log interesting! Would you like to read a dev log for a specific system of the game? If so, leave a comment down below!
Thanks for reading this and have a nice day! Until next time!