I’ve been trying to think of how best to extend the UCharacterMovementComponent to allow for states like dodge (which may alter the players collision volume, or ignore certain collision layers temporarily), or climbing - as well as keeping things simple for the character animation state machine (i.e. just querying the movement component for the current physics state rather than check multiple components).
Here’s my current plan, this would take a lot of functionality in the existing UCharacterMovementComponent and break it out into multiple files with an eye towards extendability:
Is that UML? Well anyway, it’s definitely something covered in the lectures I always skipped, so I’m afraid I can’t give specific feedback.
Still, I think it’s something worth working on for sure. If you just want the standard FPS character kind of movement that Epic almost exclusively use internally then yeah there’s no real reason not to use UCharacterMovementComponent as is. Unfortunately though if you want to customize it, it strikes me as being something of an almighty mess. It has support for custom movement modes of course, but the way it’s implemented with enums, switches and assumptions all over the place seems to me like a recipe for pain if you’re trying to do anything remotely complex.
Then there’s the fact that there seems to be a bunch of functionality built into it that in theory could be shared to some degree with non-character movement - network prediction being an obvious one. I think it’s definitely an area asking for a more modular approach. I guess one consideration with that is performance in cases when you have lots of characters, but I don’t think that necessarily needs to suffer by taking such an approach, so long as you keep it in mind.
So yeah, go ahead and prototype it a little. I don’t think there’s any reason why Epic wouldn’t consider a pull request at some point either, nothing wrong with having a couple of alternatives for the same component in the engine if they each have their own benefits.
This was my old account that I had to nuke after the forums were hacked, but to answer your question - I got it somewhat functional and then abandoned it after moving to a different project. It’s certainly do-able (I tend to write custom movement components as much as possible so I have a more complete understanding of what the code is doing, rather than just trusting “black boxes”) - but it is a lot of work. PhysX also doesn’t seem to have a concept of a movement state machine for Characters (they do have Character Controllers which do some basic character movement calculations but nothing too crazy). Havok has a very good state machine model, but obviously that isn’t free.
My feeling is most people(Epic included) just use the UCharacterMovement component and use a proverbial tank to swat a fly.
