Since the Mover plugin went experimental in Unreal 5.4, I wanted to start developing with it and see what are the capabilities of it. Unfortunately for me, examples are in C++ and Blueprint support is limited.
I didn’t let that discourage me though, so I started developing custom movement modes with Blueprints, trying to recreate the setup from their C++ examples.
What is Mover 2.0?
Mover 2.0 is Epic’s new solution to character movement. The idea is to have more customizable, flexible and smoothly networked character movement solution.
It seems cool and the actual structure is interesting, but it is definitely harder to work with than Character Movement Component(CMC).
In Mover you have to manage stuff tick by tick. That means: character location, orientation, velocity, direction, Intent Vectors,… Not only do you have to decide what you want the character to do next tick, you also have to take into count what the character was doing previous tick: location, rotation, previous velocity,…
I suspect that there will be a long period of time where Mover will only be used by people that want to go deep into it and others will stick to CMC.
For it to become more user friendly and mainstream, it will have to have abundance of movement modes, mostly Blueprints, that also have only few bigger functions that consolidate functionality and “hide” a lot of underlying complexity.
CAUTION: Random thoughts
There might be market for selling different movement modes, so people that don’t want to bother with creating them from scratch can reuse them.
The only issue I can see are shared settings. In Mover you can have one object that has data, that can be shared between different movement modes. If different sellers decide on their own custom shared settings object, that would mean that buyers will only be able to use movement modes from that seller, basically getting locked in (Unless they go through the process of combining/replacing shared settings in different movement modes).
Mover + Blueprints?
Why not? We get to develop them way faster for the price of some performance.
Ok,… “some” is doing a lot of heavy lifting there. I haven’t tested performance of Mover in blueprints yet, but Mover is pretty granular, meaning there is a lot of small pieces that need to be put together to execute a single tick. Blueprints do not deal well with a lot of small nodes that execute frequently. That is why when I was translating movement modes from C++ to Blueprints, I tried to remove any unnecessary nodes.
Right now I think the Blueprint solution will be usable, even if you have dozen characters on screen, but I would love to test having way more, to see when it breaks.
What will help a lot is developers of Mover starting to focus more on Blueprints and expose some more performant functions that we can use. If I had to guess, this will happen soon-ish, since making it C++ only will probably make it go under most peoples radars.
The biggest issue here are release cycles. I don’t expect anything to come to Mover in smaller updates, so we will have to wait for new UE version releases that come every half a year or so.
Structure of Mover
Mover consists of few important primary elements and few secondary, more situational elements. First we have Movement Modes.
Movement mode(BaseMovementMode) is an object that is continually ticking on the Mover component and calculating current character movement related data(Transform, velocity,…). This is where all of your logic for movement will be. It has OnGenerateMove and OnSimulationTick functions. First one takes general information like MoveInput and OrientationIntent and processes it to populate ProposedMove struct. This struct is then passed to OnSimulationTick function, where the actual movement is performed.
You can have multiple movement modes and switch between them in the OnSimulationTick, if you detect a condition that another movement mode should handle. For example, if you are inside walking mode and detect that you should go into falling mode.
Next we have Shared Settings.
Shared settings class is a way for mover to easily share data between movement modes. For example, you probably want all of movement modes to know about Max Speed or Turning Rate of the character.
Transitions are another thing that you might want at some point, but I haven’t try them at this point. They seem to be rules on how a movement mode should transition to another mode. You can do it instantly or over time. You can have transition for each movement mode or global transition and the first one that is available will be triggered.
If you want to contribute or just check out the project, I published it on github: https://github.com/VenturousStudios/BlueprintMover