Hi. Thank you for such a comprehensive message. You clearly have a great deal of knowledge in this area, and I really admire that. I'll try to respond to the points and information you shared. As you pointed out, the UE4 skeleton itself may indeed be the root of the problem. I spent an incredibly long time working on Motion Matching, and in the end I came to the conclusion that both the smoothness and the overall quality of Motion Matching are heavily tied to a specific skeleton. After reading your message, I'm even more convinced that this is actually the case, and trying to work around it would probably be dump. That said, I think this is a significant limitation of the Motion Matching approach. Depending on a specific skeleton is not, in my opinion, the direction Epic Games should be taking. Not everyone wants to use Epic's bone hierarchy or even their particular Skeletal Mesh assets. From a technical standpoint, I still don't fully understand why this limitation exists. For example, if I were to retarget the entire GASP project to a different bone hierarchy, would that automatically result in poorer Pose Search quality? And what about developers who want to use Motion Matching for characters that don't even have a humanoid body structure, such as monsters? I completely understand the benefits of tighter integration between Pose Search and Mover. However, AGLS has to remain based on CharacterMovementComponent because the project has simply grown too large and complex to migrate to a different movement framework. I'm fully aware that it isn't realistic to keep building on a skeleton that dates back to the very first UE4 releases. That mannequin has a rather caricature-like bone structure by today's standards. At this point, I think AGLS 2.0 will probably be the final version of the project. My plan is to start something completely new from scratch, built around more modern technologies, including GASP. Now that I have much more experience, I may be able to carry over some parts of AGLS while rebuilding others entirely. I might even choose a completely different type of gameplay - not necessarily a shooter, but perhaps something in a different genre. It's still too early to say, but I do feel that significant changes are necessary. As for Unreal Engine 6, I'm not particularly concerned about it yet. What interests me the most in future engine versions is the development of the Unreal Animation Framework (UAF). I believe that's something Unreal Engine has needed for a long time, since the current Animation Blueprint system feels quite outdated. By the time UE6 arrives, it's also possible that AI will be able to accomplish in a few minutes tasks that currently take me months to complete. AI development is progressing rapidly, and it's becoming increasingly difficult to predict where it will ultimately lead. Epic Games also seems to be moving strongly in that direction. What the final outcome will be remains to be seen. Once again, thank you for taking the time to write such a thoughtful message. Best regards.

Hi. I’m not currently planning to integrate Mover instead of CMC. Although it offers some interesting features, it requires a lot of manual configuration and is highly experimental. As for whether I plan to add something like Wall Running, I don’t have any plans for that at the moment. I’m still focused on improving the core movement, such as walking, crouching, covering, and so on.

Hi. That’s true. Unfortunately, in my case, it doesn’t change much. GASPALS is still based directly on the GASP project — mainly by using the ready-made Motion Matching setup for the UEFN skeleton. I have to implement this from scratch, while of course using the GASP animations after retargeting and applying a similar approach to Pose Search handling. However, I have the impression that even if everything matched 100% — meaning the entire character and Anim Instance used the exact same code — the result would still be different. Unfortunately, I don’t understand why it works so well on the UEFN skeleton, while with the UE4 skeleton there are noticeably more inaccuracies. Motion Matching in general is difficult to control because of the amount of data and the number of possible configuration parameters. In my case, I also have to rely on custom solutions, such as generating trajectories myself. I’ve tried many different configurations and a lot of Pose Search tuning, but at the moment the result is still not as smooth. I’m not comparing BlendStack to the Motion Matching node here — only Motion Matching itself. That said, I think what I’ve managed to achieve so far is significantly better than the previous movement system in AGLS, although finishing the whole thing will still take me some time.

Hi, Thanks for the information. The ALS integration with GASP is available for download, but in my case, that is not the source of the problem. The issue is that I have the impression Motion Matching only works properly with the UEFN skeleton. I don’t know if anyone has tried implementing PoseSearch from scratch for a different skeleton and achieved the same smoothness as in GASP. I have to implement it from scratch, while of course using the GASP animations after retargeting and applying a similar approach to Pose Search. However, I feel that even if everything matched 100% — meaning the whole character and Anim Instance used the exact same code — the result would still be different. Unfortunately, I don’t understand why it works so well with UEFN, while with the UE4 skeleton there are noticeably more inaccuracies. Motion Matching is generally difficult to control because of the amount of data and the number of possible configuration parameters. In my case, I also need to rely on custom solutions, such as generating trajectories myself. I’ve tried many different configurations and Pose Search tuning, but at the moment the result is still not as smooth. I’m not comparing BlendStack to the Motion Matching node here — only Motion Matching itself. Still, I think what I’ve achieved so far is significantly better than the previous movement system in AGLS, although finishing everything will still take me some time. You mentioned a few interesting plugins, such as GAS Companion and Gameplay Blueprint Attributes. The first one does indeed offer some interesting possibilities — I wasn’t aware of it before — but integrating it into AGLS right now would be too complex. AGLS is currently a heavily C++-based project, with its own custom assets and systems extending the engine’s default tools, such as AbilitySystem, GameplayTasks, and EQS. Attributes would make the code cleaner for values such as HealthPoints — AGLS currently handles this mostly through a Blueprint interface. I implemented the AbilitySystem back when it was still heavily limited by the engine, since that was during the UE4 period. Later, I stayed with this approach because of the project’s already expanded structure. Even so, I try to maintain some kind of organized code structure. I often use components for specific systems, avoid direct references to Blueprint classes, implement interactions as AbilityBlueprints, store them as SoftReferences, and so on. I agree that a lot of code could definitely be cleaned up, but AGLS is still a project through which I’m learning Unreal Engine. As for Gameplay Blueprint Attributes, I wouldn’t be able to use it because it is paid content and also seems quite complex to me.

I’ll try to do something about it. However, in the context of AI, there are many potential optimization-related areas to consider. Above all, there are many different methods and tricks specifically related to AI optimization. Let’s start with the character class itself. Here, for example, the CharacterMovementComponent and TickEvent can be quite heavy. CMC updates the simulation based on physics equations and also uses optimization-related values such as SubStepTime, MaxSimulationTimeStep, and MaxSimIterations. For characters that are far away from the player, it may be worth considering changing these values. Next, there is TickEvent, whose DeltaTime could also be modified. MeshComponent also allows its DeltaTime to be changed. If the mesh dt = 1/60, then the Anim Graph update will be around 60 FPS. For higher LODs, this could be reduced to 30 FPS or even 15 FPS. You can also adjust Bounds, Render Static, and many other parameters. Optimization of PoseSearchDatabases is another topic. In theory, if fewer animations are provided, finding the pose should be faster. I’m currently considering creating separate PS_Databases for AI, along with separate normalization. This should have some impact on PoseSearch performance. With a larger number of AI instances, optimization techniques such as Animation Budget Allocator are also used. Another very important aspect is the AI controller itself. I didn’t design it for a large number of instances, although I think I used some interesting optimization techniques there, such as Custom Tick Delegates. And of course, the most important topic is Blueprint vs C++. If the entire controller were implemented in C++, the result would be much more efficient. Finished Blueprint code is often rewritten into C++ because that code is processed much faster. Overall, I’ll try to improve something, but I can’t promise that these changes will significantly affect performance. I’ll also mention that the AnimInstance class (Animation Blueprint) is generally not very well optimized. The engine developers are aware of this, which is why they are developing a completely new animation system — UAF (Unreal Animation Framework). It is a completely different tool, but currently it is not suitable for production. I think it is being developed due to The Witcher 4, and it will probably be released sometime around UE6.0.