Existen varios métodos para reducir o disimular los retrasos, aunque muchos de ellos tienen sus inconvenientes y pueden no ser aplicables en todos los casos. Si la sincronización no es posible por el propio juego, los clientes pueden optar por jugar en servidores próximos geográficamente a ellos para reducir las latencias, o los servidores pueden optar simplemente por dejar de lado a los clientes con altas latencias para no tener que lidiar con los problemas resultantes. Sin embargo, no son soluciones óptimas. En su lugar, los juegos se diseñarán a menudo teniendo en cuenta la compensación de lag.
Muchos problemas pueden resolverse simplemente permitiendo a los clientes hacer un seguimiento de su propio estado y enviar estados absolutos al servidor o directamente a otros clientes. Por ejemplo, el cliente puede indicar exactamente en qué posición se encuentra el personaje de un jugador o a quién ha disparado. Esta solución funciona y elimina casi todos los problemas relacionados con el lag. Por desgracia, también se basa en la suposición de que el cliente es honesto. No hay nada que impida a un jugador modificar los datos que envía, directamente en el cliente o indirectamente a través de un proxy, para asegurarse de que siempre va a dar en el blanco. En los juegos online, el riesgo de hacer trampas puede hacer inviable esta solución, y los clientes se limitarán a enviar estados relativos (es decir, en qué vector se movió o disparó).
Edición del lado del cliente
Como los clientes normalmente no pueden definir el estado principal del juego, sino que lo reciben del servidor, la principal tarea de la compensación del lado del cliente es renderizar el mundo virtual con la mayor precisión posible. Como las actualizaciones llegan con retraso e incluso pueden ser descartadas, a veces es necesario que el cliente prediga el flujo del juego. Como el estado se actualiza en pasos discretos, el cliente debe ser capaz de estimar un movimiento basándose en las muestras disponibles. Para ello, se pueden utilizar dos métodos básicos: la extrapolación y la interpolación.
La extrapolación es un intento de estimar un estado futuro del juego. Tan pronto como se recibe un paquete del servidor, la posición de un objeto se actualiza a la nueva posición. A la espera de la siguiente actualización, la siguiente posición se extrapola basándose en la posición actual y el movimiento en el momento de la actualización. Esencialmente, el cliente asumirá que un objeto en movimiento continuará en la misma dirección. Cuando se recibe un nuevo paquete, la posición puede corregirse ligeramente.
La interpolación funciona esencialmente almacenando en el buffer un estado del juego y renderizando el estado del juego al jugador con un ligero y constante retraso. Cuando llega un paquete del servidor, en lugar de actualizar la posición de un objeto inmediatamente, el cliente empezará a interpolar la posición, empezando por la última posición conocida. A lo largo de un intervalo de interpolación, el objeto se renderizará moviéndose suavemente entre las dos posiciones. Idealmente, este intervalo debería coincidir exactamente con el retardo entre paquetes, pero debido a las pérdidas y al retardo variable, esto rara vez ocurre.
Ambos métodos tienen ventajas e inconvenientes.
- La interpolación asegura que los objetos se moverán sólo entre posiciones válidas y producirá buenos resultados con un retardo constante y sin pérdidas. Si los paquetes caídos o fuera de orden desbordan el buffer de interpolación, el cliente tendrá que congelar el objeto en su posición hasta que llegue un nuevo paquete, o recurrir a la extrapolación en su lugar. La desventaja de la interpolación es que hace que el mundo se renderice con una latencia adicional, lo que aumenta la necesidad de implementar algún tipo de compensación de retardo.
- El problema de extrapolar posiciones es bastante obvio: es imposible predecir con exactitud el futuro. Sólo renderizará correctamente el movimiento si éste es constante, pero no siempre será así. Los jugadores pueden cambiar tanto de velocidad como de dirección de forma aleatoria. Esto puede dar lugar a una pequeña cantidad de «warping» a medida que llegan nuevas actualizaciones y se corrigen las posiciones estimadas, y también causar problemas para la detección de golpes, ya que los jugadores pueden ser renderizados en posiciones en las que no están realmente.
A menudo, con el fin de permitir un juego suave, se permite al cliente hacer cambios suaves en el estado del juego. Mientras que el servidor puede, en última instancia, llevar un registro de la munición, la salud, la posición, etc., se puede permitir que el cliente prediga el nuevo estado del juego del lado del servidor basándose en las acciones del jugador, como permitir que un jugador comience a moverse antes de que el servidor haya respondido al comando. Estos cambios serán generalmente aceptados en condiciones normales y harán que el retraso sea mayormente transparente. Los problemas surgirán sólo en el caso de grandes retrasos o pérdidas, cuando las predicciones del cliente sean anuladas de forma muy notable por el servidor. A veces, en el caso de diferencias menores, el servidor puede incluso permitir cambios «incorrectos» en el estado basados en las actualizaciones del cliente.
Edición del lado del servidor
A diferencia de los clientes, el servidor conoce el estado actual exacto del juego, y como tal la predicción es innecesaria. El propósito principal de la compensación de lag del lado del servidor es, en cambio, proporcionar efectos precisos de las acciones del cliente. Esto es importante porque para cuando el comando de un jugador haya llegado, el tiempo habrá avanzado, y el mundo ya no estará en el estado que el jugador vio cuando emitió su comando. Un ejemplo muy explícito de esto es la detección de impactos de armas disparadas en los shooters en primera persona, donde los márgenes son pequeños y pueden potencialmente causar problemas significativos si no se manejan adecuadamente.
Rebobinar el tiempoEditar
Otra forma de abordar el problema es almacenar los estados pasados del juego durante un cierto tiempo, y luego rebobinar las ubicaciones del jugador al procesar un comando. El servidor utiliza la latencia del jugador (incluyendo cualquier retraso inherente debido a la interpolación; véase más arriba) para rebobinar el tiempo en una cantidad apropiada con el fin de determinar lo que el cliente de disparo vio en el momento en que se disparó. Esto suele dar lugar a que el servidor vea al cliente disparando en la antigua posición del objetivo y, por tanto, acertando. En el peor de los casos, un jugador estará tan atrasado que el servidor se queda sin datos históricos y tiene que empezar a dirigir sus objetivos.
Esta es una solución WYSIWYG que permite a los jugadores apuntar directamente a lo que están viendo. Pero el precio es un agravamiento de los efectos de la latencia cuando un jugador está bajo fuego: no sólo influye su propia latencia, sino también la de su atacante. En muchas situaciones, esto no se nota, pero los jugadores que acaban de ponerse a cubierto notarán que siguen recibiendo mensajes de daño/muerte del servidor durante más tiempo del que su propia latencia puede justificar. Esto puede llevar más a menudo a la (falsa) impresión de que les dispararon a través de la cobertura y a la impresión (no del todo inexacta) de «cajas de impacto con retraso».
Una cuestión de diseño que surge del rebobinado es si se debe dejar de rebobinar los comandos con retraso de un jugador muerto tan pronto como muera en el servidor, o seguir ejecutándolos hasta que se «pongan al día» con la hora de la muerte. Cortar la compensación inmediatamente evita que las víctimas ataquen póstumamente a sus asesinos, lo que cumple con las expectativas, pero preserva la ventaja natural de los jugadores en movimiento que doblan una esquina, adquieren un objetivo y lo matan en menos tiempo que un viaje de ida y vuelta al cliente de la víctima estacionaria.
El rebobinado puede ser criticado por permitir que la alta latencia de un jugador afecte negativamente a la experiencia de los jugadores de baja latencia. Los servidores con compensación de lag a veces reducen la longitud del historial del jugador almacenado, o imponen límites de ping, para reducir este problema.
Confiar en los clientesEditar
Es posible que los clientes le digan al servidor lo que están haciendo y que el servidor confíe en los datos que recibe. Este método se evita en la medida de lo posible debido a su susceptibilidad a las trampas: es muy sencillo encaminar los datos de la red a través de un segundo ordenador que inserte mensajes de éxito fabricados o modifique los existentes, una técnica que no puede ser detectada por las herramientas antitrampas.
Sin embargo, la gran escala de algunos juegos hace que soluciones computacionalmente costosas como el rebobinado sean imposibles. En Battlefield 3, por ejemplo, se utiliza un sistema de «detección de golpes híbrido» en el que los clientes dicen al servidor que han golpeado y el servidor sólo realiza una vaga prueba de plausibilidad antes de aceptar la afirmación.
Confiar en los resultados de un cliente, por lo demás, tiene las mismas ventajas y desventajas que rebobinar.
Hacer que los clientes extrapolenEditar
Una solución de lag menos común es no hacer nada en el servidor y hacer que cada cliente extrapole (ver arriba) para cubrir su latencia. Esto produce resultados incorrectos a menos que los jugadores remotos mantengan una velocidad constante, otorgando una ventaja a aquellos que esquivan de un lado a otro o simplemente comienzan/dejan de moverse.
La extrapolación extendida también da lugar a que los jugadores remotos sean visibles (aunque no vulnerables) cuando no deberían serlo: por ejemplo, si un jugador remoto esprinta hasta una esquina y luego se detiene bruscamente en el borde, otros clientes los representarán esprintando hacia adelante, al descubierto, durante la duración de su propia latencia. En el otro lado de este problema, los clientes tienen que dar a los jugadores remotos que acaban de empezar a moverse una ráfaga extra de velocidad con el fin de empujarlos a una ubicación teóricamente precisa.
Diseño
Es posible reducir la percepción del lag a través del diseño del juego. Las técnicas incluyen la reproducción de animaciones del lado del cliente como si la acción tuviera lugar inmediatamente, la reducción/eliminación de los temporizadores incorporados en la máquina anfitriona y el uso de transiciones de cámara para ocultar el warping.