A large-scale project designed for Unreal Engine 5.7+ that includes mechanics commonly used in adventure games.

⚙️The project is based on C++ (6 C++ plugins), but modifying the source code is not required — changes can be made entirely through Blueprints.

Not all animations are included in the project (list), but they are not required for the project to function.

The project is compatible only with Windows systems. Packaged only on Win 11.

The entire system is NOT replicated.

🏃‍♂️All animations (~ 2.5k files) rigged to UE4 Mannequin, but project include real-time retargeting to UE5 Manny (compatible with Metahuman skeleton structure)

Size to download ~2.5GB zipped

⚠️ NOTE: AGLS is a highly complex and extensive framework. It includes many features that extend the default systems available in the engine. Working with it efficiently and making modifications requires substantial experience with Unreal Engine.

Full Project Demonstration Wideo (AGLS v1.4 version)

Packaged Project DEMO for Windows

Patch Notes from 1.2 to 1.7 (Patreon Posts)

The link to download the project files is at the end of the post content

Informations about animations:

Not all animations are included in the project. 

Animations such as Stealth Finishers or some other finishers come from the UE Marketplace. You don't need to own these animation packs to open the project in the editor. The main consequence of missing animations will simply be poorly looking sequences like attack or some interactions.

⚠️ Note: There have been significant changes regarding animations not included in the project. As of version v1.8, animations from the "Brutal Finishers - Hand and Knife" pack are no longer as essential, and MeleeCombat now uses only 6 animation assets during game from this pack. Despite this, the project still contains additional assets for these animation sequences, as they are planned to be used in future versions. For "Stealth Finishers - Knife and Hand" and "Ultimate Traversal Anims", the situation remains largely the same as in previous versions of the project.

Here’s a list of animation packs not included in the project (not all sequences from the packs are used in the project):

"Stealth Finishers - knife and hand" by RamsterZ

"Brutal Finishers - Hand and Knife" by RamsterZ

"Ultimate Traversal Anims" by RamsterZ

A full list of not included animations sequences used in the project

If you have the necessary additional components, the implementation into AGLS is very simple. You just need to export the required animation sequences to .FBX files. Then, assign the appropriate file names and reimport them into AGLS.

✅ Without these animations, the project will run normally.

🔷Main changes and information regarding version 1.9:

AGLS 1.9, compared to previous versions of the project, may not appear to introduce many new features or significantly expanded systems at first glance. From a gameplay perspective, the main addition is the Melee Combat system, which can now be used by both Enemy HumanAI and CompanionAI. However, I will describe that functionality a bit later, because I would first like to focus on what consumed an enormous amount of my time and turned out to be the most difficult challenge I have ever undertaken while working with Unreal Engine. I am referring primarily to designing a better Motion Matching solution for both the player character and HumansAI. As most of you probably know, Epic Games provides a sample project called the Game Animation Sample Project (GASP), which demonstrates how powerful animation systems based on the Pose Search plugin can be. In GASP, the entire locomotion system is implemented exceptionally well, and it is clear that a tremendous amount of time was invested in its development. Of course, AGLS is heavily inspired by the solutions used in GASP. However, despite multiple attempts to transfer the entire locomotion setup to the UE4 Mannequin skeleton, I was never able to achieve animation selection that was as precise, nor movement that felt as clean and polished.

For that reason, after implementing Melee Combat for HumanAI, I decided to take a much closer look at how Pose Search actually works. I spent roughly two weeks trying to improve the default locomotion system in my project. While I achieved some improvements, the results were never quite as good as I wanted.

It is important to note that the requirements of AGLS differ somewhat from those of GASP, even though the overall integration approach should remain similar.

It is also worth mentioning that the final movement system is intended to be driven entirely by the Motion Matching node, rather than by a combination of Blend Stack + State Machine + Chooser. The latter approach (which is also used extensively in GASP) can produce extremely high-quality locomotion and, in some situations, even smoother results than pure Motion Matching. However, it is also much more difficult to maintain and significantly more time-consuming to develop than a system based primarily on Pose Search Databases.

In the end, I decided to rebuild the entire movement system almost from scratch. To achieve this, I created two major C++ classes:

MovementParamsControlComponent ᶜ⁺⁺

AGLS_Player_AnimInstanceCore ᶜ⁺⁺

