Executing Server RPCs for Authoritative Game State Changes

In this lesson, you will learn how to secure your game state by forcing clients to route their gameplay intentions through Server RPCs for centralized validation.

In a client-server architecture, the client should never directly modify game-critical state like health, ammo, or inventory. If a client simply sets Health = 0 on their own machine, the server (which is the ultimate authority) will remain unaware, leading to "cheating" or state desync. Instead, we treat the client’s input as a request, which we send to the server via a Server RPC.

The Validation Workflow

When a player performs an action (like firing a weapon), the client-side code triggers a Server RPC function. This function executes on the server, where you perform your authoritative logic—such as checking if the player actually has enough ammo or if the target is within range. If the check passes, the server modifies the state. Because that state variable is marked as Replicated, the server automatically broadcasts the updated value back to all connected clients.

Implementation Example

Consider a simple Interact request. The client triggers the RPC, and the server validates the proximity before changing the object state:

// Client-side request
void AMyCharacter::RequestInteract(AActor* Target)
{
    Server_Interact(Target);
}

// Server-side authoritative implementation
bool AMyCharacter::Server_Interact_Validate(AActor* Target)
{
    // Return false if logic suggests cheating (e.g., Target too far)
    return Target && GetDistanceTo(Target) < 200.0f;
}

void AMyCharacter::Server_Interact_Implementation(AActor* Target)
{
    // Perform state change only after validation
    Target->SetInteractedState(true);
}

By placing your logic inside the Server_Implementation block, you ensure that the server acts as the gatekeeper. The client merely "requests" the change; the server "executes" it only after verifying the rules. This pattern keeps your game state consistent and prevents malicious clients from manipulating the simulation.

Key Takeaway: Never allow clients to modify authoritative game state directly; always route gameplay inputs through validated Server RPCs so the server remains the single source of truth.