Articulo de referencia

Retraso (videojuegos)

En informática, el retardo es el tiempo ( latencia ) entre la acción del usuario (entrada) y la reacción del servidor que soporta la tarea , que debe enviarse de vuelta al clien...

En informática, el retardo es el tiempo ( latencia ) entre la acción del usuario (entrada) y la reacción del servidor que soporta la tarea , que debe enviarse de vuelta al cliente .

La capacidad del jugador para tolerar el retardo depende del tipo de juego. Por ejemplo, un juego de estrategia o por turnos de ritmo lento puede tener un umbral alto o incluso no verse afectado en gran medida por un retardo elevado. Un juego con una jugabilidad frenética , como un juego de disparos en primera persona o un juego de lucha con un ritmo considerablemente más rápido, puede requerir un retardo significativamente menor para ofrecer una experiencia de juego satisfactoria .

El lag se mide principalmente en milisegundos (ms) y puede mostrarse en el juego (a veces llamado lagómetro ). [ 1 ] Las causas más comunes del lag se expresan como tiempo de ping (o simplemente ping ) y la velocidad de fotogramas (fps). Generalmente, se considera que un lag inferior a 100 ms (10 Hz o fps) es necesario para la jugabilidad. El ping más bajo físicamente posible para una conexión entre puntos opuestos en la Tierra que cruzan la mitad del planeta es de 133 ms. Otras causas del lag suelen resultar en un lag inferior a un lag jugable de 20 ms (50  Hz o fps), o en la pérdida , corrupción o fluctuación del juego.

Causas

Una arquitectura de juego simplificada

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 los clientes individuales. Por lo tanto, 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 local del juego recibiendo actualizaciones del servidor. Esta necesidad de comunicación provoca un retraso entre los clientes y el servidor, y es la causa fundamental del lag. Si bien puede haber numerosas razones subyacentes por las que un jugador experimenta lag, las más comunes son una mala conexión entre el cliente y el servidor, o un procesamiento insuficiente en el cliente o el servidor. [ 2 ]

Conexión

Quizás el tipo de retardo más común se deba a problemas de rendimiento de la red . Las pérdidas , la corrupción o la fluctuación (un paquete obsoleto es, en efecto, una pérdida) pueden causar problemas, pero estos 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 servidor juega un papel importante. La latencia varía según varios factores, como la distancia física entre los sistemas finales, ya que una mayor distancia implica una mayor longitud de transmisión y enrutamiento , y por lo tanto, una mayor latencia. 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 estableciendo relaciones de interconexión con múltiples proveedores de servicios de Internet de red de nivel 1 y eligiendo una ruta óptima entre el servidor y el usuario. [ 3 ]

Tiempo de ping

El tiempo de ping, o simplemente ping, es la principal medida de la latencia de conexión. El tiempo de ping es el retardo de 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). Cuanto menor sea el ping, menor será la latencia y menor será la latencia que experimentará el jugador. Los términos "ping alto" y "ping bajo" se usan comúnmente en los juegos en línea, donde "ping alto" se refiere a un ping que causa una cantidad considerable de latencia; si bien cualquier nivel de ping puede causar latencia, una latencia severa generalmente se indica con un ping superior a 100 ms. [ 4 ] Este uso es un coloquialismo cultural de los juegos y no se encuentra ni se usa comúnmente en los círculos profesionales de redes informáticas. 

Algunos factores que pueden afectar particularmente al ping incluyen: el protocolo de comunicación utilizado, el rendimiento de Internet (velocidad de conexión), la calidad del proveedor de servicios de Internet del usuario y la configuración de los cortafuegos . El ping también se ve afectado por la ubicación geográfica. Por ejemplo, si alguien está en India, jugando en un servidor ubicado en Estados Unidos, la distancia entre ambos es mayor que si los jugadores estuvieran dentro de EE. UU., y por lo tanto, la transmisión de datos tarda más, resultando en un ping de 133 ms a 20 000  km ( la mitad de la circunferencia de la Tierra ). [ 5 ] Sin embargo, la cantidad de conmutación de paquetes y hardware de red entre los dos ordenadores suele ser más significativa. Por ejemplo, las tarjetas de interfaz de red inalámbricas 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 recorrer un tramo típico de cable. Por lo tanto, un ping más bajo puede resultar en velocidades de descarga y carga de Internet más rápidas.

