Feedback solo tras la respuesta del servidor (solicitud-respuesta) Request-response (no client-side feedback)
ID de la causa sy-request-response · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Al presionar un botón no hay animación ni sonido hasta que llega la respuesta del servidor. El ping se convierte directamente en el tiempo de respuesta.
Por qué Las habilidades, el movimiento y la recogida de objetos se reproducen solo cuando llega la confirmación del servidor → Efecto Desde que se presiona, no hay ninguna respuesta durante el tiempo de ida y vuelta + la espera del tick → En pantalla Con 150 ms de ping, todas las acciones responden 0.2 s tarde
Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Cliente: empezar las animaciones, los sonidos y los efectos en cuanto se presiona (feedback anticipado) y mostrar solo los resultados (daño, recompensas) tras la confirmación del servidor, aplicar al instante el movimiento y el ataque básico con predicción, y al recibir una corrección de posición del servidor, volver a aplicar desde esa posición los inputs que aún no se han confirmado. Servidor: calcular el movimiento a partir de los inputs recibidos y enviar una corrección solo cuando la diferencia con la posición que predijo el cliente supere un umbral.
Cifras de referencia
Tiempo de respuesta ≈ ping + la mitad del intervalo de tick + un frame. Con 20 ticks y 150 ms de ping, unos 190 ms.
En el gráfico
Siempre alto · Tiempo desde el input hasta el inicio del feedback, RTT (ping)
Dónde mirar
Registrar en el log del cliente de una build de desarrollo la hora del input, la hora de inicio de la primera animación o sonido y la hora de llegada de la respuesta del servidor, y verlas junto al RTT del juego. Medir variando el ping con la emulación de red del motor (Unreal NetEmulation.PktLag) o añadiendo latencia con tc netem de Linux en un servidor de pruebas
Se confirma si
El feedback empieza siempre en el mismo instante en que llega la respuesta del servidor, el tiempo del input al feedback equivale al RTT + la espera del tick, y crece exactamente lo que se añade de latencia
Se descarta si
Si el feedback empieza en cuanto se presiona y solo llegan tarde resultados como los números de daño, es el diseño normal. Si incluso con ping bajo el retraso supera el intervalo de tick, apunta a “Doble espera de tick” o a un problema de frames en el cliente
Se verifica con
Requiere logs y métricas del servidor o el cliente del juego
Para saber más
En juegos que no necesitan respuestas rápidas, como los de turnos, los de cartas o los idle, este modelo es el más simple y seguro. El problema aparece cuando en un juego con control en tiempo real también se hacen así el movimiento o el ataque básico.
Using Gameplay Abilities in Unreal EngineEpic Games Local Predicted se ejecuta en cuanto se presiona y el servidor decide al final; Server Initiated no tiene predicción, así que quien la usa percibe la latencia
Using Network Emulation in Unreal EngineEpic 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
tc-netem(8) — Linux manual pageiproute2 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