📡 Lesson 6.4: RPCs — Remote Procedure Calls

What an RPC Is

A Remote Procedure Call is a method you call on your machine that actually executes on other machines in the session. You call it like a normal method; Netcode serialises the call and its arguments, sends them across the network, and invokes the method on the target machines. It's the mechanism for the two directions NetworkVariables don't cover: a client sending a request up to the server, and the server broadcasting a momentary event down to clients.

RPCs are for events — "this happened just now." Unlike NetworkVariables, they aren't retained: a client who joins later won't receive RPCs sent before they connected. That's the litmus test from Lesson 6.3 — if a late joiner needs it, use a NetworkVariable; if it's a fleeting action, use an RPC.

The Universal [Rpc] Attribute

In current Netcode (Unity 6), you declare an RPC by marking a method with [Rpc(SendTo.…)] and giving it a name ending in Rpc. The SendTo value sets the default destination:

using Unity.Netcode;

// Runs on the SERVER when any client (or the server) calls it.
[Rpc(SendTo.Server)]
void SubmitScoreRpc(int points) { /* ... executes on the server ... */ }

// Runs on ALL clients (and the host) when the server calls it.
[Rpc(SendTo.ClientsAndHost)]
void AnnounceWinnerRpc(FixedString32Bytes name) { /* ... executes on clients ... */ }

The Rpc suffix is mandatory — the source generator uses it to identify RPC methods, and you'll get a compile error without it. Think of it as part of the syntax, not a style choice.

SendTo Targets

SendTo names where the RPC runs. The common values:

For a dedicated server with no display, prefer NotServer for pure visual/audio effects so the headless server doesn't waste time on them; use ClientsAndHost when you're developing with a host and want the host's own client to see the effect too.

Client → Server Requests

This is the upward direction — a client asks the server to do something. The owning client calls a SendTo.Server RPC; the method body runs on the server, where authority lives:

public class PlayerActions : NetworkBehaviour
{
    void Update()
    {
        if (!IsOwner) return;                       // only my avatar reads my input
        if (Input.GetKeyDown(KeyCode.Space))
            RequestFireRpc();                        // call → runs on the server
    }

    [Rpc(SendTo.Server)]
    void RequestFireRpc()
    {
        // This body executes on the SERVER.
        // ... validate (cooldown, ammo), spawn the projectile (server-authoritative) ...
        SpawnTracerRpc();                            // then tell everyone to show it
    }
}

Server → Client Broadcasts

The downward direction — the server tells clients about a momentary event they should present. The server calls a SendTo.ClientsAndHost (or NotServer/Everyone) RPC:

    [Rpc(SendTo.ClientsAndHost)]
    void SpawnTracerRpc()
    {
        // This body executes on EVERY client (and the host).
        // Purely presentational: play the muzzle flash, tracer, and sound locally.
        // The actual projectile/damage is server-authoritative state, not here.
    }

Keep broadcast RPCs presentational where possible — effects, sounds, animations. The consequences (a projectile that deals damage, a score change) belong in server-authoritative state and NetworkVariables, so a dropped RPC never desyncs the actual game, only a cosmetic flourish.

Parameters & Targeting

RPCs take parameters, which must be network-serialisable (the same types NetworkVariables allow — primitives, Unity structs, FixedString, INetworkSerializable). For dynamic targeting, add a trailing RpcParams parameter and use SendTo.SpecifiedInParams:

// Send to exactly one client, chosen at call time.
[Rpc(SendTo.SpecifiedInParams)]
void PrivateNoticeRpc(FixedString128Bytes message, RpcParams rpcParams = default)
{
    // runs only on the targeted client
    ShowToast(message.ToString());
}

// caller (on the server):
PrivateNoticeRpc("Your turn!", RpcTarget.Single(targetClientId, RpcTargetUse.Temp));

You can also read who sent an RPC on the receiving side via the RpcParams receive info — useful on the server to know which client made a request. But keep parameters lean: every RPC is a network message, and big or frequent ones cost bandwidth.

Validate on the Server

This is where authority (Lesson 6.1) becomes code. A SendTo.Server RPC is a request from a machine you don't trust — so the server must validate it before acting:

[Rpc(SendTo.Server)]
void RequestPickupRpc(ulong coinId)
{
    // Executes on the server — check the rules before granting anything.
    if (!TryGetCoin(coinId, out var coin)) return;          // exists?
    if (Vector3.Distance(transform.position, coin.Position) > 2f) return;  // in range?
    if (coin.Collected) return;                             // not already taken?

    coin.Collect();                 // authoritative state change
    Score.Value += 10;              // NetworkVariable → replicates to all
}

Never assume a request is legitimate just because it arrived. A cheat-client can call RequestPickupRpc with any coin id from anywhere — the distance and existence checks are what keep the game fair. An RPC from a client is an ask, not a command; the server decides. This single habit is the difference between a robust multiplayer game and an exploitable one.

Hands-on Challenge

Summary

🚀 What's Next?

You now have the whole toolkit — sessions, spawning, ownership, NetworkVariables, and RPCs. In Lesson 6.5 you'll assemble them into the module's mini-project: a small authoritative multiplayer prototype where players move, act, and share synced state, host-and-client, end to end.