Interfaz

retardo de entrada

El retardo de entrada o latencia de entrada es el retardo producido por el dispositivo de entrada , como un ratón, teclado u otro controlador, y su conexión. Los dispositivos inalámbricos se ven particularmente afectados por este tipo de retardo. [ 6 ] Algunas personas afirman notar un retardo adicional al usar un controlador inalámbrico, mientras que otras afirman que el retardo de 4 a 8 milisegundos es insignificante. [ 7 ] La frecuencia de actualización es un tipo o parte del retardo de entrada que es la frecuencia con la que una pantalla produce una imagen nítida, medida en Hz (por ejemplo, 60, 240 o 360, que son 16,7, 4,2 o 2,8 ms respectivamente). [ 8 ]

Retraso de visualización

Este es el retardo causado por el televisor o monitor (también llamado retardo de salida ). Además de la latencia impuesta por el tiempo de respuesta de píxeles de la pantalla , cualquier procesamiento de imagen (como el escalado , el suavizado de movimiento o el suavizado de bordes ) lleva tiempo y, por lo tanto, agrega más retardo de entrada. Un retardo de entrada inferior a 30 ms generalmente se considera imperceptible en un televisor . [ 9 ] Una vez que se ha procesado el fotograma, el paso final es la actualización de los píxeles para mostrar el color correcto para el nuevo fotograma. El tiempo que esto lleva se llama tiempo de respuesta de píxeles .

Efectos

Los efectos perceptibles del lag varían no solo según la causa exacta, sino también según las técnicas de compensación de lag que el juego pueda implementar (descritas a continuación). Dado que todos los clientes experimentan cierto retraso, implementar estos métodos para minimizar el efecto en los jugadores es importante para una experiencia de juego fluida. El lag causa numerosos problemas en cuestiones como la representación precisa del estado del juego y la detección de impactos. [ 10 ] En muchos juegos, el lag suele ser mal visto porque interrumpe la jugabilidad normal. La gravedad del lag depende del tipo de juego y su tolerancia inherente al lag. 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 extenso 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 lag, a los jugadores con 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 host de servidor distante o que tienen una alta latencia entre sí. Los casos extremos de lag pueden resultar en una desincronización extensa del estado del juego.

El retardo debido a una frecuencia de actualización insuficiente entre el cliente y el servidor puede causar algunos problemas, pero estos generalmente se limitan al propio cliente. Otros jugadores pueden notar movimientos bruscos y problemas similares con el jugador asociado al cliente afectado, pero el verdadero problema reside en el cliente. Si el cliente no puede actualizar el estado del juego con la suficiente rapidez, el jugador puede ver versiones desactualizadas del juego, lo que a su vez causa varios problemas con la detección de impactos y colisiones. [ 11 ]

Las pruebas han demostrado que un retardo de entrada general (desde la entrada humana hasta la respuesta visual) de aproximadamente 200 ms resulta molesto para el usuario. Asimismo, parece que (excluyendo el retardo de la pantalla del monitor/televisor ) un tiempo de respuesta promedio es de 133 ms , y los juegos más sensibles ( juegos de lucha , juegos de disparos en primera persona y juegos de ritmo ) alcanzan tiempos de respuesta de 67 ms (excluyendo el retardo de la pantalla). [ 12 ]

Soluciones y compensación de retrasos

Existen diversos métodos para reducir o disimular los retrasos, aunque muchos de ellos presentan inconvenientes y no siempre son aplicables. Si el juego no permite la sincronización, los clientes pueden optar por jugar en servidores cercanos geográficamente para reducir la latencia, o bien los servidores pueden simplemente desconectar a los clientes con alta latencia para evitar los problemas derivados. Sin embargo, estas soluciones no son óptimas. Por lo general, los juegos se diseñan teniendo en cuenta la compensación de latencia. [ 13 ]

