Unreal Engine RPC Optimization: Hoe je voorkomt dat je jouw netwerk elke Tick overspoelt

Elke multiplayer game developer krijgt uiteindelijk te maken met dezelfde netwerk-bottleneck: een client die op 144 frames per seconde draait en besluit om zijn custom movement state elke Tick naar de server te sturen. Binnen enkele seconden raakt de netwerk-queue van de server volledig overspoeld met redundante Remote Procedure Calls (RPCs), wat leidt tot extreme lag, packet loss en een onvermijdelijke disconnect. Je client voert in feite een Distributed Denial of Service (DDoS) aanval uit op je eigen server-infrastructuur.

Dit scenario is een van de meest voorkomende valkuilen in de architectuur van multiplayer games. Wanneer developers custom player inputs, complexe voertuig-physics of rapid-fire mechanics willen versturen, lijkt het plaatsen van een RPC in de Tick() functie de logische keuze voor een soepele responsiveness. Echter, de networking layer van Unreal Engine verwijdert niet automatisch tussenliggende RPCs. Als je game elke Tick een RPC verstuurt, worden ze allemaal in de wachtrij geplaatst en verzonden.

Voor movement- en positie-updates geef je bijna nooit om de 143 tussenliggende frames; je hebt alleen de allernieuwste state nodig om naar de andere clients te repliceren. In deze uitgebreide gids duiken we diep in unreal engine rpc optimization en laten we je precies zien hoe je deze Tick-gebaseerde netwerk calls kunt throttelen, smart state accumulation implementeert en je multiplayer bandwidth overhead drastisch verlaagt.

Het gevaar van Tick-gebonden netwerk events

Voordat we een oplossing implementeren, is het essentieel om de anatomie van het probleem te begrijpen. Wanneer je een RPC declareert in Unreal Engine, of het nu Server, Client, of NetMulticast is, geef je de netwerk-driver van de engine de opdracht om de functieparameters te serialiseren en in de uitgaande packet queue te plaatsen.

Het probleem met queueing

Unreal Engine bundelt uitgaande RPCs in packets op basis van de NetUpdateFrequency van de verbinding en de bandwidth-limieten. Als een client een Server RPC aanroept bij elke Tick met een hoge framerate, zal de engine proberen elk van die calls te verwerken.

Als de RPC is gemarkeerd als Reliable, is de situatie catastrofaal. Reliable RPCs garanderen bezorging en de volgorde van uitvoering. Het netwerkkanaal zal snel vollopen, en als de buffer overloopt, zal de verbinding geforceerd worden verbroken door de engine, met een gedisconnecteerde speler als gevolg.

Als de RPC is gemarkeerd als Unreliable, zal de engine packets laten vallen wanneer de queue vol raakt. Hoewel dit een harde disconnect voorkomt, leidt het tot enorme rubber-banding. De server ontvangt misschien frame 1 en frame 2, verliest frames 3-100, en verwerkt dan frame 101. Het resultaat is schokkerige beweging die de gameplay-ervaring ruïneert. Dit is een veelvoorkomende oorzaak wanneer teams het Unreal Engine RPC replication issue dat je states breekt proberen op te lossen.

De berekening van de bandwidth

Laten we naar wat concrete cijfers kijken. Stel dat je een simpele vector (12 bytes) en een rotator (12 bytes) verstuurt via een Server RPC. Met de RPC header overhead schatten we dit op 32 bytes per call.

• Bij 30 FPS: 30 * 32 bytes = 960 bytes/seconde (ongeveer 1 KB/s per client).
• Bij 144 FPS: 144 * 32 bytes = 4.608 bytes/seconde (ongeveer 4.6 KB/s per client).
• Bij 240 FPS: 240 * 32 bytes = 7.680 bytes/seconde.

Vermenigvuldig dit met 64 spelers in een battle royale, en je server verwerkt plotseling bijna een halve megabyte aan pure RPC-overhead per seconde — alleen al voor basis movement tracking. Dit is niet schaalbaar.

Stap 1: De Tick-afhankelijkheid doorbreken met een Accumulator Pattern

