Hi everyone. In this post, I would like to share some information regarding the new version of the AGLS project.
I am still actively working on the update and have also made several decisions that significantly change the project’s existing structure.
Version v1.9 adds the ability for both HumansAI and CompanionAI to use Melee Combat. This is the main focus of the new release, although there are also several important changes related to the player character itself.
One of these changes was the creation of a new AnimInstance class. Up until now, since the very beginning of AGLS, this role was handled by ALS_AnimBP. Currently, I am rebuilding the animation logic from scratch as a new asset called AGLS_PlayerAnimBP, designed with a much stronger focus on a C++ driven architecture (Mainly for declarating variables and functions).
The main reason for this decision was that the current Motion Matching implementation was still far from ideal when compared to the GASP project. Unfortunately, I spent around two weeks trying to understand and match the quality of GASP, without fully understanding why it works so well with the UEFN character while producing noticeably more inaccuracies on other skeletons. Initially, I thought improving this would only take a few days At the moment, the movement feel should already be better, although it still should not be compared directly to GASP, even when using the exact same animations.
It is also worth mentioning that LongmireLocomotion did an incredible job combining Mover + Chooser + BlendStack + State Machine. This combination creates nearly perfect movement, but it is also extremely complex. Even using the Motion Matching node alone already produces excellent results, but manually feeding animations into BlendStack can sometimes generate even better outcomes, despite being highly experimental.
From a technical perspective, migrating the AGLS project fully to Mover is far too complicated because of the project’s extensive underlying code structure. Because of that, I tried to work around these limitations.
For this purpose, I created a new C++ component responsible for controlling CharacterMovementComponent values. Previously, the system worked similarly to ALSv4, where a single DataTable stored all movement parameters for the capsule movement logic. The new system functions in a similar way, but instead of using one DataTable, it now relies on DataAssets containing the required values.
I also created an additional function library related to trajectory generation. The extended functions make it possible to generate trajectories directly from Root Motion animations. This means that, for example, when a Montage animation with Root Motion is played, the animation itself takes control over capsule movement. Normally, no trajectory would be generated in such a case, causing Motion Matching to play idle animations despite actual movement happening. These additional functions partially solve this issue, allowing leg movement from PoseSearch to blend correctly with Montage animations.
To summarize — unfortunately, I lost a significant amount of time working on Motion Matching, and at this point I still cannot say whether I will remain with ALS_AnimBP or fully complete the new solution It may be somewhat disappointing that AGLS v1.9 will not introduce a huge number of entirely new gameplay mechanics, but considering the deeper technical changes, the update is still quite substantial.
UPDATE 28.05
The new AnimInstance for the player controller is now practically complete. I still need to test everything as a whole. I think the final result should be significantly better, and the code should be more readable :)
However, I still need to make major changes to the animation structure for Human AI. With the tools already prepared, this should take no more than a few days. I will also try to improve PoseSearch-related performance in the context of AI.
I have also implemented an additional system intended to reduce the number of active PoseSearchDatabases kept in memory. Systems such as Covering, Stairs Walk, or Crawling are usually used less frequently during gameplay. For this reason, their databases are stored as Soft References in the Chooser.
The appropriate DataAssets store and organize which PSDs correspond to the current movement mode. When the databases become relevant, they are loaded asynchronously.
This solution is highly experimental and may ultimately not be very effective for very large animation databases, because their loading time could noticeably affect FPS for a short moment. However, it is worth remembering that the Async Load algorithm is significantly more efficient in a packaged build.
When can you expect the new update files?
It’s difficult for me to say precisely, as the project is still quite messy and many changes are unfinished. I’d like to complete everything sometime between May 30th and 31th.