Muchos problemas se pueden resolver simplemente permitiendo que los clientes registren su propio estado y envíen estados absolutos al servidor o directamente a otros clientes. [ 14 ] Por ejemplo, el cliente puede indicar con exactitud en qué posición se encuentra el personaje de un jugador o a quién disparó. Esta solución funciona y prácticamente elimina la mayoría de los problemas relacionados con el lag. Desafortunadamente, también se basa en la suposición 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 trampas puede hacer que esta solución sea inviable, y los clientes se verán limitados a enviar estados relativos (es decir, en qué vector se movieron o dispararon).

Lado del cliente

Como los clientes normalmente no pueden definir el estado principal del juego, sino que lo reciben del servidor, la tarea principal de la compensación del lado del cliente es renderizar el mundo virtual con la mayor precisión posible. Dado que las actualizaciones se producen con retraso e incluso pueden perderse, 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. Se pueden utilizar dos métodos básicos para lograr esto: extrapolación e interpolación . [ 14 ]

La extrapolación consiste en intentar estimar el estado futuro del juego. En cuanto se recibe un paquete del servidor, la posición de un objeto se actualiza. A la espera de la siguiente actualización, se extrapola la posición siguiente basándose en la posición actual y el movimiento en el momento de la actualización. Básicamente, el cliente asume que un objeto en movimiento continuará en la misma dirección. Al recibir un nuevo paquete, la posición puede corregirse ligeramente.

La interpolación funciona almacenando temporalmente el estado del juego y renderizándolo para el jugador con un ligero retardo constante. Cuando llega un paquete del servidor, en lugar de actualizar la posición de un objeto inmediatamente, el cliente comienza a interpolarla a partir de la última posición conocida. Durante el intervalo de interpolación, el objeto se renderiza moviéndose suavemente entre las dos posiciones. Idealmente, este intervalo debería coincidir exactamente con el retardo entre paquetes, pero debido a la pérdida de paquetes y al retardo variable, esto rara vez ocurre.

Ambos métodos tienen ventajas e inconvenientes.

  • La interpolación garantiza que los objetos se muevan únicamente entre posiciones válidas y produce buenos resultados con un retardo constante y sin pérdidas. Si los paquetes descartados o fuera de orden desbordan el búfer de interpolación, el cliente deberá congelar el objeto en su posición hasta que llegue un nuevo paquete o recurrir a la extrapolación. La desventaja de la interpolación es que provoca que el mundo se renderice con 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 el futuro con precisión. El movimiento solo se representará correctamente si es constante, pero esto no siempre será así. Los jugadores pueden cambiar tanto la velocidad como la dirección aleatoriamente. Esto puede provocar una pequeña distorsión a medida que llegan nuevas actualizaciones y se corrigen las posiciones estimadas, y también causar problemas con la detección de impactos, ya que los jugadores pueden aparecer en posiciones que no les corresponden.

A menudo, para garantizar una experiencia de juego fluida, se permite al cliente realizar pequeños cambios en el estado del juego. Si bien el servidor se encarga de la munición, la salud, la posición, etc., se le puede permitir al cliente predecir el nuevo estado del juego en el servidor basándose en las acciones del jugador, como por ejemplo, permitirle moverse antes de que el servidor haya respondido a la orden. Estos cambios suelen ser aceptados en condiciones normales y hacen que la latencia sea prácticamente imperceptible. Los problemas solo surgen en caso de grandes retrasos o pérdidas, cuando las predicciones del cliente se ven claramente anuladas por el servidor. En ocasiones, ante pequeñas diferencias, el servidor incluso puede permitir cambios "incorrectos" en el estado basándose en las actualizaciones del cliente.

Lado del servidor

A diferencia de los clientes, el servidor conoce el estado exacto del juego actual, por lo que la predicción es innecesaria. El propósito principal de la compensación de latencia del servidor es proporcionar efectos precisos de las acciones del cliente. Esto es importante porque para cuando llega la orden de un jugador, el tiempo habrá avanzado y el mundo ya no estará en el estado que el jugador vio al emitir su orden. [ 15 ] Un ejemplo muy claro de esto es la detección de impactos para armas disparadas en juegos de disparos en primera persona, donde los márgenes son pequeños y pueden causar problemas significativos si no se manejan adecuadamente.

