Unreal Engine RPC Optimization: Cara Menghentikan Flooding Jaringan di Setiap Tick

Setiap pengembang game Multiplayer pasti pernah menghadapi bottleneck jaringan yang sama: client yang berjalan di 144 frames per second memutuskan untuk mengirim status movement kustom ke server di setiap tick. Dalam hitungan detik, antrean jaringan server akan mengalami flooding penuh dengan Remote Procedure Calls (RPC) redundan, menyebabkan lag parah, packet loss, dan disconnect yang tak terhindarkan. Client Anda pada dasarnya melakukan DDoS attack terhadap infrastruktur server Anda sendiri.

Skenario ini merupakan salah satu pitfall paling umum dalam arsitektur game Multiplayer. Saat pengembang perlu mengirim input pemain kustom, status physics kendaraan yang kompleks, atau mekanisme tembakan cepat, menempatkan RPC di dalam fungsi Tick() tampak seperti pilihan logis untuk responsivitas yang mulus. Namun, networking layer Unreal Engine tidak secara otomatis membuang RPC perantara. Jika game Anda mengirimkan RPC di setiap tick, semuanya akan masuk antrean dan ditransmisikan.

Untuk update movement dan posisi, Anda hampir tidak pernah peduli dengan 143 frame perantara; Anda hanya butuh status terbaru yang absolut untuk direplikasi ke client lain. Dalam panduan komprehensif ini, kita akan mendalami unreal engine rpc optimization, menunjukkan cara membatasi network call berbasis tick ini, mengimplementasikan akumulasi status yang cerdas, dan secara drastis mengurangi bandwidth overhead Multiplayer Anda.

Bahaya Network Event yang Terikat pada Tick

Sebelum mengimplementasikan solusi, sangat penting untuk memahami anatomi masalahnya. Saat Anda mendeklarasikan RPC di Unreal Engine, baik itu Server, Client, atau NetMulticast, Anda menginstruksikan network driver engine untuk melakukan serialisasi parameter fungsi dan memasukkannya ke dalam antrean paket keluar.

Masalah dengan Antrean (Queueing)

Unreal Engine menggabungkan RPC keluar ke dalam paket berdasarkan NetUpdateFrequency koneksi dan batas bandwidth. Jika client memanggil Server RPC setiap tick pada frame rate tinggi, engine akan mencoba memproses setiap panggilan tersebut.

Jika RPC ditandai sebagai Reliable, situasinya akan menjadi katastrofik. Reliable RPC menjamin pengiriman dan urutan eksekusi. Channel jaringan akan cepat penuh, dan jika buffer meluap, koneksi akan diputus paksa oleh engine, mengakibatkan pemain terputus.

Jika RPC ditandai sebagai Unreliable, engine akan membuang paket saat antrean penuh. Meskipun ini mencegah disconnect total, hal ini menyebabkan rubber-banding masif. Server mungkin menerima frame 1, frame 2, membuang frame 3-100, lalu memproses frame 101. Hasilnya adalah pergerakan yang tidak menentu dan patah-patah yang merusak pengalaman gameplay. Ini adalah akar masalah yang umum saat tim sedang memperbaiki masalah replikasi RPC Unreal Engine yang merusak status Anda.

Perhitungan Bandwidth

Mari kita lihat beberapa angka konkret. Bayangkan Anda mengirimkan vector sederhana (12 bytes) dan rotator (12 bytes) via Server RPC. Dengan overhead header RPC, mari kita estimasikan 32 bytes per panggilan.

• Pada 30 FPS: 30 * 32 bytes = 960 bytes/second (sekitar 1 KB/s per client).
• Pada 144 FPS: 144 * 32 bytes = 4,608 bytes/second (sekitar 4.6 KB/s per client).
• Pada 240 FPS: 240 * 32 bytes = 7,680 bytes/second.

Kalikan ini dengan 64 pemain dalam sebuah battle royale, dan server Anda tiba-tiba harus memproses hampir setengah megabyte murni overhead RPC setiap detik—hanya untuk tracking pergerakan dasar. Ini tidak skalabel.

Langkah 1: Memutus Ketergantungan Tick dengan Accumulator Pattern