De meest effectieve strategie voor unreal engine rpc optimization is om de frequentie waarmee je gegevens over het netwerk verstuurt los te koppelen van de rendering framerate van de client. In plaats van de RPC in Tick() aan te roepen, update je elke Tick een lokale variabele en gebruik je een timer om die data met een vast, voorspelbaar interval naar de server te pushen (bijv. 10 of 20 keer per seconde).

We noemen dit het Accumulator Pattern. De client verzamelt continu de nieuwste state, maar verzendt deze pas wanneer de netwerk-poort opengaat.

De doel-frequentie bepalen

Je hebt geen 144 updates per seconde nodig voor een soepele multiplayer-ervaring. De meeste moderne competitive shooters draaien hun servers op 30Hz of 60Hz. Daarom is het versturen van client-updates 15 tot 30 keer per seconde meestal meer dan genoeg, mits je gebruikmaakt van goede client-side prediction en server-side interpolation.

Door de verzendsnelheid te verlagen van een onbegrensde 144Hz naar een gecapte 20Hz, verminder je het netwerkverkeer voor die specifieke actie direct met meer dan 85%.

Stap 2: De Rate-Limiter implementeren in C++

Laten we kijken hoe we dit effectief in C++ kunnen implementeren. We maken een systeem waarbij de client elke Tick zijn gewenste locatie en rotatie bijhoudt, maar de Server_UpdateTransform RPC alleen verstuurt op basis van een vooraf gedefinieerde netwerk-verzendfrequentie.

Het Header-bestand (.h)

Eerst definiëren we onze variabelen en functies in onze custom APawn of ACharacter class. We hebben een timer handle, een update rate en variabelen nodig om onze nog niet verzonden data vast te houden.

UCLASS()
class MYGAME_API AMyCustomPawn : public APawn
{
    GENERATED_BODY()

public:
    AMyCustomPawn();

    virtual void Tick(float DeltaTime) override;
    virtual void SetupPlayerInputComponent(class UInputComponent* PlayerInputComponent) override;

protected:
    virtual void BeginPlay() override;

    // The RPC to send data to the server. Marked as Unreliable for rapid, continuous updates.
    UFUNCTION(Server, Unreliable, WithValidation)
    void Server_SendTransformUpdate(FVector NewLocation, FRotator NewRotation);

private:
    // Timer handle for our network flush
    FTimerHandle NetworkUpdateTimerHandle;

    // How many times per second we want to send updates to the server
    UPROPERTY(EditDefaultsOnly, Category = "Network")
    float NetworkSendRate;

    // Flag to track if we have new data that hasn't been sent yet
    bool bHasPendingNetworkUpdate;

    // The accumulated data waiting to be sent
    FVector PendingLocation;
    FRotator PendingRotation;

    // The function called by the timer to flush data
    void FlushNetworkUpdate();
};

Het Source-bestand (.cpp)

Nu implementeren we de logica. We stellen de timer in bij BeginPlay, updaten onze pending variabelen in Tick, en laten de timer de daadwerkelijke netwerktransmissie afhandelen.

#include "MyCustomPawn.h"
#include "TimerManager.h"

AMyCustomPawn::AMyCustomPawn()
{
    PrimaryActorTick.bCanEverTick = true;
    
    // Default to sending 20 updates per second
    NetworkSendRate = 20.0f; 
    bHasPendingNetworkUpdate = false;
}

void AMyCustomPawn::BeginPlay()
{
    Super::BeginPlay();

    // Only the local controlling client should run the network flush timer
    if (IsLocallyControlled())
    {
        float UpdateInterval = 1.0f / NetworkSendRate; // e.g., 1.0 / 20.0 = 0.05 seconds

        GetWorld()->GetTimerManager().SetTimer(
            NetworkUpdateTimerHandle,
            this,
            &AMyCustomPawn::FlushNetworkUpdate,
            UpdateInterval,
            true // Loop continuously
        );
    }
}

void AMyCustomPawn::Tick(float DeltaTime)
{
    Super::Tick(DeltaTime);

    // Run your custom client-side movement logic here
    // e.g., FVector NewLoc = ...; FRotator NewRot = ...;
    // SetActorLocationAndRotation(NewLoc, NewRot);

    if (IsLocallyControlled())
    {
        // Instead of calling the RPC here, we just store the latest state
        PendingLocation = GetActorLocation();
        PendingRotation = GetActorRotation();
        
        // Mark that we have fresh data waiting to be sent
        bHasPendingNetworkUpdate = true;
    }
}

