Esta página aún no está traducida: se muestra la versión en inglés.

Lag Compensation

Este es el mecanismo del servidor, y aquel cuyos errores le cuestan la vida a un jugador — a favor de quien tenga la peor conexión. Todo en esta página está definido por esa asimetría.

La pregunta que responde es acotada: ¿qué vio realmente el tirador? Una acción puede llevar un tiempo de vista, el tick que el actor estaba mirando cuando actuó, y la plataforma restaura las poses de los objetivos en ese tick para que el disparo se juzgue contra lo que había en su pantalla.

El tiempo de vista es una afirmación, no un hecho

Llega del cliente, así que es una afirmación de quien llama y se trata como tal. Esto tiene dos consecuencias:

• La ventana de compensación está acotada, y fuera de ella la plataforma rechaza la acción. No extrapola para ayudar: un rechazo es una decisión que puedes ver; una extrapolación silenciosa, no.
• Leer el estado pasado de un objetivo sigue respetando la visibilidad. Preguntar por un tick histórico no es una forma de saltarse Visibility — lo que no podías ver entonces, no lo puedes leer ahora.

Y “el impacto no contó” es un veredicto, no un error: una respuesta exitosa con un motivo legible por máquina.

Lo que hace rollback se declara, y no es todo

Hacer rollback de todo produce muertes dobles: dos jugadores se disparan, ambos se rebobinan a un momento en que los dos están vivos, y los dos aciertan. No hacer rollback de nada anula la propia compensación de lag. La frontera entre ambos extremos es una lista declarada.

El rebobinado en sí le corresponde a este módulo, no a los módulos que se rebobinan. El búfer circular de historial restaura las poses del tick en disputa y luego se le hace a Collision su pregunta habitual de superposición sobre esas poses — el sistema de colisiones no guarda historial propio y nada en él sabe qué es un tick de vista. El búfer circular es la pista de historial de la entidad, no un segundo almacenamiento.

La decisión se toma sobre el pasado; el efecto se aplica en el presente

La compensación de lag responde una pregunta sobre el momento de vista del tirador. Las consecuencias — daño, muerte, recompensa — se aplican al estado actual. Lo que pasó entre el momento de vista y el momento de la decisión no se cancela ni se vuelve a calcular.

Volver a simular en el servidor queda fuera del alcance. Recalcular las consecuencias contra una nueva verdad requiere un punto de referencia fijo que el estado en punto flotante no nos da. Lo que queda es todo aquello en lo que se apoya el módulo: un cliente que vuelve a aplicar sus propias entradas sin confirmar (Predecir tu propio movimiento) y la compensación de lag como leer el pasado para una sola decisión. Así funciona en la práctica el principio “a favor del tirador” (favor the shooter).

Si vienes de otra herramienta

• Compensación de lag a favor del tirador, como la que traen la mayoría de los shooters competitivos: es el mismo mecanismo, y esta página lo describe.
• Netcode con rollback completo. El rebobinado está aquí; volver a ejecutar el mundo después, no, y el párrafo anterior explica por qué. Si tu diseño depende de que las consecuencias se recalculen a posteriori, conviene que nos plantees esa dependencia temprano en lugar de descubrirla tarde.

También conviene saber

• La implementación se puede sobrescribir. Si tu juego necesita otra regla de compensación, puedes reemplazar la nuestra, y el reemplazo declara cuáles de las declaraciones respeta.
• No hay puntos de extensión en la ruta de predicción y corrección. Esa ruta se ejecuta a la frecuencia del tick.
• Nada de esto aplica con autoridad externa. La compensación de lag existe para las salas (room) que ejecuta la simulación de la plataforma. Cuando el tick le pertenece al servidor de juego de un estudio o a un cliente maestro, la compensación le corresponde a quien lo ejecuta — consulta Quién ejecuta el tick.