Executing Server Remote Procedure Calls

In this lesson, you will learn how to leverage Server RPCs to transition from client-side requests to authoritative state changes, ensuring your multiplayer game remains secure and consistent.

The Authority Gap

In an authoritative networking model, clients are never allowed to modify gameplay state—like reducing a player's Health or setting an Ability state—directly. If a client simply changed their own Health variable, a malicious user could set it to infinite. Instead, the client must send a "request" to the server. The server then validates that request against its authoritative game rules and, if approved, applies the change. This is the primary purpose of a Server RPC.

Implementing the Request

When you define a function with UFUNCTION(Server, Reliable) or Unreliable, you are creating a bridge for the client to signal an intent. Crucially, the server receives this call and performs the "Sanity Check."

Consider a player interacting with an object to gain a buff. The client doesn't grant the buff; it asks the server to do it:

// In your Character class
void AMyCharacter::RequestBuffActivation()
{
    // The client calls this locally, which triggers the RPC
    Server_ActivateBuff();
}

void AMyCharacter::Server_ActivateBuff_Implementation()
{
    // SERVER SIDE: Validation happens here
    if (HasAuthority() && CanActivateBuff())
    {
        // Apply the Gameplay Effect or State Change
        ApplyBuffEffect();
    }
}

The Workflow

1. The Request: The client triggers a Server RPC. This acts as a function call that jumps from the client machine to the server’s memory space.
2. Authoritative Validation: Once the code hits the _Implementation block on the server, you verify if the action is legal (e.g., is the player close enough to the object? Is the cooldown finished?).
3. State Propagation: Once validated, the server modifies the variable or triggers the effect. Because the variable is replicated, the change automatically propagates back down to all clients.

By using RPCs as a gatekeeper rather than a direct command, you maintain the server as the "Single Source of Truth."

Key Takeaway: Server RPCs act as verified requests where the client proposes a change, but the server retains the authority to validate and execute the final logic.