void AMyCustomPawn::FlushNetworkUpdate()
{
    // If there is no new data (e.g., the player is standing still), don't waste bandwidth
    if (!bHasPendingNetworkUpdate)
    {
        return;
    }

    // Send the latest accumulated state to the server
    Server_SendTransformUpdate(PendingLocation, PendingRotation);

    // Reset the flag until the next tick modifies the state again
    bHasPendingNetworkUpdate = false;
}

bool AMyCustomPawn::Server_SendTransformUpdate_Validate(FVector NewLocation, FRotator NewRotation)
{
    // Add anti-cheat validation here. Is the location reasonable?
    return true; 
}

void AMyCustomPawn::Server_SendTransformUpdate_Implementation(FVector NewLocation, FRotator NewRotation)
{
    // The server receives the rate-limited data and applies it
    SetActorLocationAndRotation(NewLocation, NewRotation);
    
    // Note: The server would then replicate this to other clients, 
    // typically via standard Replicated properties, NOT by Multicasting.
}

Waarom deze architectuur werkt

Deze opzet lost het probleem van de netwerk-overspoeling elegant op. Ongeacht of de client op 30 FPS of 300 FPS draait, de server ontvangt gegarandeerd precies NetworkSendRate updates per seconde (ervan uitgaande dat er geen packet loss is).

Bovendien hebben we een early-out check geïmplementeerd (!bHasPendingNetworkUpdate). Als de speler zijn toetsenbord verlaat om koffie te halen, stopt de client volledig met het verzenden van RPCs, waardoor kritieke bandwidth vrijkomt voor actieve spelers. Dit is een enorme winst voor het behouden van consistente server-performance.

Stap 3: State interpolation op andere clients afhandelen

Wanneer je de netwerk-verzendfrequentie verlaagt, zal de beweging op de server — en bijgevolg op de andere verbonden clients — schokkerig worden. Als je updates verstuurt op 10Hz, zal het personage zichtbaar 10 keer per seconde teleporteren op een 60 FPS monitor.

Om dit op te lossen, kun je het personage niet simpelweg naar de nieuwe locatie laten 'snappen'. Je moet interpolatie gebruiken. Wanneer de server de NewLocation repliceert naar de simulated proxies (de andere clients die de speler observeren), moeten die clients vloeiend FMath::VInterpTo gebruiken om over tijd van hun huidige positie naar de gerepliceerde doelpositie te bewegen.

Dit zorgt ervoor dat zelfs bij een zeer agressieve rate limit (zoals 5 of 10 updates per seconde), de visuele weergave boterzacht blijft. Als je merkt dat personages incorrect verspringen tijdens interpolatie, kun je bekijken hoe je player location desync oplost in UEFN en Unreal Engine multiplayer.

Stap 4: Struct Batching voor complexe RPCs

Als je game het verzenden van meerdere verschillende variabelen vereist, stuur dan geen afzonderlijke RPCs. Elke RPC heeft een basis header overhead (meestal minimaal 1-2 bytes, maar in de praktijk meer bij het serialiseren van de payload).

Als je Server_SendHealth(), Server_SendArmor(), en Server_SendPosition() aanroept in dezelfde netwerk-flush, betaal je de header-kosten drie keer.

Maak in plaats daarvan een specifieke struct aan voor je netwerk-payloads.

USTRUCT()
struct FPlayerNetworkState
{
    GENERATED_BODY()

    UPROPERTY()
    FVector Location;

    UPROPERTY()
    FRotator Rotation;

    UPROPERTY()
    uint8 CurrentWeaponIndex;

    UPROPERTY()
    bool bIsCrouching;
};

Geef deze enkele struct door via je timer-gebaseerde RPC. Het reflection-systeem van Unreal Engine zal deze variabelen efficiënt verpakken in een enkele packet payload, waardoor de byte-footprint op je verbinding wordt geminimaliseerd.

5 Best Practices voor Unreal Engine RPC Optimization