Retroceder en el tiempo

Otra forma de abordar el problema es almacenar estados de juego anteriores durante un cierto período de tiempo y luego retroceder las posiciones de los jugadores al procesar un comando. [ 14 ] El servidor utiliza la latencia del jugador (incluido cualquier retraso inherente debido a la interpolación; ver más arriba) para retroceder el tiempo una cantidad apropiada para determinar lo que el cliente que dispara vio en el momento en que se efectuó el disparo. Esto generalmente resultará en que el servidor vea al cliente disparando a la posición anterior del objetivo y, por lo tanto, acierte. En el peor de los casos, un jugador estará tan rezagado que el servidor se quedará sin datos históricos y tendrá que empezar a anticiparse a sus objetivos.

Esta es una solución WYSIWYG que permite a los jugadores apuntar directamente a lo que ven. Pero el precio es una agravación 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 es perceptible, 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 mayor 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 con lag ". [ 14 ]

Un problema de diseño que surge al rebobinar es si se debe detener el rebobinado de los comandos retrasados ​​de un jugador muerto tan pronto como muere en el servidor, o continuar ejecutándolos hasta que se sincronicen con el momento de su muerte. Interrumpir la compensación de inmediato impide que las víctimas ataquen póstumamente a sus asesinos, lo cual cumple con las expectativas, pero conserva la ventaja natural de que los jugadores que doblan una esquina, adquieren un objetivo y lo eliminan lo hacen en menos tiempo que un viaje de ida y vuelta al cliente de la víctima estacionaria.

La función de rebobinado puede ser criticada 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 latencia a veces reducen la longitud del historial de juego almacenado o imponen límites de ping para mitigar este problema.

Clientes de confianza

Es posible que los clientes le indiquen al servidor lo que están haciendo y que el servidor confíe en los datos que recibe. Este método se evita siempre que sea posible debido a su vulnerabilidad al fraude : es sencillo enrutar los datos de red a través de un segundo ordenador que inserta mensajes de impacto falsificados o modifica los existentes, una técnica que no puede ser detectada por las herramientas antitrampas . [ 14 ]

Sin embargo, la magnitud de algunos juegos hace imposibles soluciones computacionalmente costosas como el rebobinado . En Battlefield 3 , por ejemplo, se utiliza un sistema de "detección de impactos híbrido" en el que los clientes informan al servidor que han acertado y el servidor realiza solo una prueba vaga de plausibilidad antes de aceptar la afirmación. [ 16 ]

Confiar en los resultados de un cliente tiene las mismas ventajas y desventajas que retroceder en el tiempo .

Hacer que los clientes extrapolen

Una solución menos común para el lag consiste en no hacer nada en el servidor y que cada cliente extrapole (véase más arriba) para compensar su latencia. [ 17 ] Esto produce resultados incorrectos a menos que los jugadores remotos mantengan una velocidad constante, lo que otorga una ventaja a quienes se mueven de un lado a otro o simplemente comienzan y se detienen.

La extrapolación extendida también provoca que los jugadores remotos se vuelvan visibles (aunque no vulnerables) cuando no deberían: por ejemplo, si un jugador remoto corre hacia una esquina y se detiene bruscamente en el borde, otros clientes lo interpretarán como si siguiera corriendo hacia el exterior durante el tiempo que dure su latencia. Por otro lado, los clientes deben proporcionar a los jugadores remotos que acaban de empezar a moverse un impulso adicional de velocidad para empujarlos hacia una ubicación teóricamente precisa.

Diseño

Es posible reducir la percepción de latencia mediante el diseño del juego . Las técnicas incluyen reproducir animaciones del lado del cliente como si la acción ocurriera inmediatamente, reducir o eliminar los temporizadores integrados en la máquina anfitriona y usar transiciones de cámara para ocultar la distorsión. [ 18 ]

juegos en la nube

