En las computadoras, el retraso es el retraso ( latencia ) entre la acción del usuario (entrada) y la reacción del servidor que respalda la tarea , que debe enviarse de vuelta al cliente .
La capacidad del jugador para tolerar el lag depende del tipo de juego que esté jugando. Por ejemplo, un juego de estrategia o un juego por turnos con un ritmo lento puede tener un umbral alto o incluso no verse afectado por un lag alto. Un juego con una mecánica de juego con tics, como un juego de disparos en primera persona o un juego de lucha con un ritmo considerablemente más rápido, puede requerir un lag significativamente menor para proporcionar una jugabilidad satisfactoria .
A la visualización de la tasa de retraso en el juego a veces se le llama lagometro . [1]
El tiempo de ping es el retraso de la red para un viaje de ida y vuelta entre el cliente de un jugador y el servidor de juego medido con la utilidad ping o equivalente. El tiempo de ping es un tiempo promedio medido en milisegundos (ms). [ cita requerida ] Cuanto más bajo sea el ping, menor será la latencia y menos retraso experimentará el jugador. Ping alto y ping bajo son términos de uso común en los juegos en línea, donde ping alto se refiere a un ping que causa una cantidad severa de retraso; mientras que cualquier nivel de ping puede causar retraso, el retraso severo generalmente se indica con un ping de más de 100 ms. [2] Este uso es un coloquialismo cultural de juegos y no se encuentra o usa comúnmente en los círculos de redes informáticas profesionales. En juegos donde el tiempo es clave, como los juegos de disparos en primera persona y los juegos de estrategia en tiempo real , un ping bajo siempre es deseable, ya que un ping bajo significa un juego más fluido al permitir actualizaciones más rápidas de los datos del juego entre los clientes de los jugadores y el servidor de juego.
Una latencia alta puede provocar retrasos. Los servidores de juegos pueden desconectar a un cliente si la latencia es demasiado alta y puede perjudicar la experiencia de juego de otros jugadores. De manera similar, el software del cliente a menudo exigirá la desconexión si la latencia es demasiado alta. Un ping alto también puede provocar que los servidores se bloqueen debido a la inestabilidad.
En algunos juegos de disparos en primera persona, un ping alto puede hacer que el jugador obtenga ventajas injustas sin querer, como desaparecer de una ubicación y reaparecer instantáneamente en otra, simulando el efecto de la teletransportación, lo que dificulta que otros jugadores calculen la posición de su personaje y, en consecuencia, hace que el jugador sea mucho más difícil de apuntar. Para contrarrestar esto, muchos servidores de juegos expulsan automáticamente a los jugadores con un ping más alto que el promedio. Por el contrario, un ping alto puede dificultar mucho que el jugador juegue debido a los efectos negativos que se producen, lo que dificulta que el jugador siga a otros jugadores e incluso mueva a su personaje.
En lugar de utilizar los paquetes de red tradicionales de solicitud y respuesta de eco ICMP para determinar los tiempos de ping, los programadores de videojuegos a menudo incorporan su propia detección de latencia en paquetes de juegos existentes (generalmente basados en el protocolo UDP ).
Algunos factores que pueden afectar el ping incluyen: el protocolo de comunicación utilizado, el rendimiento de Internet (velocidad de conexión), la calidad del proveedor de servicios de Internet de un usuario y la configuración de los firewalls . El ping también se ve afectado por la ubicación geográfica. Por ejemplo, si alguien está en la India, jugando en un servidor ubicado en los Estados Unidos, la distancia entre los dos es mayor que la que sería para los jugadores ubicados dentro de los EE. UU. y, por lo tanto, la transmisión de datos demora más. Sin embargo, la cantidad de conmutación de paquetes y hardware de red entre las dos computadoras suele ser más significativa. Por ejemplo, las tarjetas de interfaz de red inalámbrica deben modular las señales digitales en señales de radio , lo que suele ser más costoso que el tiempo que tarda una señal eléctrica en atravesar un tramo típico de cable. Como tal, un ping más bajo puede resultar en velocidades de descarga y carga de Internet más rápidas.
Mientras que un juego para un solo jugador mantiene el estado del juego principal en la máquina local, un juego en línea requiere que se mantenga en un servidor central para evitar inconsistencias entre clientes individuales. Como tal, el cliente no tiene control directo sobre el estado del juego central y solo puede enviar solicitudes de cambio al servidor, y solo puede actualizar el estado del juego local al recibir actualizaciones del servidor. Esta necesidad de comunicación causa un retraso entre los clientes y el servidor, y es la causa fundamental detrás del retraso. Si bien puede haber numerosas razones subyacentes por las que un jugador experimenta retraso, se pueden resumir como hardware insuficiente en el cliente o el servidor, o una mala conexión entre el cliente y el servidor. [3]
Los problemas relacionados con el hardware causan retrasos debido a la estructura fundamental de la arquitectura del juego. Generalmente, los juegos consisten en una secuencia de estados en bucle, o "fotogramas". Durante cada fotograma, el juego acepta la entrada del usuario y realiza los cálculos necesarios (IA, gráficos, etc.). Cuando finaliza todo el procesamiento, el juego actualizará el estado del juego y producirá una salida, como una nueva imagen en la pantalla y/o un paquete para enviar al servidor. La frecuencia con la que se generan los fotogramas se conoce a menudo como velocidad de fotogramas y retraso (videojuegos), ya que el estado central del juego se encuentra en el servidor, la información actualizada debe enviarse desde el cliente al servidor para que surta efecto. Además, el cliente debe recibir la información necesaria del servidor para actualizar completamente el estado. La generación de paquetes para enviar al servidor y el procesamiento de los paquetes recibidos solo se puede realizar con la frecuencia con la que el cliente puede actualizar su estado local. Aunque teóricamente los paquetes podrían generarse y enviarse más rápido que esto, solo daría como resultado el envío de datos redundantes si el estado del juego no se puede actualizar entre cada paquete. Por lo tanto, una velocidad de cuadros baja haría que el juego responda menos a las actualizaciones y podría obligarlo a omitir datos obsoletos.
Por el contrario, ocurre lo mismo con el servidor. La velocidad de cuadros (o tick rate) del servidor determina la frecuencia con la que puede procesar datos de los clientes y enviar actualizaciones. Este tipo de problema es difícil de predecir y compensar. Aparte de imponer requisitos mínimos de hardware e intentar optimizar el juego para obtener un mejor rendimiento, no hay formas viables de solucionarlo.
Quizás el tipo más común de retraso es causado por problemas de rendimiento de la red . Las pérdidas , la corrupción o el jitter (un paquete desactualizado es en efecto una pérdida) pueden causar problemas, pero estos problemas son relativamente raros en una red con suficiente ancho de banda y poca o ninguna congestión . En cambio, la latencia involucrada en la transmisión de datos entre clientes y servidores juega un papel importante. La latencia varía dependiendo de una serie de factores, como la distancia física entre los sistemas finales, ya que una distancia más larga significa una longitud de transmisión adicional y enrutamiento requerido y, por lo tanto, una latencia más alta. El enrutamiento a través de Internet puede ser extremadamente indirecto, lo que resulta en una longitud de transmisión mucho mayor (y la latencia consecuente) que una ruta directa, aunque el servicio de juegos en la nube OnLive ha desarrollado una solución a este problema estableciendo relaciones de emparejamiento con múltiples proveedores de servicios de Internet de red de nivel 1 y eligiendo una ruta óptima entre el servidor y el usuario. [4] Además, el ancho de banda insuficiente y la congestión, incluso si no son lo suficientemente graves como para causar pérdidas, pueden causar retrasos adicionales independientemente de la distancia. Al igual que con los problemas de hardware, los paquetes que llegan lentamente o no llegan en absoluto harán que tanto el cliente como el servidor no puedan actualizar el estado del juego de manera oportuna.
Los sistemas de juegos en línea que utilizan una red inalámbrica pueden estar sujetos a un retraso significativo, dependiendo de la arquitectura de la red inalámbrica y de la interferencia electromagnética local que afecte a esa red. La interferencia electromagnética (por ejemplo, de un horno microondas ) puede provocar que se pierdan los paquetes transmitidos, lo que requiere una retransmisión que genera latencia. Aunque la propagación de radio a través del aire es más rápida que la luz a través de una fibra óptica, los sistemas inalámbricos suelen ser compartidos entre muchos usuarios y pueden sufrir latencia debido a la congestión de la red o debido a protocolos de red que introducen latencia.
Los efectos notables del retraso varían no solo dependiendo de la causa exacta, sino también de todas las técnicas para compensar el retraso que el juego pueda implementar (descritas a continuación). Como todos los clientes experimentan algún retraso, la implementación de estos métodos para minimizar el efecto en los jugadores es importante para una jugabilidad fluida. El retraso causa numerosos problemas por cuestiones como la representación precisa del estado del juego y la detección de golpes. [5] En muchos juegos, el retraso suele estar mal visto porque interrumpe el juego normal. La gravedad del retraso depende del tipo de juego y su tolerancia inherente al retraso. Algunos juegos con un ritmo más lento pueden tolerar retrasos significativos sin necesidad de compensar en absoluto, mientras que otros con un ritmo más rápido son considerablemente más sensibles y requieren un uso extensivo de la compensación para ser jugables (como el género de disparos en primera persona). Debido a los diversos problemas que puede causar el retraso, a los jugadores que tienen una conexión a Internet insuficientemente rápida a veces no se les permite, o se les desanima de jugar con otros jugadores o servidores que tienen un host de servidor distante o tienen una alta latencia entre sí. Los casos extremos de retraso pueden resultar en una desincronización extensa del estado del juego.
El retraso debido a una tasa de actualización insuficiente entre el cliente y el servidor puede causar algunos problemas, pero estos generalmente se limitan al cliente mismo. Otros jugadores pueden notar movimientos bruscos y problemas similares con el jugador asociado con el cliente afectado, pero el problema real radica en el cliente mismo. Si el cliente no puede actualizar el estado del juego a un ritmo lo suficientemente rápido, el jugador puede ver representaciones obsoletas del juego, lo que a su vez causa varios problemas con la detección de golpes y colisiones. [6] Si la baja tasa de actualización es causada por una baja velocidad de cuadros (en lugar de una configuración en el cliente, como lo permiten algunos juegos), estos problemas generalmente se ven eclipsados por numerosos problemas relacionados con el procesamiento del lado del cliente en sí. Tanto la pantalla como los controles serán lentos y no responderán. Si bien esto puede aumentar el retraso percibido, es importante tener en cuenta que es de un tipo diferente a los retrasos relacionados con la red. En comparación, el mismo problema en el servidor puede causar problemas significativos para todos los clientes involucrados. Si el servidor no puede o no quiere aceptar paquetes de los clientes con la suficiente rapidez y procesarlos de manera oportuna, es posible que las acciones de los clientes nunca se registren. Cuando el servidor envía actualizaciones a los clientes, estos pueden experimentar bloqueos (juego que no responde) o retrocesos , según los tipos de compensación de retraso que utilice el juego, si los hay.
Por el contrario, el retraso debido a la demora de la red suele ser un problema menor. Aunque es más común, los efectos reales suelen ser menores y es posible compensar este tipo de retrasos. Sin ningún tipo de compensación de retraso, los clientes notarán que el juego responde solo un breve tiempo después de realizar una acción. Esto es especialmente problemático en los juegos de disparos en primera persona , donde es probable que los enemigos se muevan cuando un jugador intenta dispararles y el margen de error suele ser pequeño.
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 geográficamente cercanos a ellos para reducir las latencias, o los servidores pueden simplemente optar por descartar a los clientes con latencias altas para evitar tener que lidiar con los problemas resultantes. Sin embargo, estas no son soluciones óptimas. En cambio, los juegos a menudo se diseñarán teniendo en cuenta la compensación de los retrasos. [7]
Muchos problemas se pueden resolver simplemente permitiendo que los clientes lleven un registro de su propio estado y envíen estados absolutos al servidor o directamente a otros clientes. [8] Por ejemplo, el cliente puede indicar exactamente en qué posición se encuentra el personaje de un jugador o a quién disparó el personaje. Esta solución funciona y prácticamente eliminará la mayoría de los problemas relacionados con el retraso. Desafortunadamente, también se basa en el supuesto de que el cliente es honesto. No hay nada que impida que un jugador modifique los datos que envía, directamente al cliente o indirectamente a través de un proxy, para asegurarse de que siempre acertará a sus objetivos. En los juegos en línea, el riesgo de hacer trampa puede hacer que esta solución sea inviable, y los clientes se limitarán a enviar estados relativos (es decir, en qué vector se movió o disparó).
Como normalmente no se permite a los clientes definir el estado principal del juego, sino que lo reciben del servidor, la principal tarea de la compensación del lado del cliente es representar el mundo virtual con la mayor precisión posible. Como las actualizaciones se producen con retraso e incluso pueden omitirse, a veces es necesario que el cliente prediga el flujo del juego. Como el estado se actualiza en pasos discretos, el cliente debe poder estimar un movimiento en función de las muestras disponibles. Se pueden utilizar dos métodos básicos para lograr esto: extrapolación e interpolación . [8]
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 próxima actualización, la siguiente posición se extrapola en función de la posición actual y el movimiento en el momento de la actualización. Básicamente, 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 básicamente almacenando en búfer un estado del juego y mostrándoselo al jugador con un ligero retraso constante. Cuando llega un paquete del servidor, en lugar de actualizar la posición de un objeto inmediatamente, el cliente comenzará a interpolar la posición, comenzando desde la última posición conocida. Durante un intervalo de interpolación, el objeto se representará moviéndose suavemente entre las dos posiciones. Lo ideal sería que este intervalo coincidiera exactamente con el retraso entre paquetes, pero debido a la pérdida y al retraso variable, esto rara vez sucede.
Ambos métodos tienen ventajas y desventajas.
A menudo, para permitir una jugabilidad fluida, se permite al cliente realizar cambios suaves en el estado del juego. Si bien el servidor puede, en última instancia, realizar un seguimiento de la munición, la salud, la posición, etc., se puede permitir al cliente predecir el nuevo estado del juego del lado del servidor en función de las acciones del jugador, como permitir que un jugador comience a moverse antes de que el servidor haya respondido al comando. Estos cambios generalmente se aceptarán en condiciones normales y harán que el retraso sea mayormente transparente. Los problemas surgirán solo en el caso de grandes retrasos o pérdidas, cuando las predicciones del cliente sean deshechas de manera muy notable por el servidor. A veces, en el caso de diferencias menores, el servidor puede incluso permitir cambios "incorrectos" en el estado en función de las actualizaciones del cliente.
A diferencia de los clientes, el servidor conoce el estado actual exacto del juego y, como tal, no es necesario hacer predicciones. El objetivo principal de la compensación de retardo del lado del servidor es, en cambio, proporcionar efectos precisos de las acciones del cliente. Esto es importante porque, cuando llegue la orden de un jugador, el tiempo habrá pasado y el mundo ya no estará en el estado en el que el jugador vio cuando dio la orden. [9] Un ejemplo muy explícito de esto es la detección de impactos de armas disparadas en juegos de disparos en primera persona, donde los márgenes son pequeños y pueden causar problemas importantes si no se manejan adecuadamente.
Otra forma de abordar el problema es almacenar estados de juego anteriores durante un período de tiempo determinado y luego retroceder las ubicaciones de los jugadores al procesar un comando. [8] El servidor utiliza la latencia del jugador (incluido cualquier retraso inherente debido a la interpolación; consulte más arriba) para retroceder el tiempo en una cantidad adecuada con el fin de determinar lo que vio el cliente que disparó en el momento en que se disparó. Esto generalmente dará como resultado que el servidor vea al cliente disparando a la antigua posición del objetivo y, por lo tanto, acertando. En el peor de los casos, un jugador estará tan retrasado que el servidor se quedará sin datos históricos y tendrá que comenzar a adelantarse a 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 solo 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 con más frecuencia a la (falsa) impresión de que les dispararon a través de la cobertura y a la (no del todo inexacta) impresión de " hitboxes lentos ". [8]
Un problema de diseño que surge con el rebobinado es si se debe dejar de rebobinar los comandos retrasados de un jugador muerto tan pronto como muere en el servidor, o continuar ejecutándolos hasta que "alcancen" el momento 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.
Se puede criticar el rebobinado por permitir que la alta latencia de un jugador afecte negativamente la experiencia de los jugadores con baja latencia. Los servidores con compensación de retraso a veces reducen la longitud del historial del jugador almacenado o imponen límites de ping para reducir este problema.
Los clientes pueden decirle al servidor lo que están haciendo y el servidor puede confiar en los datos que recibe. Este método se evita en la medida de lo posible debido a su susceptibilidad a las trampas : es una cuestión sencilla de enrutar los datos de la red a través de un segundo ordenador que inserta mensajes de éxito inventados o modifica los existentes, una técnica que no puede ser detectada por las herramientas antitrampas . [8]
Sin embargo, la gran escala de algunos juegos hace imposible aplicar soluciones computacionalmente costosas, como el rebobinado. En Battlefield 3 , por ejemplo, se utiliza un sistema de "detección de impacto híbrido" en el que los clientes le dicen al servidor que han acertado y el servidor realiza solo una vaga prueba de verosimilitud antes de aceptar la afirmación. [10]
Confiar en los resultados de un cliente tiene las mismas ventajas y desventajas que retroceder.
Una solución de retraso menos común es no hacer nada en el servidor y hacer que cada cliente extrapole (ver arriba) para cubrir su latencia. [11] Esto produce resultados incorrectos a menos que los jugadores remotos mantengan una velocidad constante, lo que otorga una ventaja a aquellos que se mueven de un lado a otro o simplemente comienzan o dejan de moverse.
La extrapolación extendida también hace que los jugadores remotos se vuelvan visibles (aunque no vulnerables) cuando no deberían serlo: por ejemplo, si un jugador remoto corre hacia una esquina y luego se detiene abruptamente en el borde, otros clientes lo harán correr hacia adelante, hacia el espacio abierto, durante la duración de su propia latencia. Por otro lado, este problema se debe a que los clientes deben darles a los jugadores remotos que recién comenzaron a moverse una ráfaga adicional de velocidad para empujarlos hacia una ubicación prevista teóricamente precisa.
Es posible reducir la percepción de retraso mediante el diseño del juego . Las técnicas incluyen reproducir animaciones del lado del cliente como si la acción tuviera lugar inmediatamente, reducir o eliminar los temporizadores integrados en la máquina anfitriona y usar transiciones de cámara para ocultar la distorsión. [12]
Los juegos en la nube son un tipo de juego en línea en el que todo el juego se aloja en un servidor de juegos en un centro de datos, y el usuario solo ejecuta un cliente ligero localmente que reenvía las acciones del controlador de juego en sentido ascendente al servidor de juegos. A continuación, el servidor de juegos reproduce el siguiente fotograma del vídeo del juego, que se comprime mediante compresión de vídeo de bajo retardo y se envía en sentido descendente y se descomprime mediante el cliente ligero. Para que la experiencia de juego en la nube sea aceptable, el retardo de ida y vuelta de todos los elementos del sistema de juego en la nube (el cliente ligero, la conexión a Internet y/o LAN del servidor de juegos, la ejecución del juego en el servidor de juegos, la compresión y descompresión de vídeo y audio, y la visualización del vídeo en un dispositivo de visualización ) debe ser lo suficientemente bajo como para que la percepción del usuario sea que el juego se está ejecutando localmente. [4] [13] Debido a estos estrictos requisitos de retardo, entran en juego consideraciones de distancia de la velocidad de la luz a través de la fibra óptica , que actualmente limitan la distancia entre un usuario y un servidor de juegos en la nube a aproximadamente 1000 millas, según OnLive . [14] También existe mucha controversia sobre el retraso asociado con los juegos en la nube. En los juegos multijugador que utilizan una arquitectura de red cliente/servidor, la computadora del jugador renderiza los gráficos del juego localmente y solo se envía al servidor información sobre las acciones del jugador en el juego. Por ejemplo, cuando el jugador presiona un botón, el personaje en pantalla realiza instantáneamente la acción correspondiente. Sin embargo, las consecuencias de la acción, como la muerte de un enemigo, solo se ven después de un breve retraso debido al tiempo que tarda la acción en llegar al servidor. Esto solo es aceptable siempre que la respuesta a la entrada del jugador sea lo suficientemente rápida.
Al utilizar juegos en la nube, las entradas del jugador pueden provocar breves retrasos hasta que pueda ver una respuesta. Las entradas primero deben transmitirse al servidor remoto, luego el servidor debe comenzar a renderizar los gráficos de la acción que se está realizando y transmitir el video de regreso al jugador a través de la red, lo que lleva tiempo adicional. Por lo tanto, el jugador experimenta un retraso notable entre presionar un botón y ver algo que sucede en la pantalla. Dependiendo de la habilidad y la experiencia del jugador, esto puede causar desorientación y confusión similar a la retroalimentación auditiva retrasada y dificulta la navegación y la puntería en el mundo del juego. Al ingresar rápidamente un movimiento de combinación largo, el personaje en pantalla no se sincronizará con las pulsaciones de botones. Esto generalmente causa una gran confusión en el jugador que resulta en el fracaso del movimiento de combinación.
El retraso de entrada adicional también puede dificultar mucho la ejecución de ciertos juegos para un solo jugador. Por ejemplo, si un enemigo intenta golpear al jugador y se espera que este lo bloquee, cuando la pantalla del jugador muestre que el enemigo ha comenzado a atacar, el enemigo ya habrá golpeado y matado al jugador en el servidor.
Ka le o Kale , / ˈkɑːlɜː / , [15] es una jerga de juegos [16] y una frase de Internet [ 16] [17] que se refiere al retraso. [ 15 ] [16] [17] Proviene de la frase china卡了( pinyin : Kǎle ) [15] [16] [17] y se usó por primera vez en el Campeonato de Dota 2 Asia 2015 , cuando algunos jugadores chinos la escribieron en el chat para quejarse de sus molestos retrasos en el juego y solicitar una pausa. [16] [15] A medida que la escena china de Dota 2 se hizo popular, esta expresión también se hizo conocida. Muchos jugadores occidentales, tanto profesionales como aficionados, a menudo escriben "kale" en lugar de "lag" en el chat del juego y en Twitch . [17] [15]
El modelo de impacto de BF3 utiliza un modelo de servidor cliente combinado, una detección de impacto híbrida. El cliente le dice al servidor "¡Oye, le disparé!" y el servidor realiza una comprobación con la posición de los dos objetivos y determina si el jugador podría haber alcanzado razonablemente ese objetivo y luego aplica el daño.