Netcode es un término general que utilizan con mayor frecuencia los jugadores en relación con las redes en los juegos en línea , que a menudo se refiere a problemas de sincronización entre clientes y servidores. Los jugadores a menudo infieren "netcodes incorrectos" cuando experimentan retrasos o cuando se pierden sus entradas. Las causas comunes de tales problemas incluyen alta latencia entre el servidor y el cliente, pérdida de paquetes , congestión de la red y factores externos independientes de la calidad de la red, como el tiempo de renderizado de cuadros o velocidades de cuadros inconsistentes . [1] [2] Los netcodes pueden diseñarse para mantener una experiencia sincrónica y fluida entre los usuarios a pesar de estos desafíos de red.
A diferencia de un juego local donde las entradas de todos los jugadores se ejecutan instantáneamente en la misma simulación o instancia del juego, en un juego en línea existen varias simulaciones paralelas (una para cada jugador) donde las entradas de sus respectivos jugadores se reciben instantáneamente, mientras que las entradas para el mismo cuadro de otros jugadores llegan con un cierto retraso (mayor o menor dependiendo de la distancia física entre los jugadores, la calidad y velocidad de las conexiones de red de los jugadores, etc.). [3] Durante una partida en línea, los juegos deben recibir y procesar la entrada de los jugadores dentro de un tiempo determinado para cada cuadro (igual a 16,66 ms por cuadro a 60 FPS ), y si la entrada de un jugador remoto de un cuadro en particular (por ejemplo, del cuadro número 10) llega cuando otro ya está en ejecución (por ejemplo, en el cuadro número 20, 166,66 ms después), se produce una desincronización entre las simulaciones de los jugadores. Existen dos soluciones principales para resolver este conflicto y hacer que el juego funcione de manera fluida:
La solución clásica a este problema es el uso de un netcode basado en retardo. Cuando las entradas de un jugador remoto llegan tarde, el juego retrasa las entradas del jugador local en consecuencia para sincronizar las dos entradas y ejecutarlas simultáneamente. Este retraso adicional puede ser perjudicial para los jugadores (especialmente cuando la latencia es alta), pero en general el cambio no es muy notable. Sin embargo, estos retrasos pueden ser inconsistentes debido a fluctuaciones repentinas en la latencia actual. Si la latencia entre jugadores excede una ventana de búfer establecida para el jugador remoto, el juego debe esperar, lo que hace que las pantallas se "congelen". Esto ocurre porque un netcode basado en retraso no permite que la simulación continúe hasta que reciba las entradas de todos los jugadores en el cuadro en cuestión. [4] Este retraso variable causa una experiencia inconsistente y sin respuesta en comparación con el juego fuera de línea (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 netcode anterior 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 offline, y predice las entradas del jugador o jugadores remotos en lugar de esperarlas (asumiendo que harán la misma entrada que la del 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, se revierte el estado del juego y la jugabilidad 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 disfrazar 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 el rollback. El rollback es bastante efectivo para disimular picos de lag 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 resultar problemático cuando el juego de un cliente se ralentiza (normalmente por sobrecalentamiento), ya que se pueden producir problemas de rift que lleven a un intercambio de tickets entre máquinas a ritmos desiguales. Esto genera fallos visuales que interrumpen la jugabilidad de aquellos jugadores que reciben entradas a un ritmo más lento, mientras que el jugador cuyo juego se ralentiza tendrá una ventaja sobre el resto al recibir entradas de los demás a un ritmo normal (esto se conoce como rollback unilateral). [6] Para solucionar este flujo de entrada desigual (y en consecuencia, también un flujo de cuadros desigual), existen soluciones estándar como esperar a que las entradas tardías lleguen a todas las máquinas (similar al modelo de netcode basado en retardo) o soluciones más ingeniosas [ cita requerida ] como la que se utiliza actualmente en Skullgirls , que consiste en la omisión sistemática de un cuadro cada siete para que cuando el juego encuentre el problema en cuestión pueda recuperar los cuadros saltados para sincronizar gradualmente las instancias de los juegos en las distintas máquinas. [7]
El netcode rollback requiere que el motor del juego sea capaz de volver a su estado anterior, lo que requiere modificaciones a muchos motores existentes, y por 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 ha comentado el productor de Dragon Ball FighterZ Tomoko Hiroki, entre otros. [8]
Aunque este sistema suele asociarse con una arquitectura peer to peer y juegos de lucha, existen formas de redes de reversión que también se utilizan comúnmente en arquitecturas cliente-servidor (por ejemplo, los programadores agresivos que se encuentran en los sistemas de gestión de bases de datos incluyen la funcionalidad de reversión) y en otros géneros de videojuegos . [1]
Existe una biblioteca popular con licencia MIT llamada GGPO diseñada para ayudar a implementar redes de reversión 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á estrictamente ligada a ella (cuanto mayor sea la latencia entre jugadores, mayor será la sensación de que el juego no responde a sus entradas). [1] La latencia de la red de los jugadores (que en gran medida está fuera del control del juego) no es el único factor en cuestión, 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 retardo que se utilizan para disfrazar o hacer frente a la latencia (especialmente con valores de latencia altos). [10]
Una única actualización de una simulación de juego se conoce como tick. La velocidad a la que se ejecuta la simulación en un servidor se suele denominar tickrate del servidor; esto es esencialmente el equivalente en el servidor de la velocidad de cuadros de un cliente , en ausencia de cualquier sistema de renderizado. [11] El tickrate está limitado por el tiempo que lleva ejecutar 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. [12] La tasa de ticks para juegos como los shooters en primera persona suele estar entre 128 ticks por segundo (tal es 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 ) [13] y 20 ticks por segundo (tales son los controvertidos casos de Call of Duty: Modern Warfare , Call of Duty: Warzone y Apex Legends ). [14] [15] Una tasa de ticks más baja también reduce naturalmente la precisión de la simulación, [11] 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 se necesita para la comunicación de red, algunos juegos priorizan ciertas comunicaciones vitales mientras limitan la frecuencia y prioridad de la información menos importante. Al igual que con la tasa de ticks, esto aumenta efectivamente la latencia de sincronización. Los motores de juegos pueden limitar la cantidad de veces que se envían actualizaciones (de una simulación) a un cliente en particular y/o a objetos particulares en el 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 notoria en algunos casos. [11] [16]
Varios errores de sincronización de simulación entre máquinas también pueden caer bajo la categoría de "problemas de código de red". Estos pueden incluir errores que hacen que la simulación proceda de manera diferente en una máquina que en otra, o que hacen que algunas cosas no se comuniquen 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 redes peer to peer con protocolos de sincronización en los que se supone que la simulación se ejecutará exactamente igual en todos los clientes; sin embargo, si un cliente se desfasa por cualquier motivo, la desincronización puede agravarse y ser irrecuperable. [11] [17]
La elección del protocolo de capa de transporte de un juego (y su gestión y codificación) también puede afectar los problemas de red percibidos.
Si un juego utiliza un Protocolo de Control de Transmisión (TCP), habrá una mayor latencia entre jugadores. Este protocolo se basa en la conexión entre dos máquinas, en la que pueden intercambiar datos y leerlos. Este tipo de conexiones son muy fiables, estables, ordenadas y fáciles de implementar, y se utilizan en prácticamente cualquier operación que se haga en Internet (desde navegar por la web hasta enviar correos electrónicos o chatear a través de un IRC ). Estas conexiones, sin embargo, no se adaptan del todo a las velocidades de red que requieren los juegos de acción rápida, ya que este tipo de protocolos ( Real Time Streaming Protocols ) agrupan automáticamente los datos en paquetes (que no se enviarán hasta que se alcance un cierto volumen de información, a menos que este algoritmo -el de Nagle- esté desactivado) que se enviarán a través de la conexión establecida entre las máquinas, en lugar de hacerlo directamente (sacrificando velocidad por seguridad). Este tipo de protocolos también suelen responder muy lentamente siempre que pierden un paquete, o cuando los paquetes llegan en un orden incorrecto o duplicados, lo que puede ser muy perjudicial para un juego online en tiempo real (este protocolo no fue diseñado para este tipo de software).
Si en cambio el juego utiliza un 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 entre ellas, 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 manejar funciones indispensables para la comunicación entre máquinas que son manejadas por TCP (como la división de datos a través de paquetes, la detección automática de pérdida de paquetes, etc.); esto aumenta la complejidad del motor y puede por sí mismo dar lugar a problemas. [18]