Rollback netcode: repetición determinista y efectos secundarios controlados

Avanzar por adelantado y luego corregir

El rollback permite que un juego avance mientras aún se desconocen algunas entradas remotas. Cuando una suposición resulta errónea, la simulación vuelve a un estado anterior y se pone al día con la entrada corregida. El jugador debe recibir una respuesta local inmediata, pero la implementación tiene que poder revisitar trabajo que parecía ya realizado.

El contrato de la repetición

El rollback clásico basado solo en entradas exige una simulación determinista a partir del mismo estado y de las mismas entradas; este artículo trata esa arquitectura. Las variantes que sincronizan el estado tienen requisitos distintos. La explicación de arquitectura de SnapNet cubre la predicción de entradas, la restauración y la repetición. [1] La interfaz de integración de GGPO exige callbacks para guardar y cargar el estado del juego y para avanzar un fotograma, de modo que la gestión del estado recae en la aplicación. [2]

Ejemplo práctico

Un cliente ilustrativo ha completado el fotograma 105 tras predecir la entrada remota del fotograma 102. Llega la entrada real y es distinta. Se restaura el estado guardado al final del fotograma 101 y se simulan los fotogramas 102, 103, 104 y 105 con la entrada corregida y las entradas conservadas de cada fotograma. Son cuatro fotogramas repetidos antes de simular cualquier fotograma nuevo.

Si un estado guardado ocupa 256 KiB, conservar 8 estados cuesta 2048 KiB, es decir, 2 MiB, sin contar entradas, metadatos ni sobrecarga de asignación de memoria. Son tamaños hipotéticos, no resultados de un benchmark. Además, el estado guardado más antiguo marca hasta dónde puede restaurar este búfer en concreto; conviene indicar explícitamente si las instantáneas corresponden al inicio o al final de cada fotograma.

Flujo de trabajo de implementación

Hay que inventariar todos los valores que afectan al juego futuro: orden de creación de entidades, temporizadores, estado del generador aleatorio, tiempos de impacto que dependen de animaciones y comandos en cola. Se deben serializar o reconstruir de forma reproducible. No se debe usar la hora real del reloj ni el orden de finalización de operaciones asíncronas no controladas como entradas ocultas de la simulación.

Ejecute dos veces la misma grabación de entradas y compare por fotograma los hashes canónicos del estado. Ante la primera discrepancia, inspeccione las diferencias estructuradas del estado y no solo la posición final del personaje. Después, fuerce rollbacks incluso en una conexión local. Mida el rendimiento de la peor ventana de repetición admitida junto con el trabajo habitual de renderizado y simulación.

Efectos secundarios y límites

Asigne a los efectos predichos identidades de evento estables. Un registro de efectos permite distinguir un sonido ya reproducido de un evento recién descubierto tras la repetición. Hay que decidir qué efectos pueden cancelarse, cuáles pueden terminar a pesar de una corrección y qué resultados irreversibles esperan a la confirmación. [1]

El determinismo puede fallar por el comportamiento del punto flotante, el orden de iteración o un estado omitido. Las ventanas de predicción más largas aumentan la exposición a correcciones y el trabajo de repetición. Defina cómo recuperarse cuando la entrada es más antigua que el historial conservado o cuando se agota el presupuesto de trabajo. El retardo de entrada puede ser un control complementario deliberado; el rollback no elimina la latencia ni garantiza que las correcciones pasen inadvertidas.

Fuentes

[1] Netcode architectures: rollback — SnapNet.

[2] GGPO integration interface — Tony Cannon and GGPO contributors.