Mover 2.0 upgrade path

Development Programming & Scripting
, ,
1

Hello!

I was hoping to get a sense of Epics expectations for an upgrade path for games in development hoping to take advantage of Mover 2.0.

The GASP update builds the new “character” directly off of Pawn, and not character. There is a decent amount of engine code that tries to cast the pawn to a Character or operates directly off it. I understand why you’d want to drop the character entirely, but this does seem like a relatively large undertaking for game teams to switch to rely solely on Pawn.

Is it possible/recommended to simply add a mover 2.0 to a character and disable the CMC? Ideally we’d be able to swap the components without changing the base class. The assumptions around capsule and mesh components are still valid for us.

I could be overestimating the amount of places that assume CMC/Character in the engine. In practice for other studios has GAS and other systems worked well when building from Pawn instead, or would the expectation be override/adjust things like FAnimNode_SlopeWarping::SetWorldSpaceTargetFloorInfoFromMovementComponent to work from Pawns.

Is there a significant gain to not only abandoning CMC but also Character?

2

Just testing this out, and it does seem fine to disable tick/put the CMC in movement mode none and then just add the mover component. Just want to check if there are any gotchyas in doing so.

This has the added benefit that we can simply fill in data such as CurrentFloor and velocity for the CMC and do a gradual refactor.

3

Hi there,

The Character movement component and ACharacter were introduced together and were created specifically for bipedal movement using a character, with a capsule component and skeletal mesh, and contained its own network prediction and correction code that only itself was aware of.

A downside of this is that systems like the Gameplay Ability System (GAS), for example, had no knowledge of any rollbacks or position changes from the server, of the character that may have affected the outcome or even activation of an ability.

The new Mover 2.0 is designed to be more generalised in its use, used by any Actor, not just Characters or even Pawns. For example, you could create a moving platform that players can stand on, and have network-predicted movement.

Because of this, the Character class would no longer be required.

Mover 2.0 is still Experimental, and the interface and code may change between engine releases; caution should be used if shipping with it.

There are a few Gameplay abilities, like Character Jump, that may need to be replaced with one that uses the FCharacterDefaultInputs Mover Data struct instead of manipulating the movement component.

And as you have mentioned, a few anim nodes may need a custom replacement created. Most are to do with the root motion source, which are similar to layered moves in Mover.

In other places in the codebase, it does not solely rely on it being a character, but has a different code path if it is.

As for disabling the tick, I am unsure of any gotchas when attempting to blend the two, im not aware of anyone attempting this, and moving data between the two.

Velocity, you should be able to get from the actor itself without getting it from the CMC, and the current floor is used by some anim nodes around feet placement and slope walking, you could use control rig and/or the new Locomotor plugin (Also Experimental) instead, which supports multi-feet placement Procedural Animation with a Locomotor | Tutorial and looks really good, with some out of the box hip displacement aswell, it is mostly a black box, and has a lot of variables that can and be tweaked, but with sometime you can get a really good effect.

GAS can also be used by any actor, it does not need to be associated with a character or even a pawn (you can even have a global ability system)

If your character still makes use of a capsule and skeletal mesh, it wouldn’t be difficult to create your own character mover class that would add these components and functionality.

As Character does not provide much more functionality beyond adding the CMC, depending on your needs, the motivations of moving to Mover 2.0, and timeline etc, you might be better off staying with CMC, as it is battle-tested. If your project is some way off, you could consider refactoring to have a clean codebase, based on pawn and mover, but again, Mover is experimental, and you may have to write some of your own glue code between other systems, which may then be deprecated by newer releases.

As for what an intended upgrade path might look like in the future, as at this stage, Mover is still experimental, and I don’t believe there is a scheduled release date as yet for it to move out of experimental, I would need to refer that to the Epic team to comment on any plans they have, if you wish.

Let me know if I can be of any further assistance, or if you’d like me to escalate to a subject matter expert/epic around any timelines or upgrade paths that may or may not be known as yet.

Kind Regards

Keegan Gibson

4

To chip in with some additional info, we had some success bridging an ACharacter with a MoverComponent. This was our approach with UEFN’s physics-based character. It allows all the cosmetic customization of Fortnite’s Player Character system, with the movement done using Mover and physics. Movement mechanics were where things diverged and the team has been standing them up over time (FN has a lot of them!). We started with basic walk/run/sprint/jump and have been tuned them to be as similar as possible.

There is a specialized CMC_WithMover class to stand in for CMC. So any existing systems that use CMC’s API will talk to this class instead, and it will either translate queries to the MoverComponent or refer to some cached state that was based on MoverComponent’s data. Then we have a pre-movement function where we reflect CMC state + input -> Mover state. And a post-movement function where we reflect Mover state back to CMC.

Looking forward, we also plan to spend more time on the Character-focused MoverComponent variant to make it easier to convert from CMC, as well as minimizing effort needed to stand up a classic upright biped from scratch.

As for progressing to Beta status, a couple of areas come to mind before that can occur. We have a rework in progress that will be a breaking API change for layered moves, modifiers, etc. This is to better support Mover’s goals of multi-threaded simulation, prediction, moving things that may not be actors, and BP-extendible mechanics. For multiplayer, some of the networking also needs to be hardened to handle varying network conditions better and scaling to larger entity counts.

5

It would be nice to get a sense of how close they feel mover is for a single player game to be able to use.

Additionally, how far off is the async movement modes. Specifically for non-player NPCs such as crowd characters.

6

As mover is such a large change it be good to know what’s holding it back for beta/production.

Is it network prediction and rollback?

Is it the new physics based movement modes?

Is it the Async movement doesn’t work?

Is it the base features aren’t stable/performant even in standalone?

7

In my experience, Mover has been really easy to use thus far, using the legacy movement mode, but that was starting from a new project vs migrating from an existing one.

But there have been changes between versions of Unreal that required adjusting some code and fixing the odd bug. Atleast in 5.6 the chaos and physics backends where definitly in a state of flux, as the artchitecture was changing.

I’ll refer you to a subject matter expert who will be able to give you more context as to its status.

8

Thanks for the context. The big concern with not adopting it early is accumulating tech debt that makes the transition too costly later.

Those all sound reasonable, and we can take a bit of a hit with refactoring as you update the releases. We’ll start with the UEFN approach and pipe the data back and forth as our interim solution.

The multi-threaded sim would be a huge win as CMC is always a large chunk of the frame. Ideally we can switch between walking and async nav walking for distant characters.