Easily extensible Movement

Hey there. I struggle heavily when it comes to modular/extensible movement/input/animation.

The Implementation for different Movement Modes is not uniformly implemented. For example Walking uses the Velocity for the Blendspace in the AnimBP,
Climbing at a wall uses the Input directly in the AnimBP (by getting the inputvalue in a transition rule).
Climbing ontop of Obstacles uses AnimMontages.
What I want is a uniformly designed, easily extensible pattern for movement, Input and Animation.

First, I thought of a class “CustomMovement” that encapsulates the “Phys()” function we know from Phys() within the CharacterMovementComponent.
As soon as I have the movementmode set to “custom”, the Phys() function will delegate to this class/object’s Phys() function.
This allows encapsulation through inheritance/interface where Phys() can be implemented for different movement modes.

However, the Animation cannot be encapsulated that easily, You can’t exchange the Anim Instance of a Skeletal Mesh with smooth Transitions. The Input cannot be accessed in UObject classes either which makes this design pretty useless. If I could delegate the Input to these objects, that would be great. I could have different Input Behaviour for Walking, Swimming and Climbing without storing everything in the character class.

Do you have an idea how to get an easily extensible/modular/clean base for advanced movement modes?
Climbing, Rope Swinging, Balancing etc are movement modes I want to implement.

IDK if this is what you’re looking for, or even if this is the best way of doing it, but my current movement system in executed via Enumerators
Downside> The Enum Nodes are so big it can make things look cluttered, and you always need to call a custom event once you’ve set it

Here’s a screenshot I posted of a basic system in another thread

Hope this helps :wink:

Hey there. Thanks for the answer, but my question is targeted at the design to communicate between Input, Animation and Movement that has an uniform design and can be extended easily.

I’m actually working on a root motion charactrer controller. I was asking myself the same question and decided to move as much logic away from the anim bp as possible. my basic concept is that you would have different “motions”, for example idle, walk/run, jump, fall, climb, scale wall, slide, etc.

Basically each motion has a base class that comes with the following pattern: InitializeMotion(), TestActivateMotion(), ActivateMotion(), TestUpdateMotion(), UpdateMotion(), DeactivateMotion(). The Motion base class also gets some basic information that could be relevant to all motions such as input, current grounding status of character, slope angle, sorrounding awareness (like edge detection etc.). It also contains a reference to things like character capsule, character mesh, etc.

I have a motion controller class, that on start of the game initializes all available motions. Each frame I run TestActivateto check if another motion should run, if so i deactivate the current motion and activate the new one. If no other motion should run I test if the current motion should continue. If not, I deactivate it, if it should continue, I update it.

Taking the concept further you can break down each motion into motion phases, for example a jump typically consists of start, rise, apex, fall and land. So in my motion update I would check for the current phase of the motion.

This allows me to have a lot of logic in self-contained units aka motions. I pass the current motion, the previous motion and the motion phase of the current motion as enums to my anim BP and work with states and blendtrees from there.

It’s like a super basic overview, if you wanna know more, feel free to text me.

^This sounds absolutely interesting. How do you integrate it into the CharacterBP?