The first system/component was designed to provide better control over parameters related to the CharacterMovementComponent. Previously, AGLS handled this functionality in the same way as ALSv4, using a DataTable-based approach. Now, however, each movement preset is stored as a DataAsset, and these assets provide many additional configuration options:

MovementParamsControl_Player is a component attached to ALS_Base_CharacterBP that is primarily responsible for configuring values such as: CMC->MaxWalkSpeed, CMC->Acceleration, CMC->WalkingDeceleration or CMC->GroundFriction.

MPCP performs its updates before the CharacterMovementComponent (CMC) update. In addition, it exposes two important delegates that allow custom code to be executed before the CMC refresh takes place:

I believe that, in the long run, this solution will prove to be an improvement over the previous approach inherited from ALSv4. Below, I have also highlighted the main functions responsible for loading and applying a new Movement Preset.

Another, even more significant change is related to the AGLS_Player_AnimInstanceCore class. Starting with AGLS v1.9, the player character now uses an entirely new AnimInstance class. The new animation blueprint is AGLS_PlayerAnimBP, which is built on top of AGLS_Player_AnimInstanceCore. As a result, the ALS_AnimBP asset has been marked as deprecated as of v1.9, although it remains included in the project.

Completely rebuilding the animation logic was a major challenge, but I believe the effort will ultimately pay off and make the animation framework much more production-ready. I will not go into great detail about AGLS_PlayerAnimBP, as it is a fairly complex asset. However, I would like to highlight some of the most important changes worth noting. First and foremost, the majority of variables are now declared in C++, including the primary animation states, which are represented using Enums.

Note: Unreal allows you to display a list of variables from parent classes. To do this, select the 'Show Inherited Variables' option in the MyBlueprint tab.

This change is quite important when integrating Enum variables that were originally declared as engine assets. A large portion of Blueprint classes, including ALS_Base_CharacterBP, still operate on their primary state values besed on Blueprint Enum assets. For example, to retrieve the list of the most important character states, you would typically call the interface function: BPI_Player_CharacterCore->BPI_Get_CurrentStates() However, in AGLS_PlayerAnimBP, the variables representing these states are now declared as C++ Enums, which are not directly compatible with Blueprint Enum assets by default. However, to solve this, you need to apply a simple transformation to the appropriate type:

Classes related to HumanAI already operate exclusively on Enums declared in C++, so in that case a different interface function should be used to retrieve the state information.

I mention this because the previous ALS_AnimBP relied heavily on Blueprint Enums, whereas the new implementation no longer does. Motion Matching now retrieves PoseSearchDatabases from an entirely new Chooser called AGLS_Player_PoseSearchDatabases, and many systems and functions have also been rewritten in C++.

The new Motion Matching implementation is based on several custom solutions, including:

🟢 CustomTrajectoryGenerating ᶜ⁺⁺

⚠️ PoseSearchDatabasesCollectors ᶜ⁺⁺ (experimental)

I will start with the trajectory-related improvements. In this area, I managed to remove several limitations that normally affect Pose Search. The new trajectory function library addresses three major issues:

The requirement to rely exclusively on CharacterMovementComponent capsule rotation methods such as CMC->bOrientRotationToMovement.

Missing trajectory generation during Root Motion animations.

The fact that Trajectory History is normally 2D and does not capture movement along the Z axis.

For Pose Search to correctly select animations that involve root bone rotation changes, it typically requires the use of the default capsule rotation techniques provided by the CharacterMovementComponent. The biggest issues appeared in cases such as TurnInPlace or RefaceFromStart animations. In GASP, the SandboxCharacter_CMC class continuously orients the capsule toward ControlRotation.Yaw, even while the character is idle. If the RootOffset node were removed from the AnimInstance, the character mesh would rotate with every camera movement, even while standing still. As a result, the desynchronization between GetActorRotation() and GetRootRotation() could reach as much as 180 degrees. The Mover plugin largely eliminates this limitation, but I wanted to solve the problem while still using the CharacterMovementComponent. In the end, I believe I managed to do so. To achieve this, I created the 🔸PoseSearchGenerateTrajectory(Extended) function. It provides significantly more input parameters than the default implementation, allowing for much greater control over trajectory generation. Facing for each sample is calculated differently than the default, or more precisely, for each sample the theoretical time to the given orientation is taken into account, rather than simply copying ControlRotation.Yaw.