El juego en la nube es un tipo de juego en línea donde todo el juego se aloja en un servidor de juego en un centro de datos, y el usuario solo ejecuta un cliente ligero localmente que reenvía las acciones del controlador de juego al servidor de juego. El servidor de juego luego renderiza el siguiente fotograma del video del juego que se comprime usando compresión de video de baja latencia y se envía al cliente ligero para descomprimirlo. Para que la experiencia de juego en la nube sea aceptable, la latencia 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 al servidor de juego, la ejecución del juego en el servidor de juego, la compresión y descompresión de video y audio, y la visualización del video en un dispositivo de visualización ) debe ser lo suficientemente baja como para que el usuario perciba que el juego se está ejecutando localmente. [ 3 ] [ 19 ] Debido a estos estrictos requisitos de latencia, 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 juego de juego en la nube a aproximadamente 1000 millas, según OnLive . [ 20 ] También existe mucha controversia sobre el retardo asociado a los juegos en la nube. En los juegos multijugador que utilizan una arquitectura de red cliente/servidor , el ordenador del jugador renderiza los gráficos del juego localmente y solo se envía al servidor información sobre las acciones del jugador dentro del juego. Por ejemplo, cuando el jugador pulsa 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 tras 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 usar juegos en la nube, las acciones del jugador pueden generar pequeños retrasos hasta que se muestre la respuesta. Primero, las acciones deben transmitirse al servidor remoto, que luego debe renderizar los gráficos de la acción y enviar el video al jugador a través de la red, lo que consume tiempo adicional. Por lo tanto, el jugador experimenta un retraso perceptible entre presionar un botón y ver la acción en 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 juego. Al realizar rápidamente una combinación de movimientos larga, 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 resulta en el fallo de la combinación.

El retardo adicional en la respuesta de los controles también puede dificultar mucho jugar a ciertos juegos para un solo jugador. Por ejemplo, si un enemigo ataca al jugador y este debe bloquear, para cuando la pantalla del jugador muestre que el enemigo ha comenzado a atacar, este ya lo habrá golpeado y eliminado en el servidor.

Uso especial

"Ka le" en Dota 2

Ka le o Kale , / ˈ k ɑː l ɜː / , [ 21 ] es una jerga de videojuegos y una frase de Internet [ 22 ] que se refiere al lag. [ 21 ] [ 22 ] Proviene de la frase china卡了( pinyin : Kǎle ) [ 21 ] [ 22 ] y se usó por primera vez en el Dota 2 Asia Championships 2015 , cuando algunos jugadores chinos la escribieron en el chat para quejarse de sus molestos lags en el juego y pedir que se pausara. [ 21 ] A medida que la escena china de Dota 2 se hizo popular, esta expresión también se conoció. Muchos jugadores occidentales, tanto profesionales como aficionados, a menudo escriben "kale" en lugar de "lag" en el chat del juego y en Twitch . [ 22 ] [ 21 ]

Véase también

