Código de red

La solución clásica a este problema es el uso de un código de red basado en retardo. Cuando las entradas de un jugador remoto llegan tarde, el juego retrasa las entradas del jugador local en consecuencia para sincronizarlas y ejecutarlas simultáneamente. Este retardo adicional puede ser molesto para los jugadores (especialmente cuando la latencia es alta), pero en general el cambio no es muy perceptible. Sin embargo, estos retardos pueden ser inconsistentes debido a fluctuaciones repentinas en la latencia actual. Si la latencia entre jugadores supera una ventana de búfer establecida para el jugador remoto, el juego debe esperar, lo que provoca que las pantallas se "congelen". Esto ocurre porque un código de red basado en retardo no permite que la simulación continúe hasta que reciba las entradas de todos los jugadores en el fotograma en cuestión. ^{[ 4 ]} Este retardo variable provoca una experiencia inconsistente y poco receptiva en comparación con el juego sin conexión (o con un juego LAN ), y puede afectar negativamente el rendimiento del jugador en géneros sensibles al tiempo y de ritmo rápido, como los juegos de lucha . ^{[ 5 ]}

Un sistema alternativo al anterior netcode es el netcode rollback. Este sistema ejecuta inmediatamente las entradas del jugador local (para que no se retrasen como con el netcode basado en retardo), como si fuera un juego sin conexión, y predice las entradas del jugador o jugadores remotos en lugar de esperarlas (asumiendo que harán la misma entrada que en el tick anterior). Una vez que llegan estas entradas remotas (supongamos, por ejemplo, 45 ms después), el juego puede actuar de dos maneras: si la predicción es correcta, el juego continúa como está, de forma totalmente continua; si la predicción fue incorrecta, el estado del juego se revierte y el juego continúa desde el estado corregido, visto como un "salto" al otro jugador o jugadores (equivalente a 45 ms, siguiendo el ejemplo). ^{[ 1 ]} Algunos juegos utilizan una solución híbrida para disimular estos "saltos" (que pueden volverse problemáticos a medida que aumenta la latencia entre jugadores, ya que hay cada vez menos tiempo para reaccionar a las acciones de otros jugadores) con un retardo de entrada fijo y luego se utiliza rollback. El rollback es bastante efectivo para ocultar picos de latencia u otros problemas relacionados con inconsistencias en las conexiones de los usuarios, ya que las predicciones suelen ser correctas y los jugadores ni siquiera lo notan. Sin embargo, este sistema puede ser problemático cuando el juego de un cliente se ralentiza (generalmente debido al sobrecalentamiento), ya que pueden surgir problemas de grieta que provocan un intercambio desigual de tickets entre máquinas. Esto genera fallos visuales que interrumpen la partida de aquellos jugadores que reciben entradas a un ritmo más lento, mientras que el jugador cuyo juego se ralentiza tendrá ventaja sobre los demás al recibir entradas de otros a un ritmo normal (esto se conoce como rollback unilateral). ^{[ 6 ]} Para abordar este flujo de entrada desigual (y, en consecuencia, también un flujo de fotogramas desigual), existen soluciones estándar como esperar a que las entradas tardías lleguen a todas las máquinas (similar al modelo de código de red basado en retardo) o soluciones más ingeniosas como la que se utiliza actualmente en Skullgirls , que consiste en la omisión sistemática de un fotograma cada siete para que, cuando el juego encuentre el problema en cuestión, pueda recuperar los fotogramas omitidos y así sincronizar gradualmente las instancias del juego en las distintas máquinas. ^{[ 7 ]}

El netcode rollback requiere que el motor del juego pueda revertir su estado, lo que exige modificaciones en muchos motores existentes y, por lo tanto, la implementación de este sistema puede ser problemática y costosa en juegos tipo AAA (que suelen tener un motor sólido y una red de alto tráfico), como comentó la productora de Dragon Ball FighterZ, Tomoko Hiroki, entre otros. ^{[ 8 ]}

Aunque este sistema se asocia a menudo con una arquitectura peer-to-peer y juegos de lucha, existen formas de redes de retroceso que también se utilizan comúnmente en arquitecturas cliente-servidor (por ejemplo, los planificadores agresivos que se encuentran en los sistemas de gestión de bases de datos incluyen funcionalidad de retroceso) y en otros géneros de videojuegos . ^{[ 1 ]}

Existe una popular biblioteca con licencia MIT llamada GGPO diseñada para ayudar a implementar redes de retroceso en juegos (principalmente juegos de lucha). ^{[ 9 ]}

La latencia es inevitable en los juegos en línea, y la calidad de la experiencia del jugador está estrechamente ligada a ella (cuanto mayor sea la latencia entre jugadores, mayor será la sensación de que el juego no responde a sus acciones). ^{[ 1 ]} La latencia de la red de los jugadores (que en gran medida escapa al control del juego) no es el único factor a considerar, sino también la latencia inherente a la forma en que se ejecutan las simulaciones del juego. Existen varios métodos de compensación de latencia que se utilizan para disimularla o mitigarla (especialmente con valores de latencia elevados). ^{[ 73 ]}