The second major improvement is that trajectories can now also be generated from Root Motion. This approach is currently used by HumansAI, where the inputs provided to GenerateTrajectory are the ∂Acceleration and ∂Velocity values calculated by the functions shown below:

Here is an example of Motion Matching in action, where the movement source is a Montage animation:

Another important feature related to Pose Search is an attempt to optimize the databases related to Pose Search databases. By default, every asset accessible to the Chooser responsible for selecting PoseSearchDatabases is referenced through Hard References. My goal was to reduce the number of animation databases that need to remain loaded at any given time. Some locomotion systems, such as Covering or certain movement modes like Jogging, are used relatively infrequently - or sometimes not at all during gameplay. For this reason, the Pose Search Chooser now returns database assets as Soft References. To support asynchronous asset loading, the PoseSearchDatabasesCollector ᶜ⁺⁺ and PoseSearchAllMovementsCollector ᶜ⁺⁺ classes were created, the purpose of which is to catalog PSDs in order to load the entire movement rather than individual PSD.

⚠️ Note: This is a highly experimental approach. The final optimization gains may not be worth the momentary FPS drops during loading. Async loading in a Packaged project is much more efficient than loading from the editor. If you want to avoid this approach, you should create HardReferences to the PSD somewhere in the scene, which will force the engine to constantly store them in memory.

The AGLS_AI_AnimBP class has also undergone major changes. Most notably, a large portion of the Blueprint logic has been replaced with C++. This may provide a modest improvement in animation processing performance. Earlier, I also mentioned the new trajectory-related functionality and the MovementParamsControlComponent ᶜ⁺⁺, both of which are now utilized by HumanAI. The PoseSearchDatabase assets used by HumanAI have been specifically prepared for this character class. Previously, both the player and AI shared the same databases and normalization assets. For v1.9, I decided to separate these systems, allowing the animation frameworks for the two different controller types to evolve independently.

The HumanAI Pose Search assets can be found in: MachingData->Human_AI:

In AGLS v1.9, I also introduced more aggressive LOD levels for the AnimInstance. For example, at LOD3, Pose Search uses a much more limited set of animation databases, which should reduce the amount of work required when searching for the best matching pose. The LOD behavior can be previewed using the console command:

AGLS.HumanAI.Optimization.ForceLodState

There are many more technical changes than the ones described here, but I believe I have covered the most important ones.

What do all of these changes improve?

Overall, the entire locomotion system should benefit from these improvements, including Crawling, Crouching, and the movement systems used by HumanAI. In addition, animation performance should also improve. That being said, it is important to acknowledge that the final animation quality and smoothness are still not quite on the same level as those found in the Game Animation Sample Project (GASP). Naturally, this raises the question: why? Unfortunately, I do not have a definitive answer. Most likely, I still do not fully understand Pose Search well enough to calibrate it with the same level of precision achieved by Epic Games. I also have the impression that the system performs exceptionally well when used with the UEFN skeleton, and that some of its strengths are difficult to reproduce on other skeletons. Pose Search requires well-chosen values ​​of many variables to work, e.g. the number of trajectory samples, their sampling time, data in Channels, etc. However, despite this, I think that overall I managed to prepare a pretty good animation system.

Crawling locomotion example:

HumanAI walking example (LOD0):

Other important changes included in AGLS v1.9:

➊ MeleeCombatComponent implementation for HumanAI and CompanionAI.

Starting with this version, the AI ​​can also engage in melee combat if environmental conditions allow. The default input bindings for the player, when using a keyboard, are:

Melee Attack = key 'V'

Melee Dodge = key 'C'

The default inputs map for a gamepad is as follows:

Example of a 1 vs. 3 combat scenario. In this case, the HumansAI characters do not have any firearms equipped, causing their controllers to attempt to engage the target using the Melee Combat system.

HumanAI ma też możliwość upuszczania oraz podnoszenia broni podczas walki.

Example 2 (Player with CompanionAI) vs 3 fight:

List of smaller changes:

Fixed a bug where a TraversalAction could be interrupted incorrectly when entering Ragdoll.

Improved Dynamic Foot Transitions and Additive Foot Transitions when changing the Overlay State or when the player starts aiming.

Added EarlyStoppingMontage support for interactions such as PickNewRifle and PickNewPistol. This allows interactions to end more quickly when the player provides movement input.

