Do you have a reason for needing to separate these movement modes into separate sub-classes? Unless you’re creating a modular movement mode system, in which you want to be able to add movement mode components onto different characters (ie. Add on a
FlyingMovementComponent to allow a character to fly). I think you’re making more work for yourself.
If you’re just building a single character movement then you’re better of containing those movement modes inside a class derived from
CharacterMovementComponent and overriding the
CustomMovementMode in that. It’s not really messy since you still separate it out into independent functions (ie.
However if you really do want to use separate
MovementComponents for different MovementModes then you need to override the
CharacterMovement component in the
The default character movement component is created in
ACharacter on line.85 as such:
CharacterMovement = CreateDefaultSubobject<UCharacterMovementComponent>(ACharacter::CharacterMovementComponentName);
so I would suggest creating multiple default subobjects and then switching out the
CharacterMovement variable based on user input.
HOWEVER this will get really complicated really fast, so please please do think about whether you really need to go to this level of division in your movement modes, as for most use-cases this is definitely overkill.
An alternative solution if you still want to separate movement modes into sub-classes, would be to use a single
CharacterMovementComponent and create default subobjects from there, and then switch between the active
MovementModeComponent within your
CharacterMovementComponent which would be like a hybrid version of the
CharacterMovementComponent while using your subclasses.
However, even this is overkill if it’s a single character behaviour you’re making, and not some complex modular or procedural character generation system. So please consider the initial decision of simply overriding the
CharacterMovementComponent and overriding the functions there for things like
Hope this helps,