Reproducción al llegar, sin marcas de tiempo Events played on arrival (no timestamps)

ID de la causa sy-no-timestamp · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)

Abrir la ficha interactiva con gráficos y simulaciones →

Si los eventos del servidor no llevan la hora en que ocurrieron y se reproducen en cuanto llegan, el timing de las animaciones sigue tal cual el jitter de la red.

Por qué Los eventos “inicio de ataque” o “reproducir efecto” se ejecutan en cuanto llegan → Efecto Cada paquete tarda un tiempo distinto en llegar y los intervalos son irregulares → En pantalla Las animaciones de ataques seguidos se aceleran y se frenan, el timing de los patrones del jefe cambia cada vez

Síntomas: Tirones, Cámara rápida
Factores: Jitter
A quién afecta: Solo yo
Cuándo: Siempre
Responsable: Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo): Cliente: reproducir según la hora que trae cada evento (eventos programados, búfer de interpolación). Servidor: añadir a cada evento la hora en que ocurrió (hora del servidor).
En el gráfico: Picos aleatorios · Intervalo de reproducción de eventos, intervalo de llegada de paquetes
Dónde mirar: Emparejar por número de evento la hora en que ocurrió cada evento en el log del servidor con su hora de llegada y de reproducción en el log del cliente, y comparar los intervalos. En una build de desarrollo, reproducirlo añadiendo jitter (el valor de jitter de tc netem, la latencia mínima y máxima de la emulación de red de Unreal)
Se confirma si: Los eventos ocurren a intervalos regulares en el servidor, pero los intervalos de reproducción siguen tal cual a los de llegada y son irregulares
Se descarta si: Si los paquetes llegan a intervalos regulares y aun así la reproducción es irregular, es un problema de frames en el cliente (“Pico de frametime”). Si ya en el servidor los intervalos son irregulares, apunta a “Tick que excede su presupuesto”
Se verifica con: Requiere logs y métricas del servidor o el cliente del juego

Fuentes

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
Se añade la hora del servidor a cada actualización y se dibuja la posición correspondiente a la hora objetivo, que es la hora actual menos el tiempo de interpolación (100 ms)
Snapshot Interpolation Gaffer On Games
Si se dibuja cada snapshot en cuanto llega, el jitter produce tirones; si se acumulan un momento en el búfer de interpolación antes de dibujarlos, el movimiento es fluido
NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
Ejemplo en el que el RPC lleva la hora de envío y el receptor reproduce el efecto según la hora del servidor
tc-netem(8) — Linux manual page iproute2
Herramienta de pruebas que imita una red real añadiendo latencia y jitter (delay TIME JITTER) y pérdida (loss random PERCENT) a los paquetes salientes
Using Network Emulation in Unreal Engine Epic Games
Pruebas con latencia mínima y máxima y porcentaje de pérdida de paquetes en el servidor y el cliente; en la consola se configura con comandos como NetEmulation.PktLag

Ver también

Misma capa: Diseño del netcode

Causas de otras capas con el mismo síntoma (Tirones)

Pico de frametime L1 Proceso del juego en el cliente
Recolección de basura (GC) en el cliente L1 Proceso del juego en el cliente
Carga síncrona y compilación de shaders en el hilo principal L1 Proceso del juego en el cliente
Almacenamiento lento que retrasa el streaming de assets L1 Proceso del juego en el cliente
Carga de renderizado de multitudes L1 Proceso del juego en el cliente
Búfer de interpolación ausente o demasiado corto L1 Proceso del juego en el cliente
Extrapolación excesiva (dead reckoning) L1 Proceso del juego en el cliente
Espiral de recuperación con timestep fijo L1 Proceso del juego en el cliente

Ver la ficha interactiva con gráficos y simulaciones