Una única actualización de una simulación de juego se conoce como tick. La frecuencia con la que se ejecuta la simulación en un servidor se suele denominar tickrate del servidor; este es esencialmente el equivalente en el servidor a la velocidad de fotogramas de un cliente , sin ningún sistema de renderizado. ^{[ 74 ]} El tickrate está limitado por el tiempo que tarda en ejecutarse la simulación, y a menudo se limita aún más intencionalmente para reducir la inestabilidad introducida por un tickrate fluctuante y para reducir los costos de CPU y transmisión de datos. Un tickrate más bajo aumenta la latencia en la sincronización de la simulación del juego entre el servidor y los clientes. ^{[ 75 ]} La tasa de ticks para juegos como los de disparos en primera persona suele estar entre 128 ticks por segundo (como en el caso de Valorant ) , 64 ticks por segundo (en juegos como Counter-Strike: Global Offensive y Overwatch ), 30 ticks por segundo (como en Fortnite y la edición de consola de Battlefield V ) ^{[ 76 ]} y 20 ticks por segundo (como los controvertidos casos de Call of Duty: Modern Warfare , Call of Duty: Warzone y Apex Legends ). ^{[ 77 ] [ 78 ]} Una tasa de ticks más baja también reduce naturalmente la precisión de la simulación, ^{[ 74 ]} lo que en sí mismo podría causar problemas si se lleva demasiado lejos, o si las simulaciones del cliente y del servidor se ejecutan a velocidades significativamente diferentes.

Debido a las limitaciones en la cantidad de ancho de banda disponible y el tiempo de CPU que consume la comunicación de red, algunos juegos priorizan ciertas comunicaciones vitales, limitando la frecuencia y la prioridad de la información menos importante. Al igual que con la tasa de actualización, esto aumenta efectivamente la latencia de sincronización. Los motores de juego pueden limitar la cantidad de veces que se envían actualizaciones (de una simulación) a un cliente específico o a objetos específicos del mundo del juego, además de reducir la precisión de algunos valores enviados a través de la red para ayudar con el uso del ancho de banda. Esta falta de precisión puede ser perceptible en algunos casos. ^{[ 74 ] [ 79 ]}

Diversos errores de sincronización de simulación entre máquinas también pueden entrar en la categoría de "problemas de código de red". Estos pueden incluir errores que provocan que la simulación se ejecute de forma diferente en una máquina que en otra, o que impiden que se comuniquen ciertos elementos cuando el usuario percibe que deberían hacerlo. ^{[ 2 ]} Tradicionalmente, los juegos de estrategia en tiempo real (como Age of Empires ) han utilizado modelos de red peer-to-peer con protocolo lockstep, donde se asume que la simulación se ejecutará exactamente igual en todos los clientes; sin embargo, si un cliente se desincroniza por cualquier motivo, la desincronización puede agravarse y ser irrecuperable. ^{[ 74 ] [ 80 ]}

La elección del protocolo de capa de transporte de un juego (así como su gestión y codificación) también puede afectar a los problemas de red percibidos.

Si un juego utiliza el Protocolo de Control de Transmisión (TCP), aumentará la latencia entre los jugadores. Este protocolo se basa en la conexión entre dos máquinas, que intercambian y leen datos. Este tipo de conexiones son muy fiables, estables, ordenadas y fáciles de implementar. Sin embargo, no son del todo adecuadas para las velocidades de red que requieren los juegos de acción rápida, ya que este protocolo agrupa automáticamente los datos en paquetes (que no se envían hasta alcanzar un cierto volumen de información, a menos que se desactive el algoritmo de Nagle ) . Estos paquetes se envían a través de la conexión establecida entre las máquinas, en lugar de directamente (priorizando la seguridad sobre la velocidad). Además, este protocolo tiende a responder muy lentamente cuando se pierde un paquete o cuando los paquetes llegan en un orden incorrecto o duplicados, lo que puede ser muy perjudicial para un juego en línea en tiempo real (este protocolo no fue diseñado para este tipo de software).

Si el juego utiliza el Protocolo de Datagramas de Usuario (UDP), la conexión entre máquinas será muy rápida, ya que en lugar de establecer una conexión, los datos se enviarán y recibirán directamente. Este protocolo es mucho más sencillo que el anterior, pero carece de su fiabilidad y estabilidad, y requiere la implementación de código propio para gestionar funciones indispensables para la comunicación entre máquinas que gestiona TCP (como la división de datos en paquetes, la detección automática de pérdida de paquetes, etc.); esto aumenta la complejidad del motor y podría generar problemas. ^{[ 81 ]}