Referencias

  1. "Optimizar XP para Mööayhem multijugador" . Maximum PC . Vol.  Verano. Future US, Inc. 2004. pág.  49.
  2. Cronin, Eric; Filstrup, Burton; Anthony, Kurc. "Un sistema de servidor de juegos multijugador distribuido" (PDF) . Universidad de Michigan. Archivado (PDF) del original el 4 de agosto de 2016. Recuperado el 16 de julio de 2014 .
  3. 1 2 "El proceso de invención: servicio de videojuegos OnLive" . The FU Foundation School of Engineering & Applied Science (Universidad de Columbia). Archivado del original el 20 de diciembre de 2012. Recuperado el 23 de enero de 2010 .
  4. "Cómo eliminar el lag | GeForce" . www.geforce.com . Archivado del original el 13 de septiembre de 2018. Consultado el 13 de septiembre de 2018 .
  5. Brown, Leigh (1 de junio de 2007). "Límite de velocidad teórico vs. real de Ping" . pingdom.com . Consultado el 27 de noviembre de 2024 .
  6. Butler, Sydney (6 de noviembre de 2024). "Retraso de entrada vs. Caídas de velocidad de fotogramas: ¿Cuál es la diferencia y cómo manejar cada uno?" . How-To Geek . Consultado el 27 de noviembre de 2024 .
  7. "Latencia del controlador inalámbrico: ¿es un problema? - LockerGnome" . LockerGnome . 27 de agosto de 2011. Archivado del original el 28 de agosto de 2016. Consultado el 12 de junio de 2016 .
  8. Shafer, Rob (12 de julio de 2024). "¿Qué es el retardo de entrada y qué importancia tiene para los videojuegos? [ Guía sencilla ] " . Display Ninja . Consultado el 26 de febrero de 2025 .
  9. "El lado oscuro de Overdrive" . bit-tech . Consultado el 12 de junio de 2016 .
  10. Smith, Joshua. "Arquitectura de juego distribuida para superar la latencia del sistema" (PDF) . Patente de Estados Unidos. Archivada (PDF) del original el 28 de octubre de 2017. Recuperada el 16 de julio de 2014 .
  11. Claypool, Mark; Claypool, Kajal. "La latencia puede matar: precisión y plazos de entrega en los juegos en línea" . Consultado el 16 de julio de 2014 .{{cite web}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  12. "Juegos de consola: El factor de latencia" . Eurogamer . Gamer Network. 5 de septiembre de 2009. pág. 2. Consultado el 12 de junio de 2016 . 
  13. Roelofs, Gregory. "Compensación de la latencia de red en un juego multijugador" (PDF) . Patente de Estados Unidos. Archivado (PDF) del original el 28 de abril de 2016. Recuperado el 16 de julio de 2014 .
  14. 1 2 3 4 5 Bernier, Yahn (2001). "Métodos de compensación de latencia en el diseño y optimización de protocolos de juego cliente/servidor" . Valve . Archivado del original el 30 de junio de 2019. Recuperado el 17 de septiembre de 2011 .
  15. Kahn, Adam S.; Williams, Dmitri (junio de 2016). "Estamos todos juntos en esto (juego): sistemas de memoria transaccional, presencia social y estructura de equipo en arenas de batalla multijugador en línea" . Communication Research . 43 (4): 487–517 . doi : 10.1177/0093650215617504 . ISSN 0093-6502 . S2CID 29776927 .  
  16. Kertz, Alan (11 de diciembre de 2011). "Re: Necesitamos a alguien que cree una guía para el nuevo control deslizante de configuración de interpolación de red" . Archivado del original el 14 de marzo de 2017. Recuperado el 4 de noviembre de 2013. El modelo de impacto de BF3 utiliza un modelo combinado cliente-servidor, una detección de impacto híbrida. El cliente le dice al servidor "¡Oye, le disparé!" y el servidor realiza una comprobación contra la posición de los dos objetivos y determina si el jugador pudo razonablemente haber alcanzado ese objetivo y luego aplica el daño.
  17. Gibson, John (5 de diciembre de 2010). "Re: ¿Presentará HoS las desventajas del código de red de UE3?" . Tripwire Interactive . Archivado del original el 10 de marzo de 2016 . Recuperado el 18 de septiembre de 2011 .
  18. Aldridge, David (2011). "Te disparé primero: Interconexión de la jugabilidad de HALO: REACH" . Game Developers Conference 2011. GDC Vault . Archivado del original el 19 de mayo de 2019. Recuperado el 14 de julio de 2014 .
  19. "D8 Video: Demostración de OnLive en iPad, PC, Mac, consola e iPhone" . Wall Street Journal. 9 de agosto de 2010. Archivado del original el 12 de febrero de 2011. Consultado el 19 de agosto de 2010 .
  20. "Pruebas beta a la velocidad de la luz" . OnLive. 21 de enero de 2010. Archivado del original el 16 de diciembre de 2012. Consultado el 23 de enero de 2010 .
  21. ^ 1 2 3 4 5正惊游戏 (01 de septiembre de 2018). "当网游出现延迟的时候,中国玩家用lag,老外却用拼音说"kale"?" . 17173 (en chino (China)).
  22. 1 2 3 4 Josuamarcelc (8 de julio de 2021). "¿Qué es Kale en Dota 2?" . josuamarcelc .
  • Prueba de retardo de entrada: televisores de 2016 y 2017. Dein-Fernseher.de