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 regreso al cliente .
La capacidad del jugador para tolerar el retraso depende del tipo de juego que se 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 retraso alto. Un juego con jugabilidad de contracción , como un juego de disparos en primera persona o un juego de lucha con un ritmo considerablemente más rápido, puede requerir un retraso significativamente menor para brindar una jugabilidad satisfactoria .
Una visualización de la tasa de retraso en el juego a veces se denomina lagómetro . [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 del juego , medido con la utilidad ping o equivalente. El tiempo de ping es un tiempo promedio medido en milisegundos (ms). [ cita necesaria ] 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 comúnmente utilizados en los juegos en línea, donde ping alto se refiere a un ping que causa un retraso severo; Si bien cualquier nivel de ping puede provocar un retraso, un retraso grave suele indicarse con un ping de más de 100 ms. [2] Este uso es un coloquialismo cultural sobre juegos y no se encuentra ni se utiliza comúnmente en los círculos profesionales de redes informáticas. En juegos donde el tiempo es clave, como los juegos de disparos en primera persona y de estrategia en tiempo real , siempre es deseable un ping bajo, 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 del juego.
La latencia alta puede provocar retrasos. Los servidores del juego pueden desconectar un cliente si la latencia es demasiado alta y puede perjudicar el juego de otros jugadores. De manera similar, el software cliente a menudo exigirá la desconexión si la latencia es demasiado alta. Un ping alto también puede provocar que los servidores colapsen debido a la inestabilidad.
En algunos juegos de disparos en primera persona, un ping alto puede hacer que el jugador obtenga involuntariamente ventajas injustas, como desaparecer de un lugar y reaparecer instantáneamente en otro, simulando el efecto de teletransportación, lo que dificulta que otros jugadores juzguen el comportamiento de su personaje. posición y, posteriormente, hacer 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 superior al promedio. Por el contrario, un ping alto puede hacer que al jugador le resulte muy difícil jugar debido a los efectos negativos que se producen, lo que dificulta que el jugador rastree a otros jugadores e incluso mueva su personaje.
En lugar de utilizar los tradicionales paquetes de red de solicitud y respuesta de eco ICMP para determinar los tiempos de ping, los programadores de videojuegos a menudo crean 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, los datos tardan más en transmitirse. 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 tasas de carga y descarga de Internet más rápidas.
Mientras que un juego para un solo jugador mantiene el estado principal del juego 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 central del juego y solo puede enviar solicitudes de cambio al servidor, y solo puede actualizar el estado del juego local recibiendo actualizaciones del servidor. Esta necesidad de comunicarse provoca un retraso entre los clientes y el servidor, y es la causa fundamental del retraso. Si bien puede haber numerosas razones subyacentes por las que un jugador experimenta retrasos, se pueden resumir como hardware insuficiente en el cliente o en el servidor, o una mala conexión entre el cliente y el servidor. [3]
Los problemas relacionados con el hardware provocan retrasos debido a la estructura fundamental de la arquitectura del juego. Generalmente, los juegos constan de una secuencia en bucle de estados o "cuadros". Durante cada cuadro, el juego acepta la entrada del usuario y realiza los cálculos necesarios (IA, gráficos, etc.). Cuando finalice todo el procesamiento, el juego actualizará el estado del juego y producirá un resultado, como una nueva imagen en la pantalla y/o un paquete para enviar al servidor. La frecuencia con la que se generan fotogramas a menudo se denomina velocidad de fotogramas y Lag (videojuegos). Dado que el estado central del juego se encuentra en el servidor, la información actualizada debe enviarse desde el cliente al servidor para que tenga efecto. Además, el cliente debe recibir la información necesaria del servidor para poder actualizar completamente el estado. La generación de paquetes para enviar al servidor y el procesamiento de los paquetes recibidos solo se pueden realizar con la frecuencia con la que el cliente pueda actualizar su estado local. Aunque en teoría los paquetes podrían generarse y enviarse más rápido que esto, solo resultaría en el envío de datos redundantes si el estado del juego no se puede actualizar entre cada paquete. Por lo tanto, una velocidad de fotogramas baja haría que el juego respondiera menos a las actualizaciones y podría obligarlo a omitir datos obsoletos.
Por el contrario, lo mismo se aplica al servidor. La velocidad de cuadros (o velocidad de ticks) del servidor determina con qué frecuencia 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 de retraso más común sea causado por problemas de rendimiento de la red . Las pérdidas , la corrupción o la fluctuación (un paquete desactualizado es, de hecho, 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 y enrutamiento adicionales necesarios 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 consiguiente latencia) que una ruta directa, aunque el servicio de juegos en la nube OnLive ha desarrollado una solución a este problema al establecer relaciones de intercambio de tráfico con múltiples proveedores de servicios de Internet de red de nivel 1. y elegir 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 hacen 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 retrasos significativos, dependiendo de la arquitectura de la red inalámbrica y de la interferencia electromagnética local que afecta a esa red. La interferencia electromagnética (por ejemplo, de un horno microondas ) puede provocar la pérdida de 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 de la luz a través de una fibra óptica, los sistemas inalámbricos a menudo se comparten entre muchos usuarios y pueden sufrir latencia debido a la congestión de la red o a protocolos de red que introducen latencia.
Los efectos notables del retraso varían no sólo 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, implementar estos métodos para minimizar el efecto en los jugadores es importante para un juego fluido. El retraso causa numerosos problemas, 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 de su tolerancia inherente al retraso. Algunos juegos con un ritmo más lento pueden tolerar retrasos significativos sin necesidad de compensación alguna, mientras que otros con un ritmo más rápido son considerablemente más sensibles y requieren un uso extensivo de compensación para poder jugarlos (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 desaconseja jugar con otros jugadores o servidores que tienen un servidor distante o tienen una alta latencia entre sí. Los casos extremos de retraso pueden provocar una desincronización generalizada del estado del juego.
El retraso debido a una velocidad de actualización insuficiente entre el cliente y el servidor puede causar algunos problemas, pero generalmente se limitan al propio cliente. Otros jugadores pueden notar movimientos entrecortados y problemas similares con el jugador asociado con el cliente afectado, pero el verdadero problema radica en el cliente mismo. Si el cliente no puede actualizar el estado del juego a un ritmo lo suficientemente rápido, es posible que se muestren al jugador versiones 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 fotogramas (a diferencia 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 . Tanto la pantalla como los controles estarán lentos y no responderán. Si bien esto puede aumentar el retraso percibido, es importante señalar 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 importantes a todos los clientes involucrados. Si el servidor no puede o no quiere aceptar paquetes de clientes lo suficientemente rápido y procesarlos de manera oportuna, es posible que las acciones del cliente nunca se registren. Cuando el servidor envía actualizaciones a los clientes, es posible que experimenten congelaciones (juego que no responde) y/o retrocesos , dependiendo de qué tipos de compensación de retraso, si corresponde, utiliza el juego.
El retraso debido a retrasos en la red, por el contrario, suele ser un problema menor. Aunque son más comunes, los efectos reales son generalmente menores y es posible compensar este tipo de retrasos. Sin ningún tipo de compensación por retraso, los clientes notarán que el juego responde poco 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 mediante el juego en sí, los clientes pueden optar por jugar en servidores cercanos geográficamente a ellos para reducir las latencias, o los servidores pueden simplemente optar por eliminar clientes con latencias altas para evitar tener que abordar los problemas resultantes. Sin embargo, estas no son soluciones óptimas. En cambio, los juegos suelen diseñarse teniendo en cuenta la compensación del retraso. [7]
Muchos problemas se pueden resolver simplemente permitiendo a los clientes realizar un seguimiento de su propio estado y enviar 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 a un jugador modificar los datos que envía, directamente al cliente o indirectamente a través de un proxy, para garantizar que siempre alcanzará sus objetivos. En los juegos en línea, el riesgo de hacer trampa puede hacer que esta solución sea inviable, y los clientes estarán limitados a enviar estados relativos (es decir, en qué vector se movió o en qué vector disparó).
Como normalmente a los clientes no se les permite definir el estado principal del juego, sino recibirlo del servidor, la tarea principal de la compensación del lado del cliente es representar el mundo virtual con la mayor precisión posible. Como las actualizaciones llegan con retraso e incluso pueden eliminarse, a veces es necesario que el cliente prediga el flujo del juego. Dado que 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 el 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 esencialmente almacenando en búfer el estado del juego y mostrándolo al jugador con un retraso ligero y 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. Idealmente, este intervalo debería coincidir exactamente con el retraso entre paquetes, pero debido a la pérdida y al retraso variable, este rara vez es el caso.
Ambos métodos tienen ventajas e inconvenientes.
A menudo, para permitir un juego fluido, el cliente puede realizar cambios suaves en el estado del juego. Si bien el servidor puede, en última instancia, realizar un seguimiento de las municiones, la salud, la posición, etc., se le 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 en gran medida transparente. Los problemas surgirán sólo en el caso de grandes retrasos o pérdidas, cuando el servidor deshaga notablemente las predicciones del cliente. A veces, en el caso de diferencias menores, el servidor puede incluso permitir cambios "incorrectos" en el estado según las actualizaciones del cliente.
A diferencia de los clientes, el servidor conoce exactamente el estado actual del juego y, como tal, la predicción es innecesaria. El objetivo principal de la compensación del retraso del lado del servidor es proporcionar efectos precisos de las acciones del cliente. Esto es importante porque cuando llegue la orden de un jugador, el tiempo habrá avanzado y el mundo ya no estará en el estado que vio el jugador cuando emitió su orden. [9] Un ejemplo muy explícito de esto es la detección de impactos en 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 anteriores del juego durante un período de tiempo determinado y luego rebobinar 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; ver arriba) para rebobinar el tiempo en una cantidad adecuada para determinar qué 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, acertará. En el peor de los casos, un jugador estará tan atrasado que el servidor se quedará sin datos históricos y tendrá que empezar a liderar 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 una cobertura y a la impresión (no del todo inexacta) de " hitboxes retrasados ". [8]
Un problema de diseño que surge al rebobinar es si se deben 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 mover a los jugadores 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 duración del historial del jugador almacenado o imponen límites de ping para reducir este problema.
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 sencillo enrutar los datos de la red a través de una segunda computadora que inserta mensajes de éxito inventados o modifica los existentes, una técnica que no puede ser detectada por las herramientas anti-trampas . [8]
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 impacto híbrido" donde los clientes le dicen al servidor que han golpeado y el servidor realiza sólo una vaga prueba de plausibilidad antes de aceptar el reclamo. [10]
De lo contrario, confiar en los resultados de un cliente tiene las mismas ventajas y desventajas que rebobinar.
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, otorgando una ventaja a aquellos que esquivan hacia adelante y hacia atrás o simplemente comienzan o dejan de moverse.
La extrapolación extendida también da como resultado 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. mientras dure 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 para empujarlos a 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 temporizadores integrados en la máquina host y usar transiciones de cámara para ocultar la deformación. [12]
Los juegos en la nube son un tipo de juego en línea en el que todo el juego está alojado 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 del juego al servidor del juego. Luego, el servidor del juego procesa el siguiente fotograma del vídeo del juego, que se comprime utilizando una compresión de vídeo de bajo retraso y el cliente ligero lo envía en sentido descendente y lo descomprime. Para que la experiencia de juego en la nube sea aceptable, el retraso 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, el servidor del juego, la ejecución del juego en el servidor del juego, el vídeo y el audio compresión y descompresión, y la visualización del video en un dispositivo de visualización ) deben ser lo suficientemente bajos como para que la percepción del usuario sea que el juego se está ejecutando localmente. [4] [13] Debido a requisitos de retraso tan estrictos, entran en juego consideraciones de distancia de la velocidad de la luz a través de la fibra óptica , lo que actualmente limita 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 representa 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 sólo es aceptable siempre que la respuesta a la entrada del jugador sea lo suficientemente rápida.
Cuando se utilizan juegos en la nube, las aportaciones 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 representar los gráficos de la acción que se está realizando y transmitir el video al reproductor 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 que algo sucede en la pantalla. Dependiendo de la habilidad y experiencia del jugador, esto puede causar desorientación y confusión similar a la retroalimentación auditiva retardada y dificulta la navegación y la puntería en el mundo del juego. Al ingresar rápidamente un movimiento combinado largo, el personaje en pantalla no se sincronizará con las pulsaciones de los botones. Esto suele causar una gran confusión en el jugador, lo que provoca el fracaso del movimiento combinado.
El retraso de entrada adicional también puede hacer que sea muy difícil jugar ciertos juegos para un solo jugador. Por ejemplo, si un enemigo golpea al jugador y se espera que el jugador 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.
El modelo de visitas de BF3 utiliza un modelo de servidor cliente combinado, una detección de visitas híbrida. El cliente le dice al servidor "¡Oye, le disparé!" y el servidor verifica la posición de los dos objetivos y determina si el jugador podría haber golpeado razonablemente ese objetivo y luego aplica el daño.