Rebobinado en el servidor para la detección de impactos con compensación de latencia

¿A qué momento apuntó el jugador?

Un objetivo remoto que se muestra en un cliente representa un estado anterior del mundo. Cuando el ataque llega al servidor, comprobar solo la posición actual del objetivo puede contradecir lo que el jugador veía. El rebobinado en el servidor (server rewind) resuelve este problema de sincronización mediante la detección histórica de impactos; no autoriza a un cliente a declarar daño.

Historial con autoridad acotada

Riot describe cómo rebobinar el estado del objetivo hasta el momento que vio el tirador y cómo limitar ese rebobinado para gestionar la equidad. [1] La implementación de Valve conserva el historial de los jugadores, comprueba los tiempos, tiene en cuenta el retardo de interpolación y restaura el estado modificado temporalmente una vez aplicada la compensación. [2] La política exacta depende de cada juego; la detección histórica de impactos no tiene por qué volver a ejecutar toda la simulación.

Ejemplo resuelto

Supongamos un servidor hipotético que recibe un disparo en 12.000 s y valida que el momento visto por el jugador es 11.880 s. El rebobinado solicitado es de 120 ms, dentro del límite de 200 ms que este juego ha elegido. Ninguno de los dos valores es un valor por defecto de un motor.

El historial contiene posiciones del centro del objetivo de 2.0 m en 11.875 s y de 2.5 m en 11.900 s. Para un tramo en el que se permite la interpolación lineal, la fracción es (11.880 - 11.875) / (11.900 - 11.875) = 0.2, lo que da 2.1 m. Se prueba el disparo validado contra la geometría de impacto histórica de ese instante y, después, se aplica el resultado aceptado mediante las reglas autoritativas actuales del juego.

Si un teletransporte separa esas dos muestras, la interpolación inventaría posiciones que nunca existieron. Hay que marcar esa discontinuidad y usar una política explícita de rechazo o de muestreo.

Flujo de implementación

Define el alcance del rebobinado: jugadores, hitboxes animadas, puertas móviles u otros oclusores relevantes. Combinar un objetivo histórico con una cobertura actual puede producir resultados que ninguno de los participantes vio; elige y documenta la regla prevista.

Valida la secuencia del ataque, los límites de tiempo, la admisibilidad del arma, la munición y un origen de disparo plausible. No aceptes marcas de tiempo arbitrarias del cliente como solicitudes de historial con autoridad. Almacena suficientes datos de pose para reconstruir la representación de impacto elegida, incluida una identidad ligada al ciclo de vida, de modo que una entidad reciclada no herede el historial de otro objetivo.

Siempre que sea viable, prefiere consultas históricas aisladas. Si se mueven temporalmente objetos activos del mundo, garantiza su restauración en todas las rutas de salida e impide que otras partes de la jugabilidad observen ese mundo temporal.

Equidad y diagnóstico

Las ventanas de historial más amplias aceptan vistas más antiguas, pero aumentan el tiempo durante el cual se puede impactar a un defensor después de que haya llegado a una posición aparentemente segura. Las ventanas más pequeñas rechazan más ataques retrasados. Ese compromiso no se elimina con un registro perfecto.

Registra los tiempos solicitado y aceptado, la disponibilidad del historial, el motivo del rechazo y la geometría probada. Prueba latencias desiguales, retrasos en ráfagas, coberturas móviles, reapariciones y marcas de tiempo en los límites. Explica la retroalimentación de los impactos de forma coherente con la política elegida, en lugar de prometer que la imagen de cada cliente representa un único presente compartido.

Fuentes

[1] Peeking into VALORANT's netcode — Riot Games.

[2] Source SDK lag compensation — Valve.