Netcode es un término general utilizado con mayor frecuencia por los jugadores en relación con las redes en juegos en línea , y a menudo se refiere a problemas de sincronización entre clientes y servidores. Los jugadores a menudo infieren "códigos de red incorrectos" cuando experimentan retrasos o cuando se pierden sus entradas. Las causas comunes de estos 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 procesamiento de fotogramas o velocidades de fotogramas inconsistentes . [1] [2] Los códigos de red 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 los inputs de todos los jugadores se ejecutan instantáneamente en la misma simulación o instancia del juego, en un juego online existen varias simulaciones paralelas (una para cada jugador) donde los inputs de sus respectivos jugadores se reciben instantáneamente, mientras las entradas para el mismo fotograma 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 fotograma (igual a 16,66 ms por fotograma a 60 FPS ), y si la entrada de un jugador remoto de un fotograma en particular (por ejemplo , del fotograma número 10) llega cuando ya se está ejecutando otro (por ejemplo, en el fotograma número 20, 166, 66 ms después), se produce la desincronización entre las simulaciones de los jugadores. Hay dos soluciones principales para resolver este conflicto y hacer que el juego funcione sin problemas:
La solución clásica a este problema es el uso de un código de red basado en retrasos. 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 resultar 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 "congelan". Esto ocurre porque un código de red basado en retrasos 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 provoca una experiencia inconsistente y que no responde 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 de ritmo rápido y sensibles al tiempo, como los juegos de lucha . [5]
Un sistema alternativo al netcode anterior es el rollback netcode. Este sistema ejecuta inmediatamente las entradas del jugador local (para que no se retrasen como ocurre con el código de red basado en retrasos), como si fuera un juego fuera de línea, y predice las entradas del jugador o jugadores remotos en lugar de esperarlas (asumiendo 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, el estado del juego se invierte 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 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 retraso de entrada fijo y luego se está utilizando la reversión. La reversión es bastante eficaz para ocultar picos de retraso u otros problemas relacionados con inconsistencias en las conexiones de los usuarios, ya que las predicciones suelen ser correctas y los jugadores ni siquiera se dan cuenta. Sin embargo, este sistema puede resultar problemático cuando el juego de un cliente se ralentiza (normalmente debido al sobrecalentamiento), ya que se pueden provocar problemas de rift que provoquen un intercambio de billetes entre máquinas a precios 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 está más lento tendrá ventaja sobre el resto al recibir entradas de otros a un ritmo normal (esto se conoce como uno- retroceso lateral). [6] Para abordar este flujo de entrada desigual (y, en consecuencia, también un flujo de trama 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 retrasos) o soluciones más ingeniosas. [ cita necesaria ] soluciones 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 para poder sincronizar gradualmente las instancias de los juegos. en las distintas máquinas. [7]
Rollback netcode requiere que el motor del juego pueda retroceder su estado, lo que requiere modificaciones en muchos motores existentes y, por tanto, la implementación de este sistema puede resultar problemática y costosa en juegos tipo AAA (que suelen tener un motor sólido y una alta -traffic network), como comentó el productor de Dragon Ball FighterZ, Tomoko Hiroki, entre otros. [8]
Aunque este sistema a menudo se asocia con una arquitectura de igual a igual y juegos de lucha, existen formas de redes de reversión que también se usan comúnmente en arquitecturas cliente-servidor (por ejemplo, los programadores agresivos que se encuentran en los sistemas de administración de bases de datos incluyen funcionalidad de reversión) y en otros géneros de videojuegos . [1]
Existe una biblioteca popular con licencia del MIT llamada GGPO diseñada para ayudar a implementar la reversión de redes en los 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 esto (cuanto más latencia hay entre jugadores, mayor es la sensación de que el juego no responde a sus entradas). [1] Que 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 retraso 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 a menudo se denomina tasa de ticks del servidor; esto es esencialmente el equivalente en el servidor a la velocidad de fotogramas de un cliente , sin ningún sistema de renderizado. [11] 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 una tasa de ticks fluctuante y para reducir los costos de CPU y transmisión de datos. Una tasa de ticks más baja 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 casos controvertidos 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 a su vez 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 al tiempo que limitan la frecuencia y prioridad de información menos importante. Al igual que con tickrate, 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 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 en algunos casos ser perceptible. [11] [16]
Varios errores de sincronización de simulación entre máquinas también pueden caer bajo el manto de "problemas de código de red". Estos pueden incluir errores que hacen que la simulación se desarrolle de manera diferente en una máquina que en otra, o que provocan que algunas cosas no se comuniquen cuando el usuario percibe que deberían serlo. [2] Tradicionalmente, los juegos de estrategia en tiempo real (como Age of Empires ) han utilizado modelos de red punto a punto donde se supone que la simulación se ejecutará exactamente igual en todos los clientes; Sin embargo, si un cliente pierde el ritmo 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 las 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 realicemos 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 protocolo ( Real Time Streaming Protocols ) agrupa 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é deshabilitado) que se enviará a través de la conexión establecida entre las máquinas, en lugar de hacerlo directamente (sacrificando velocidad por seguridad). Este tipo de protocolo también tiende a responder muy lentamente cada vez que se pierde 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, porque en lugar de establecer una conexión entre ellas los datos se enviarán y recibirán directamente. Este protocolo es mucho más simple que el anterior, pero carece de su confiabilidad 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 división de datos a través de paquetes, detección automática de pérdida de paquetes). , etc.); esto aumenta la complejidad del motor y podría provocar problemas. [18]