Om ervoor te zorgen dat je game schaalt van lokale testen naar duizenden gelijktijdige spelers, kun je deze fundamentele regels voor netwerkarchitectuur hanteren:

1. Verstuur nooit RPCs in Tick zonder gate: Beschouw dit als een harde regel. Als een RPC zich in Tick() bevindt, moet deze worden beveiligd door een tijdscontrole (bijv. if (TimeSinceLastRPC > 0.1f)) of worden beheerd via een herhalende timer.
2. Geef prioriteit aan Unreliable boven Reliable: Voor data die continu wordt geüpdatet (beweging, rondkijken, continue beam-wapens), gebruik je altijd Unreliable RPCs. Als een packet wegvalt, zal het volgende packet dat een fractie van een seconde later aankomt dit toch overschrijven. Reliable RPCs moeten strikt worden gereserveerd voor absolute state-wijzigingen (bijv. wapen afgevuurd, item opgepakt, speler gestorven).
3. Gebruik Quantization voor floats en vectoren: Bij het verzenden van FVector data heb je zelden volledige floating-point precisie nodig. Unreal Engine stelt je in staat om vectoren in RPCs te quantizen (bijv. FVector_NetQuantize100), wat de waarden afrondt op twee decimalen en de benodigde bandwidth drastisch vermindert.
4. Gebruik standaard Replication voor downstream data: Terwijl clients RPCs moeten gebruiken om data naar de server te sturen, moet de server zelden Multicast RPCs gebruiken om continu data terug te sturen. De server moet een UPROPERTY(Replicated) variabele updaten, waardoor Unreal's ingebouwde replication manager automatisch de bandwidth-optimalisatie, prioritering en relevancy-sorting kan afhandelen.
5. Profileer vroeg en vaak: Gebruik het net.DumpRelevantActors commando en de Network Profiler tool (NetworkProfiler.exe in de Engine binaries) om precies te visualiseren hoeveel bytes je RPCs per frame consumeren. Gok nooit naar je optimalisatiewinst; meet deze empirisch.

Infrastructuur en Backend Scaling afhandelen

Het beheersen van de fijne kneepjes van de netcode van Unreal Engine is een enorme onderneming. Je besteedt uren aan het tweaken van timer handles, het quantizen van vectoren en het beperken van desyncs, alleen maar om je dedicated servers soepel te laten draaien zonder hun bandwidth-limieten te overschrijden.

Zodra je in-game code eindelijk is geoptimaliseerd, moet je die servers nog wereldwijd implementeren en schalen. Als je dit zelf bouwt, moet je fleet managers, load balancers, database sharding en SSL-certificaatbeheer opzetten — goed voor 4 tot 6 weken intensief infrastructuurwerk dat je weghoudt van het daadwerkelijke game design.

Met horizOn zijn deze backend services al geconfigureerd, specifiek voor game developers. Je krijgt schaalbare dedicated server hosting, real-time database synchronisatie en robuuste analytics direct uit de doos, zodat je jouw game kunt releasen in plaats van je infrastructuur.

Tot slot

De sleutel tot unreal engine rpc optimization is het besef dat netwerk-bandwidth een eindige, zeer vluchtige bron is. Je kunt de netwerklaag niet behandelen als een standaard frame buffer. Door af te stappen van Tick-gestuurde uitvoering en het Accumulator Pattern te omarmen, krijg je volledige controle over de data-output van je game. Je vermindert de serverbelasting, beperkt packet loss en creëert een drastisch soepelere ervaring voor spelers op wisselende internetverbindingen.

Onthoud dat het optimaliseren van je game een continu proces is. Stop met vertrouwen op standaard engine-gedrag om je te beschermen tegen netwerk-overspoeling. Neem expliciete controle over je datastroom. Implementeer deze rate limits in je huidige prototype, monitor de resultaten met de Network Profiler en zie de prestaties van je server omhoog schieten.

Klaar om je nieuw geoptimaliseerde multiplayer backend te schalen? Probeer horizOn gratis of bekijk de API docs om te zien hoe eenvoudig professionele game-infrastructuur kan zijn.

---

Bron: Network: How not to send all PRC every tick?