I have made some substantial modifications to my character movement to give it some deceleration logic for smooth movement. But it is done entirely in blueprint and is embarrassingly messy. It is also causing problems during multiplayer testing. For maintainability I am replacing the logic with C++. But I would appreciate some opinions before I do it, because it is possible that the way I plan to do it may not be preferable.
The options that I am aware of are, override the input events in C++ and copy the concepts. Or maybe make some additions to the character movement module.
Thank you.
Right pattern: leave input alone and move the logic into a custom CharacterMovementComponent — that’s what that class is for, and it’s the layer that already handles prediction and replication, which likely fixes your multiplayer problem for free.
Concretely:
- Subclass UCharacterMovementComponent and override CalcVelocity — deceleration logic usually lives there. Override the Phys functions (PhysWalking etc.) only if you need to change the whole integration step.
-
- In your Character’s constructor set CharacterMovementComponentClassName to your subclass (or override the movement component class on the Blueprint).
-
- Keep SetupPlayerInputComponent doing input → set flags / call server RPCs like today, but let the CMC consume those flags each tick. Don’t override the input pipeline in C++; you’d be re-implementing coordination the CMC already does.
-
- If your deceleration needs extra replicated state (say a braking flag), use the SavedMove pattern: subclass FSavedMove_Character, pack the flag into GetCompressedFlags, and override GetPredictionData_Client / GetPredictionData_Server so client prediction stays in sync.
- This is the standard approach for exactly your case — messy BP movement replaced by C++ with correct multiplayer behavior.