Regarding implementing a custom movement mode for Character that uses regular physics functionality

Development Programming & Scripting C++
1

So I am looking to implement a form of flight that relies almost entirely on physics. Moving forward done by applying forces, staying in the air by applying a constant upwards force and so on.
Looking through the docs and the code the alternatives I have found that I have for implementing these include:

  1. Subclassing UCharacterMovementComponent and defining a custom movement mode that enables physics events for the character’s various components. (Which means trying to understand how UCharacterMovementComponent movement is supposed to be used and implementing this as a custom movement mode that conforms with how all its movement modes are handled.)
  2. Subclassing UCharacterMovementComponent and overriding its TickComponent function with one that handles my movement mode in whatever way I wish (in which case I will probably set this up to work in a way that is not at all bound to how the class normally handles movement.
  3. Replacing the UCharacterMovementComponent entirely in my code and building my own movement mechanism, possibly with a component or possibly by just putting it in my Character class.
  4. Making my own Character class and setting it all up in whatever way I want.

Option 1 means I should be able to keep most of the nice functionality implemented by the Character and character movement component classes (networking, navmeshes, all that stuff) but I’m unsure if I will have to spend a bunch of time struggling with making it work the way I need it to.
Option 2 seems like it should mean I could in the future integrate all that nice functionality back into it, but I would be cutting much of it out simply by overriding the tick function for myself. But then it seems like I should be able to integrate things like networking later instead of having to reimplement them.
Option 3 means I have to reimplement anything I want that the movement component has implemented (this isn’t terrible really - my game is not intended to be networked and if it is going to be then I don’t mind setting that up myself.)
Option 4 means losing anything that character also implements but having full control to add just the things I know, want and understand.

It kinda feels like Option 4 is the one that is going to get me to having my character functioning and doing what I want the fastest, Option 3 might be similarly good for that. Option 1 and 2 both feel like they’re going to have me spending a lot of time understanding and struggling with things that I don’t necessarily need in my game.

So for clarification: I am not asking how to implement the movement itself, just for advice on what would be the best approach to injecting my own logic into the already existing set of classes. Or if I should, as in options 3 and 4, just disregard it and make my own Pawn class.) Are there any best practices for this? Does anyone have experience with the various options? I’m just hoping someone might have something that might help me decide which way to go. I’m going to be trying at least one or two of them right away, but I’m hoping someone might have some useful advice that can set me on my way :slight_smile:

2

The character movement component isn’t designed to be used for physics-driven characters, so it won’t help you with potential networking or anything else really. So I’d go with 4 - in fact if your character model isn’t a skeletal mesh you could even abandon Character altogether and just subclass Pawn, since all a Character is is a Pawn with a skeletal mesh, capsule collision and a character movement component (according to Character | Unreal Engine Documentation)

The only functionality you’d really use from a character movement component would be the concept of consuming input, which is simple enough to replicate. The player controller passes inputs to the pawn, which then uses them to update the physics, and resets them ready for the next frame.