Strategi paling efektif untuk unreal engine rpc optimization adalah memisahkan network send rate dari rendering frame rate client. Alih-alih mengirimkan RPC di Tick(), Anda harus memperbarui variabel lokal setiap tick, lalu menggunakan timer untuk mengirim data tersebut ke server pada interval yang tetap dan terprediksi (misalnya, 10 atau 20 kali per detik).

Kita menyebutnya sebagai Accumulator Pattern. Client mengakumulasi status terbaru secara terus-menerus tetapi hanya mentransmisikannya saat network gate terbuka.

Mengidentifikasi Frekuensi Target

Anda tidak butuh 144 update per detik untuk pengalaman Multiplayer yang mulus. Kebanyakan shooter kompetitif modern menjalankan server mereka pada 30Hz atau 60Hz. Oleh karena itu, mengirim update client 15 hingga 30 kali per detik biasanya sudah lebih dari cukup, asalkan Anda menggunakan client-side prediction dan server-side interpolation yang tepat.

Dengan mengurangi send rate dari 144Hz (tanpa batas) menjadi 20Hz (dibatasi), Anda secara instan mengurangi network traffic sebesar lebih dari 85% untuk aksi spesifik tersebut.

Langkah 2: Mengimplementasikan Rate-Limiter di C++

Mari kita lihat cara mengimplementasikan ini secara efektif di C++. Kita akan membuat sistem di mana client melacak lokasi dan rotasi target yang diinginkan setiap tick, tetapi hanya mengirimkan RPC Server_UpdateTransform berdasarkan network send rate yang telah ditentukan.

File Header (.h)

Pertama, kita definisikan variabel dan fungsi dalam kelas kustom APawn atau ACharacter kita. Kita butuh timer handle, update rate, dan variabel untuk menampung data yang belum terkirim.

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;

    // RPC untuk mengirim data ke server. Ditandai sebagai Unreliable untuk update cepat dan berkelanjutan.
    UFUNCTION(Server, Unreliable, WithValidation)
    void Server_SendTransformUpdate(FVector NewLocation, FRotator NewRotation);

private:
    // Timer handle untuk network flush kita
    FTimerHandle NetworkUpdateTimerHandle;

    // Berapa kali per detik kita ingin mengirim update ke server
    UPROPERTY(EditDefaultsOnly, Category = "Network")
    float NetworkSendRate;

    // Flag untuk melacak jika kita punya data baru yang belum dikirim
    bool bHasPendingNetworkUpdate;

    // Data akumulasi yang menunggu untuk dikirim
    FVector PendingLocation;
    FRotator PendingRotation;

    // Fungsi yang dipanggil oleh timer untuk flush data
    void FlushNetworkUpdate();
};

File Source (.cpp)

Sekarang, kita implementasikan logikanya. Kita atur timer di BeginPlay, perbarui variabel pending di Tick, dan biarkan timer menangani transmisi jaringan yang sebenarnya.

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

AMyCustomPawn::AMyCustomPawn()
{
    PrimaryActorTick.bCanEverTick = true;
    
    // Default mengirim 20 update per detik
    NetworkSendRate = 20.0f; 
    bHasPendingNetworkUpdate = false;
}

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

    // Hanya client yang mengontrol secara lokal yang menjalankan timer network flush
    if (IsLocallyControlled())
    {
        float UpdateInterval = 1.0f / NetworkSendRate; // misal, 1.0 / 20.0 = 0.05 detik

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

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

    // Jalankan logika movement client-side kustom Anda di sini
    // misal, FVector NewLoc = ...; FRotator NewRot = ...;
    // SetActorLocationAndRotation(NewLoc, NewRot);

    if (IsLocallyControlled())
    {
        // Alih-alih memanggil RPC di sini, kita simpan saja status terbarunya
        PendingLocation = GetActorLocation();
        PendingRotation = GetActorRotation();
        
        // Tandai bahwa kita punya data baru yang menunggu untuk dikirim
        bHasPendingNetworkUpdate = true;
    }
}

void AMyCustomPawn::FlushNetworkUpdate()
{
    // Jika tidak ada data baru (misal pemain diam), jangan buang bandwidth
    if (!bHasPendingNetworkUpdate)
    {
        return;
    }

    // Kirim status akumulasi terbaru ke server
    Server_SendTransformUpdate(PendingLocation, PendingRotation);

    // Reset flag sampai tick berikutnya memodifikasi status lagi
    bHasPendingNetworkUpdate = false;
}

