Optimización de RPC en Unreal Engine: Cómo evitar la saturación de red en cada Tick

Todo desarrollador de juegos multiplayer se enfrenta tarde o temprano al mismo cuello de botella de red: un cliente que corre a 144 FPS decide enviar su estado de movimiento personalizado al servidor en cada Tick. En cuestión de segundos, la cola de red del servidor se inunda por completo con Remote Procedure Calls (RPCs) redundantes, provocando un Lag extremo, pérdida de paquetes y una desconexión inevitable. Básicamente, tu cliente está ejecutando un ataque de denegación de servicio distribuido (DDoS) contra tu propia infraestructura de servidores.

Este escenario representa uno de los errores más comunes en la arquitectura de juegos multiplayer. Cuando los desarrolladores necesitan enviar inputs de jugador personalizados, estados complejos de física de vehículos o mecánicas de disparo rápido, colocar un RPC dentro de la función Tick() parece la opción lógica para una respuesta fluida. Sin embargo, la capa de networking de Unreal Engine no descarta automáticamente los RPC intermedios. Si tu juego lanza un RPC en cada Tick, todos ellos se encolan y se transmiten.

Para las actualizaciones de movimiento y posición, casi nunca te interesan los 143 frames intermedios; solo necesitas el estado más reciente para replicarlo a los demás clientes. En esta guía completa, profundizaremos en la optimización de rpc en unreal engine, mostrándote exactamente cómo limitar estas llamadas de red basadas en el Tick, implementar una acumulación de estado inteligente y reducir drásticamente el consumo de ancho de banda en tu proyecto multiplayer.

El peligro de los eventos de red vinculados al Tick

Antes de implementar una solución, es crucial entender la anatomía del problema. Cuando declaras un RPC en Unreal Engine, ya sea Server, Client o NetMulticast, le estás indicando al controlador de red del motor que serialice los parámetros de la función y los envíe a la cola de paquetes de salida.

El problema con el encolamiento

Unreal Engine agrupa los RPC salientes en paquetes basados en el NetUpdateFrequency de la conexión y los límites de ancho de banda. Si un cliente llama a un Server RPC en cada Tick a un alto frame rate, el motor intentará procesar cada una de esas llamadas.

Si el RPC está marcado como Reliable, la situación es catastrófica. Los Reliable RPCs garantizan la entrega y el orden de ejecución. El canal de red se llenará rápidamente y, si el búfer se desborda, el motor forzará el cierre de la conexión, resultando en un jugador desconectado.

Si el RPC está marcado como Unreliable, el motor descartará paquetes cuando la cola se llene. Aunque esto evita una desconexión forzada, provoca un Rubber-banding masivo. El servidor podría recibir el frame 1, el frame 2, perder los frames 3 al 100 y luego procesar el frame 101. El resultado es un movimiento errático y brusco que arruina la experiencia de juego. Esta es una causa común cuando los equipos están corrigiendo el problema de replicación de RPC en Unreal Engine que rompe sus estados.

Las matemáticas del ancho de banda

Veamos algunos números concretos. Imagina que envías un simple vector (12 bytes) y un rotador (12 bytes) a través de un Server RPC. Con el overhead de la cabecera del RPC, estimemos 32 bytes por llamada.

• A 30 FPS: 30 * 32 bytes = 960 bytes/segundo (aprox. 1 KB/s por cliente).
• A 144 FPS: 144 * 32 bytes = 4,608 bytes/segundo (aprox. 4.6 KB/s por cliente).
• A 240 FPS: 240 * 32 bytes = 7,680 bytes/segundo.

Multiplica esto por 64 jugadores en un battle royale, y tu servidor estará procesando repentinamente casi medio megabyte de puro overhead de RPC cada segundo, solo para el seguimiento básico del movimiento. Esto no es escalable.

Paso 1: Romper la dependencia del Tick con un patrón de acumulador

