News of Unreal Engine 5.4 surfaces, and out of all the new features from the update, motion matching sounded like a handy tool for replacing the state machine method in ABPs. I had to check it out for myself with a small detour.

Unlike traditional animation systems, motion matching can make automatic animation pose selections from a set of animation data to create a responsive and reactive animation system, without the need to set up transition or blending logic between animation sequences.

Since motion matching is still a work-in-progress, an experimental add-on is used to support and execute it. Introducing Pose Search, an add-on for your motion matching components to fetch poses with, and  Motion Trajectory (MM), an add-on system which generates predictions and track history of character motion.

Heading to your player blueprint, the Character Trajectory component will provide the system a foundation to guess which animations from your MM component will play when it moves ot does anything. I will elaborate on said components early on. 

Working with MM deals with background information more than the actual input. Putting animations into your query is a simple matter; tweaking them to work with the system is a moderately technical matter.

First off, you will need to create two components: a Pose Search Schema (PSS) and Pose Search Database (PSD). The former stores your MM configuration and query settings, while the latter stores animations you have put into.

You will also need to tinker with your existing animation sequences if you want the motion matching system to run them smoothly.

Firstly, select all animations you want to become MM-compatible in the Content Browser. Next, right-click the selection and edit them in the property matrix, found in the Asset Actions tab.

Root Motion is the motion of a character that is based off of animation from the root bone of a skeleton. For example, not having Root Motion in a running animation means the skeleton will return to their original position after said animation has been completed. Enabling it ensures your mesh does not instantly teleport back to their old spot as if time had been rewound.

As I have mentioned in bits and pieces in my past blogs, locomotive animations track players' speed and velocity to figure out how fast or partially each related animation will be executed. In motion matching, trajectory - the path an object with mass follows as it moves through space - is checked instead (see slide 2).

If you compiled this blueprint and tested it, you would get a non-game-crashing error in a blueprint name FootstepEffectTagModifier (see slide 3). For convenience's sake, just disconnect the track between the two leftmost nodes and move on.

Sadly, this new feature cannot reliably play jumping and falling animations yet. This appears to apply for all 'motion managed' vertical movements. For now, though, enjoy your state-less horizontal plane locomotion!

Now we return to RPG development. Many games of this genre gave players the ability to crouch. In this mode/state, player maximum speed will be realistically reduced but gain some bonuses. Today's focus will be on the mechanics of crouching.

Apply what you have learnt about Blend Spaces and Root Motion into creating the BS1D for crouching idly and walking forward while crouching. Ensure both animation sequences have Force Root Lock enabled so both do not run in your game…

Like this.

I will make the crouch state in a separate state machine primarily for organization and optimization purposes, as stuffing everything into one state machine makes it difficult to relocate the locations of functions and states.

Back to the Main state machine, the state Crouched-Locomotion

My crouch states and conditions are reliant on Boolean variable isCrouched to know which state (standing or crouching) the player is at right now. Instructions on letting the blueprint check the player's crouching state are at the lower paragraphs.

You will next need a button function to enter the crouch state. Create an IA (Input Action) for toggling crouch mode, then head to your game mode's IMC (Input Mapping Context). Inside, create a mapping, then pick a button on your device to link with. You ask me, I prefer the left control button on my keyboard.

Before you head back to your ABP (animation blueprint), create a Crouched? Boolean variable in your player blueprint. You will link said variable to the ABP's 'IsCrouched' to tell the system your player's current state between standing upright or crouching.

Introducing the Flip Flop node, a node with paths A and B (starting with A) that changes its gate per activation. Click the crouch button while standing, path A sets 'Crouched?' to true and lowers the max walk speed fetched from character movement. Click it again and your player is no longer crouching and will be walking at their starting speed (which you can manually edit).

A quality-of-life gimmick for both crouch and idle states from the tutorial is camera control. Using a Timeline node,  I can create a activatable sequence which alters the target arm length of the player camera based on their state.

Another node that makes this possible is the Lerp node, which functions similarly to the Flip Flop node but for non-link nodes, and can be set to fluctuate between values A and B depending on its third Alpha category (0 for A and 1 for B).

Far out!