Replaced most animation curves that used EnableFootIK with DisableFootIK. Before the Motion Matching update, the system relied on the EnableFootIK curve, but this occasionally caused blending issues when the "Enable" and "Disable" states overlapped.

Fixed a crash in packaged builds caused by UseRawData when attempting to retrieve bone transforms directly from animations. In packaged builds, access to raw animation data is restricted because animations are stored in a compressed format.

Fixed an issue in packaged builds where interactions could fail if the required asset had not yet been loaded into memory. For example, when attempting to pick up a weapon, pressing 'E' would not activate the initial interaction on the first attempt, requiring the player to press the key twice. As of v1.9, this bug should no longer occur.

██████▶ 𝐀𝐆𝐋𝐒 ᴠ1.9.1 𝐂𝐇𝐀𝐍𝐆𝐄𝐒 ◀██████

Update v1.9.1 was mainly focused on fixing many bugs related to the new Pose Search setup for both the player and AI. This version also includes many other fixes, with the main changes being as follows:

Motion Matching for the player has undergone many major changes:

The BlendStack logic has been updated, with many values in the Steering and Orientation Warping nodes being changed. An additional Stride Warping node [Experimental] has also been added inside the Motion Matching node. Its purpose is to correct foot placement when the animation speed differs significantly from the capsule speed, for example due to collision. Overall, I feel that the new parameters are better tuned to the animations.

The Movement Analysis functions have also been changed, including values such as FacingDelta and IsCircing.

Many PoseSearchDatabase assets have been rebuilt, with major changes applied to the databases in the Spins category, which should improve their matching.

For MovementParamsControl_Player, I have taken Root Motion animations into account, which should improve pose matching after a Montage animation ends

I expanded several PoseSearchDatabases with additional animations, including, for example, RelaxedRun_Diamonds

The PoseSearchSchema assets have undergone many changes. The key one, however, is AGLS_PSS_Loops, which previously did not index Facing and took capsule speed differences relative to the animation into account to a lesser extent

The “AGLS_Player_PoseSearchDatabases” Chooser itself has also been rebuilt

Fixed a bug related to jumping down from ledges while Crouching. Previously, landing animations were not selected in this case. The issue was caused by DatabaseConstBias and ContinuingPoseBias values being too high

Fixed Pose Search related to TurnInPlace animations. Previously, Steering remained active for too long in relation to the Turn animation, which caused the root bone to slide when the animation was already indicating an idle pose

Added TurnInPlace animations for the Crouching state

Removed the code controlling ActorRotation() from PredictableJumpAction during Montage playback, which means calling LockUpdatingRotation() is no longer necessary. Rotation correction is handled through Motion Warping

RollAction has been significantly rebuilt. A proper Chooser has been added to select the Animation Montage, and Motion Warping has also been implemented to correct the Root Motion trajectory

Added an additional actor, “AGLS_PoseSearchRebuilderForCharacters”, which allows all PoseSearchDatabases for both the player and HumanAI to be fully loaded at once. After the assets are loaded, indexed poses are also rebuilt when necessary. This process may usually be required after making changes to the skeleton or to animations indexed by Pose Search

Added interpolation for the SpineRotation value for both the player and HumanAI when AimingRotation is no longer active. Without this change, an issue occurred during the transition from -90 to 90

pine Aiming control nodes have been reduced to only 3 spine bones. Previously, the Pelvis was also rotated, which I considered unnecessary

Disabled the ability to perform a Melee Attack/Dodge when the player is not in MovementState = Grounded

As with Motion Matching for the player, the “AGLS_AI_AnimBP” class and other assets related to it have undergone some changes aimed at generally improving Pose Search behavior

Fixed an issue related to HumanAI Fall Damage. Previously, after critical fall damage when HealthPoints = 0, the HumanAI death code was not executed. This should now work correctly

For CompanionAI, the code controlling the FocusActor position has been fixed. Previously, at a certain distance between the AI and the player, the BT_Service set an incorrect FocusActor position

Fixed the following error: LogScript: Warning: Script Msg: Attempted to access index -1 from array “NormalizedScales” of length 7 in “UI_WheeledOverlaysMenu.UI_WheeledOverlaysMenu_C”! LogScript: Warning: Script Msg called by: UI_WheeledOverlaysMenu_C