La estrategia más efectiva para la optimización de rpc en unreal engine es desacoplar tu tasa de envío de red del frame rate de renderizado del cliente. En lugar de lanzar el RPC en Tick(), debes actualizar una variable local en cada Tick y luego usar un temporizador para enviar esos datos al servidor en un intervalo fijo y predecible (por ejemplo, 10 o 20 veces por segundo).

Llamamos a esto el Patrón de Acumulador. El cliente acumula el estado más reciente de forma continua, pero solo transmite cuando la compuerta de red se abre.

Identificación de la frecuencia objetivo

No necesitas 144 actualizaciones por segundo para una experiencia multiplayer fluida. La mayoría de los shooters competitivos modernos corren sus servidores a 30Hz o 60Hz. Por lo tanto, enviar actualizaciones del cliente de 15 a 30 veces por segundo suele ser más que suficiente, siempre que utilices un Client-side prediction y Server-side interpolation adecuados.

Al reducir la tasa de envío de un 144Hz sin límite a un 20Hz limitado, reduces instantáneamente tu tráfico de red en más de un 85% para esa acción específica.

Paso 2: Implementar el Rate-Limiter en C++

Veamos cómo implementar esto de manera efectiva en C++. Crearemos un sistema donde el cliente rastrea su ubicación y rotación objetivo en cada Tick, pero solo envía el RPC Server_UpdateTransform basándose en una tasa de envío de red predefinida.

El archivo de cabecera (.h)

Primero, definimos nuestras variables y funciones en nuestra clase personalizada APawn o ACharacter. Necesitamos un handle de temporizador, una tasa de actualización y las variables para almacenar nuestros datos aún no enviados.

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;

    // El RPC para enviar datos al servidor. Marcado como Unreliable para actualizaciones rápidas y continuas.
    UFUNCTION(Server, Unreliable, WithValidation)
    void Server_SendTransformUpdate(FVector NewLocation, FRotator NewRotation);

private:
    // Timer handle para nuestro envío de red
    FTimerHandle NetworkUpdateTimerHandle;

    // Cuántas veces por segundo queremos enviar actualizaciones al servidor
    UPROPERTY(EditDefaultsOnly, Category = "Network")
    float NetworkSendRate;

    // Flag para rastrear si tenemos nuevos datos que aún no se han enviado
    bool bHasPendingNetworkUpdate;

    // Los datos acumulados esperando ser enviados
    FVector PendingLocation;
    FRotator PendingRotation;

    // La función llamada por el temporizador para enviar los datos
    void FlushNetworkUpdate();
};

El archivo fuente (.cpp)

Ahora, implementamos la lógica. Configuramos el temporizador en BeginPlay, actualizamos nuestras variables pendientes en Tick y dejamos que el temporizador se encargue de la transmisión de red real.

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

AMyCustomPawn::AMyCustomPawn()
{
    PrimaryActorTick.bCanEverTick = true;
    
    // Por defecto enviamos 20 actualizaciones por segundo
    NetworkSendRate = 20.0f; 
    bHasPendingNetworkUpdate = false;
}

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

    // Solo el cliente que controla localmente debe ejecutar el temporizador de envío de red
    if (IsLocallyControlled())
    {
        float UpdateInterval = 1.0f / NetworkSendRate; // ej., 1.0 / 20.0 = 0.05 segundos

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

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

    // Ejecuta aquí tu lógica de movimiento personalizada del cliente
    // ej., FVector NewLoc = ...; FRotator NewRot = ...;
    // SetActorLocationAndRotation(NewLoc, NewRot);

    if (IsLocallyControlled())
    {
        // En lugar de llamar al RPC aquí, simplemente almacenamos el último estado
        PendingLocation = GetActorLocation();
        PendingRotation = GetActorRotation();
        
        // Marcamos que tenemos datos frescos esperando ser enviados
        bHasPendingNetworkUpdate = true;
    }
}

