Course contentsShow
← Unreal Engine Game Development
Lesson 731 of 88010. Networking and ReplicationFree lesson

Synchronizing Custom Movement Capabilities

Extend the base movement component to support unique mechanics like wall-running or dashing while maintaining full compatibility with prediction systems.

In this lesson, you will learn how to integrate custom movement mechanics like wall-running or dashing into the CharacterMovementComponent while ensuring they stay perfectly synchronized between the client and server.

Extending the Movement State

To implement a custom capability like "Wall Running," you cannot simply rely on RPCs, as they are too slow for frame-by-frame movement corrections. Instead, you must extend the UCharacterMovementComponent to include a new EMovementMode. By adding a custom mode, you tap into the component’s existing reconciliation architecture, which automatically handles input buffering, prediction, and server-side validation.

When a client initiates a wall-run, you set the movement mode to MOVE_Custom and define a custom sub-mode index. This tells the server, "I am now in a specific state," allowing the server to run the same movement logic to verify the client's position.

Synchronizing via SavedMoves

The magic of synchronized custom movement lies in FSavedMove_Character. To ensure your wall-running logic survives network latency, you must override FSavedMove_Character::Serialize to pack your custom state (like the wall normal or run duration) into the bitstream.

// Within your custom FSavedMove_Character
virtual void SetMoveFor(ACharacter* Character, float InDeltaTime, FVector const& NewAccel, class FNetworkPredictionData_Client_Character& ClientData) override
{
    Super::SetMoveFor(Character, InDeltaTime, NewAccel, ClientData);
    MyCustomState = Cast<UMyMovementComponent>(Character->GetMovementComponent())->bIsWallRunning;
}

By adding these flags to the SavedMove, the client sends its intent to the server. If the server’s calculated position deviates from the client’s predicted position due to lag or an invalid wall-run attempt, the server sends a correction back, forcing the client to snap to the authoritative state. This process ensures that your custom mechanics feel just as responsive as the native "Walking" or "Falling" modes, without desyncing during intense gameplay.

Key Takeaway: Never implement custom movement exclusively via RPCs; always extend the CharacterMovementComponent state machine and serialize your custom flags into FSavedMove to allow the engine to automatically reconcile your client-side predictions against the server’s authoritative movement simulation.