Added many additional descriptions for Blueprint assets

██████▶ 𝐀𝐆𝐋𝐒 ᴠ1.9.2 𝐂𝐇𝐀𝐍𝐆𝐄𝐒 ◀██████

🧩 AGLS v1.9.2 is the result of my continued work on learning and improving the Pose Search system. I still wasn't satisfied with how it performed in AGLS, so I decided to carry out a third full iteration of the Motion Matching implementation.

In the end, I decided to rely more heavily on a single primary Pose Search Channel instead of creating multiple channels based on different animation database types. I also merged several Pose Search Databases into a single main database, adjusted the Steering parameters, and updated parts of the Movement Analysis logic, including functions such as IsPivoting() and ShouldSpinTransition().

🟩 Overall, v1.9.2 introduces significant improvements to the core locomotion system for both the player character and HumanAI. This version also adds Gait Transition animations, such as Walk-to-Run and Run-to-Walk.

I hope this will be the last such thorough overhaul of Pose Search in the project.😤

Other major changes in v1.9.2:

Improved Ragdoll system, including a fix for the bug that occurred when entering Ragdoll while Crawling. Added a Play Rate parameter for Fall animation, as well as rotation interpolation while Ragdoll is active, improving the stability of Physics Constraints for attached equipment such as rifles and pistols.

Improved the Sliding System by increasing friction.

Fixed the HumansAI PatrolingInteractions system. Previously, the configured range of PathPoint indices used for searching Smart Objects was being ignored.

Changed the basis for calculating Aiming Rotation, including Spine Rotation. Previously, DeltaRotation was calculated relative to the Root Transform. It is now calculated relative to the Character Transform, which should resolve the issue of aiming overshooting while the character is moving.

▶ DOWNLOAD PROJECT FILES (v1.9.2, UE5.7) ◀

DOWNLOAD PROJECT FILES (v1.9.1, UE5.7)

DOWNLOAD PROJECT FILES (v1.9.0, UE5.7, No Replication)

▶️ AGLS Tutorials Playlist ◀️

I would also like to mention an important point to keep in mind when extracting the project files. Normally, little attention is paid to the folder in which a project is stored. However, asset paths are subject to length limitations. AGLS contains a large number of subfolders and assets with relatively long names. As a result, storing the project in a directory with a very long path may cause issues during packaging. For example, in my case, the project files are stored in the ':\Unreal Projects\UE5.7' directory. If it were something like ':\Epic Games\Unreal Engine 5.7\Projects\AdventureGameLocomotionSystem\', you might get an error message about the asset path exceeding the maximum number of characters.

Unreal Engine 5.8 Addtive Required Content ⚠️

Download Plugins Files for UE5.8 (Experimental)

Currently, for UE5.8, AGLS does not support the use of HumansAI, and the packaging process will fail. You can find more information on this topic in this post (link).

Can it be used for commercial purposes?Yes, but there are certain limitations. Most importantly, distributing project files (in the same way I provide them) is strictly prohibited. For commercial purposes, distribution should only be in the form of a packaged project (preferably in shipping configuration). This means that publication should be done in a format that does not allow easy extraction of AGLS project content. In short, the permitted format would be a compiled program, such as a .exe file for Windows.

It is worth reading the full license of use. You can find it at the link (PDF) or in the attachments under the post.

📄 it is worth taking a look at the documents in the attachments 📄

Information about project packaging.In this version of the project, I left a few folders related to the packaging process I performed on my own computer — these include the 'Binaries' and 'Intermediate' directories for project and plugins folders. If any errors occur during packaging, it’s worth considering completely deleting these directories from the project files. Additionally, in such cases, it’s recommended to use the 'Full Rebuild' option.

Some important Discord threads:

Aiming looking wreid for Rifle overlay

IWALS Documentation (created by Minty and Anarky)

I would also like to mention a small request. Namely, it is about private messages sent on Patreon. I would ask that this method of communication be limited, due to its large constraints. If your question is about the project, please send it on the Discord server, or in the comments under the Patreon post. In other cases, I would suggest an email or possibly via a Patreon mailbox. Please note that due to the large number of messages, I am unable to reply to all of them. Most often I answer questions asked on the Discord server, followed by emails, comments under the Patreon post, and Patreon private messages. Thank you for your understanding.