void AMyCustomPawn::FlushNetworkUpdate()
{
    // Si no hay datos nuevos (ej., el jugador está quieto), no desperdicies ancho de banda
    if (!bHasPendingNetworkUpdate)
    {
        return;
    }

    // Envía el último estado acumulado al servidor
    Server_SendTransformUpdate(PendingLocation, PendingRotation);

    // Reinicia el flag hasta que el próximo tick modifique el estado de nuevo
    bHasPendingNetworkUpdate = false;
}

bool AMyCustomPawn::Server_SendTransformUpdate_Validate(FVector NewLocation, FRotator NewRotation)
{
    // Añade aquí validación anti-cheat. ¿Es razonable la ubicación?
    return true; 
}

void AMyCustomPawn::Server_SendTransformUpdate_Implementation(FVector NewLocation, FRotator NewRotation)
{
    // El servidor recibe los datos con limitación de tasa y los aplica
    SetActorLocationAndRotation(NewLocation, NewRotation);
    
    // Nota: El servidor luego replicaría esto a otros clientes, 
    // típicamente a través de propiedades Replicated estándar, NO mediante Multicasting.
}

Por qué funciona esta arquitectura

Esta configuración resuelve elegantemente el problema de la inundación de red. No importa si el cliente corre a 30 FPS o a 300 FPS, se garantiza que el servidor recibirá exactamente la cantidad de actualizaciones por segundo definida en NetworkSendRate (asumiendo que no hay pérdida de paquetes).

Además, implementamos una comprobación de salida temprana (!bHasPendingNetworkUpdate). Si el jugador se aleja del teclado, el cliente deja de enviar RPCs por completo, liberando ancho de banda crítico para los jugadores activos. Esta es una victoria masiva para mantener un rendimiento constante del servidor.

Paso 3: Manejo de la interpolación de estados en otros clientes

Cuando reduces la tasa de envío de red, el movimiento en el servidor (y, por consiguiente, en los otros clientes conectados) se volverá entrecortado. Si envías actualizaciones a 10Hz, el personaje se teletransportará visiblemente 10 veces por segundo en un monitor de 60 FPS.

Para solucionar esto, no puedes simplemente ajustar el personaje a la nueva ubicación. Debes usar interpolación. Cuando el servidor replica la NewLocation a los Simulated proxies (los otros clientes que observan al jugador), esos clientes deben realizar un FMath::VInterpTo fluido desde su posición actual a la posición objetivo replicada a lo largo del tiempo.

Esto garantiza que, incluso con un límite de tasa muy agresivo (como 5 o 10 actualizaciones por segundo), la representación visual permanezca fluida. Si tienes problemas con personajes que se ajustan incorrectamente durante la interpolación, podrías revisar cómo solucionar el desincronismo de la ubicación del jugador en UEFN y Unreal Engine multiplayer.

Paso 4: Batching de estructuras para RPC complejos

Si tu juego requiere enviar múltiples variables diferentes, no envíes múltiples RPC por separado. Cada RPC tiene un overhead de cabecera base (normalmente alrededor de 1-2 bytes como mínimo, pero prácticamente más al considerar la serialización del payload).

Si llamas a Server_SendHealth(), Server_SendArmor() y Server_SendPosition() en el mismo envío de red, estás pagando el coste de la cabecera tres veces.

En su lugar, crea una Struct dedicada para tus payloads de red.

USTRUCT()
struct FPlayerNetworkState
{
    GENERATED_BODY()

    UPROPERTY()
    FVector Location;

    UPROPERTY()
    FRotator Rotation;

    UPROPERTY()
    uint8 CurrentWeaponIndex;

    UPROPERTY()
    bool bIsCrouching;
};

Pasa esta única estructura a través de tu RPC basado en temporizador. El sistema de reflexión de Unreal Engine empaquetará estas variables de manera eficiente en un solo payload de paquete, minimizando la huella de bytes en tu conexión.

5 mejores prácticas para la optimización de RPC en Unreal Engine

Para asegurar que tu juego escale de pruebas locales a miles de jugadores concurrentes, adopta estas reglas fundamentales para la arquitectura de red:

1. Nunca envíes RPCs en el Tick sin una compuerta: Considéralo una regla inquebrantable. Si un RPC está dentro de Tick(), debe estar protegido por una comprobación de tiempo (ej., if (TimeSinceLastRPC > 0.1f)) o gestionado mediante un temporizador en bucle.
2. Prioriza Unreliable sobre Reliable: Para datos que se actualizan continuamente (movimiento, rotación de cámara, armas de rayo continuo), utiliza siempre Unreliable RPCs. Si un paquete se pierde, el siguiente que llegue una fracción de segundo después lo sobrescribirá de todos modos. Los Reliable RPCs deben reservarse estrictamente para cambios de estado absolutos (ej., disparo de arma, objeto recogido, muerte del jugador).
3. Usa cuantización para Floats y Vectors: Al enviar datos FVector, rara vez necesitas precisión total de punto flotante. Unreal Engine te permite cuantizar vectores en los RPC (ej., FVector_NetQuantize100), lo que redondea los valores a dos decimales y reduce drásticamente el ancho de banda necesario.
4. Prefiere la replicación estándar para datos descendentes: Aunque los clientes deben usar RPC para enviar datos al servidor, el servidor rara vez debería usar Multicast RPCs para enviar datos continuos hacia abajo. El servidor debería actualizar una variable UPROPERTY(Replicated), permitiendo que el gestor de replicación integrado de Unreal maneje la optimización del ancho de banda, la priorización y la relevancia de forma automática.
5. Perfile pronto y con frecuencia: Utiliza el comando net.DumpRelevantActors y la herramienta Network Profiler (NetworkProfiler.exe ubicada en los binarios del Engine) para visualizar exactamente cuántos bytes están consumiendo tus RPC por frame. Nunca adivines tus ganancias de optimización; mídela de forma empírica.

Gestión de infraestructura y escalado de Backend

Dominar los entresijos del Netcode de Unreal Engine es una tarea titánica. Pasas horas ajustando handles de temporizadores, cuantizando vectores y mitigando desincronismos solo para que tus Dedicated Servers funcionen sin desbordar sus límites de ancho de banda.

Una vez que tu código de juego está finalmente optimizado, todavía tienes que desplegar y escalar esos servidores globalmente. Construir esto por tu cuenta requiere configurar gestores de flotas, balanceadores de carga, sharding de bases de datos y gestión de certificados SSL; fácilmente de 4 a 6 semanas de trabajo intensivo en infraestructura que te aleja del diseño real del juego.

Con horizOn, estos servicios de Backend vienen preconfigurados específicamente para desarrolladores de juegos. Obtienes hosting de Dedicated Servers escalables, sincronización de bases de datos en tiempo real y análisis robustos desde el primer momento, permitiéndote lanzar tu juego en lugar de tu infraestructura.

Reflexiones finales

La clave de la optimización de rpc en unreal engine es darse cuenta de que el ancho de banda de red es un recurso finito y altamente volátil. No puedes tratar la capa de red como un búfer de frames estándar. Al alejarte de la ejecución impulsada por el Tick y adoptar el Patrón de Acumulador, obtienes un control total sobre la salida de datos de tu juego. Reduces la carga del servidor, mitigas la pérdida de paquetes y creas una experiencia drásticamente más fluida para los jugadores con conexiones de internet inestables.

Recuerda que optimizar tu juego es un proceso continuo. Deja de confiar en los comportamientos por defecto del motor para salvarte de las inundaciones de red. Toma el control explícito de tu flujo de datos. Implementa estos límites de tasa en tu prototipo actual, monitoriza las métricas antes y después usando el Network Profiler y observa cómo se dispara el rendimiento de tu servidor.

¿Listo para escalar tu Backend multiplayer recién optimizado? Prueba horizOn gratis o consulta la documentación de la API para ver qué tan sencilla puede ser una infraestructura de juegos profesional.

---

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