Se predice el input del rival y se muestra por adelantado; si la predicción falla, se rebobina y se vuelve a calcular. Cuanto mayor es el ping, más hay que rebobinar.
Por qué El rival cambia de input (distinto de lo predicho) → Efecto El input real llega con un retraso de medio ping, y hay que rebobinar y recalcular ese mismo tramo → En pantalla Las animaciones del rival se saltan algunos frames o cambian de golpe
Al hacer ciertas acciones, De vez en cuando, al azar
Responsable
Responsable principal Desarrollo de cliente (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Combinar 1–3 frames de retardo de input para reducir lo que se rebobina, poner un tope al rebobinado.
Cifras de referencia
Con 100 ms de ping (50 ms en cada sentido), a 60 FPS se rebobinan unos 3 frames. Con 2 frames de retardo de input, baja a 1 frame.
En el gráfico
Picos aleatorios · Frames rebobinados, RTT (ping)
Dónde mirar
Registrar en el cliente, en cada rebobinado, los frames rebobinados, el RTT en ese momento, el retardo de input configurado y el tiempo que llevó rebobinar y recalcular
Se confirma si
En el instante en que saltaron las animaciones del rival hay muchos frames rebobinados, y el rebobinado medio es aproximadamente (latencia en un sentido − retardo de input) ÷ tiempo de frame, y crece con el ping
Se descarta si
Si hay tirones aunque se rebobine poco, es un problema de rendimiento: el recálculo supera el tiempo de un frame. Si tras rebobinar los resultados de las dos pantallas siguen siendo distintos, es una desincronización de los cálculos (desync)
Se verifica con
Requiere logs y métricas del servidor o el cliente del juego
Fuentes
GGPO Rollback Networking SDKGGPO Se predice el input del rival y se avanza; si el input real es distinto, se recalcula desde el punto de divergencia hasta el presente