bool AMyCustomPawn::Server_SendTransformUpdate_Validate(FVector NewLocation, FRotator NewRotation)
{
    // Tambahkan validasi anti-cheat di sini. Apakah lokasinya wajar?
    return true; 
}

void AMyCustomPawn::Server_SendTransformUpdate_Implementation(FVector NewLocation, FRotator NewRotation)
{
    // Server menerima data yang sudah di-rate-limit dan menerapkannya
    SetActorLocationAndRotation(NewLocation, NewRotation);
    
    // Catatan: Server kemudian akan mereplikasi ini ke client lain, 
    // biasanya melalui Replicated properties standar, BUKAN dengan Multicasting.
}

Mengapa Arsitektur Ini Berhasil

Setup ini secara elegan menyelesaikan masalah network flood. Tidak peduli apakah client berjalan pada 30 FPS atau 300 FPS, server dijamin akan menerima tepat NetworkSendRate update per detik (dengan asumsi tidak ada packet loss).

Selain itu, kita mengimplementasikan pengecekan early-out (!bHasPendingNetworkUpdate). Jika pemain meninggalkan keyboard untuk mengambil kopi, client berhenti mengirimkan RPC sepenuhnya, membebaskan bandwidth kritis untuk pemain yang aktif. Ini adalah kemenangan besar untuk menjaga performa server yang konsisten.

Langkah 3: Menangani State Interpolation pada Client Lain

Saat Anda mengurangi network send rate, pergerakan di server—dan konsekuensinya pada client lain yang terhubung—akan menjadi tersendat. Jika Anda mengirim update pada 10Hz, karakter akan terlihat berteleportasi 10 kali dalam satu detik pada monitor 60 FPS.

Untuk memperbaikinya, Anda tidak bisa sekadar melakukan snapping karakter ke lokasi baru. Anda harus menggunakan interpolation. Saat server mereplikasi NewLocation ke simulated proxies (client lain yang melihat pemain tersebut), client tersebut harus melakukan smooth FMath::VInterpTo dari posisi saat ini ke target posisi yang direplikasi seiring waktu.

Ini memastikan bahwa bahkan dengan rate limit yang sangat agresif (seperti 5 atau 10 update per detik), representasi visual tetap halus. Jika Anda kesulitan dengan karakter yang patah-patah secara tidak benar selama interpolation, Anda mungkin perlu meninjau cara memperbaiki desinkronisasi lokasi pemain di UEFN dan Multiplayer Unreal Engine.

Langkah 4: Struct Batching untuk RPC yang Kompleks

Jika game Anda memerlukan pengiriman beberapa variabel berbeda, jangan kirimkan beberapa RPC terpisah. Setiap RPC memiliki overhead header dasar (biasanya minimal sekitar 1-2 byte, tetapi praktisnya lebih saat mempertimbangkan payload serialization).

Jika Anda memanggil Server_SendHealth(), Server_SendArmor(), dan Server_SendPosition() dalam network flush yang sama, Anda membayar biaya header tiga kali lipat.

Sebagai gantinya, buatlah struct khusus untuk payload jaringan Anda.

USTRUCT()
struct FPlayerNetworkState
{
    GENERATED_BODY()

    UPROPERTY()
    FVector Location;

    UPROPERTY()
    FRotator Rotation;

    UPROPERTY()
    uint8 CurrentWeaponIndex;

    UPROPERTY()
    bool bIsCrouching;
};

Kirimkan single struct ini melalui RPC berbasis timer Anda. Reflection system Unreal Engine akan memaketkan variabel-variabel ini secara efisien ke dalam satu paket payload, meminimalkan byte footprint pada koneksi Anda.

5 Best Practice untuk Unreal Engine RPC Optimization

Untuk memastikan game Anda dapat diskalakan dari pengujian lokal hingga ribuan pemain bersamaan, adopsi aturan dasar berikut untuk arsitektur jaringan:

1. Jangan Pernah Mengirim RPC di Tick Tanpa Gate: Anggap ini sebagai aturan baku. Jika RPC ada di dalam Tick(), ia harus dijaga oleh pengecekan waktu (misal, if (TimeSinceLastRPC > 0.1f)) atau dikelola melalui looping timer.
2. Prioritaskan Unreliable dibanding Reliable: Untuk data yang diperbarui terus-menerus (movement, arah pandang, beam weapon berkelanjutan), selalu gunakan Unreliable RPC. Jika paket hilang, paket berikutnya yang tiba sepersekian detik kemudian akan menimpanya. Reliable RPC harus dicadangkan ketat untuk perubahan status absolut (misal, senjata ditembakkan, item diambil, pemain mati).
3. Gunakan Quantization untuk Float dan Vector: Saat mengirim data FVector, Anda jarang membutuhkan presisi floating-point penuh. Unreal Engine memungkinkan Anda untuk melakukan quantize pada vector dalam RPC (misal, FVector_NetQuantize100), yang membulatkan nilai ke dua tempat desimal dan memangkas bandwidth yang dibutuhkan untuk mengirimnya.
4. Pilih Replikasi Standar untuk Downstream Data: Meskipun client harus menggunakan RPC untuk mengirim data ke server, server jarang sekali harus menggunakan Multicast RPC untuk mengirim data berkelanjutan kembali ke bawah. Server harus memperbarui variabel UPROPERTY(Replicated), membiarkan built-in replication manager Unreal menangani optimasi bandwidth, prioritas, dan relevancy sorting secara otomatis.
5. Lakukan Profiling Sejak Dini dan Secara Rutin: Gunakan perintah net.DumpRelevantActors dan tool Network Profiler (NetworkProfiler.exe yang terletak di Engine binaries) untuk memvisualisasikan secara tepat berapa byte yang dikonsumsi RPC Anda per frame. Jangan pernah menebak hasil optimasi Anda; ukur secara empiris.

Menangani Infrastruktur dan Backend Scaling

Menguasai seluk-beluk netcode Unreal Engine adalah tugas yang masif. Anda menghabiskan berjam-jam melakukan tweaking timer handle, melakukan quantizing vector, dan memitigasi desinkronisasi hanya untuk menjaga Dedicated Server Anda berjalan mulus tanpa melampaui batas bandwidth.

Setelah kode dalam game Anda akhirnya dioptimalkan, Anda masih harus melakukan deploy dan scaling server tersebut secara global. Membangun ini sendiri membutuhkan penyiapan fleet manager, load balancer, database sharding, dan manajemen sertifikat SSL — setidaknya 4-6 minggu kerja infrastruktur intensif yang menarik Anda menjauh dari desain game yang sebenarnya.

Dengan horizOn, layanan Backend ini sudah terkonfigurasi khusus untuk pengembang game. Anda mendapatkan hosting Dedicated Server yang skalabel, sinkronisasi database real-time, dan analitik yang kuat langsung dari awal, sehingga Anda bisa merilis game Anda alih-alih merilis infrastruktur Anda.

Kesimpulan

Kunci dari unreal engine rpc optimization adalah menyadari bahwa network bandwidth adalah sumber daya yang terbatas dan sangat volatil. Anda tidak bisa memperlakukan networking layer seperti frame buffer standar. Dengan beralih dari eksekusi berbasis Tick dan menerapkan Accumulator Pattern, Anda mendapatkan kontrol total atas output data game Anda. Anda mengurangi beban server, memitigasi packet loss, dan menciptakan pengalaman yang jauh lebih mulus bagi pemain dengan koneksi internet yang fluktuatif.

Ingatlah bahwa optimasi game adalah proses yang berkelanjutan. Berhentilah mengandalkan perilaku default engine untuk menyelamatkan Anda dari network flood. Ambil kendali eksplisit atas aliran data Anda. Implementasikan rate limit ini dalam prototipe Anda saat ini, pantau metrik sebelum dan sesudah menggunakan Network Profiler, dan lihat performa server Anda meroket.

Siap untuk melakukan scaling pada Backend Multiplayer Anda yang baru dioptimalkan? Coba horizOn secara gratis atau lihat dokumentasi API untuk melihat betapa sederhananya infrastruktur game profesional.

---

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