Netcode es un término general utilizado por 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 suelen inferir "códigos de red incorrectos" cuando encuentran problemas de conexión en un juego. Algunas causas comunes: alta latencia entre el servidor y el cliente, pérdida de paquetes , congestión de la red , etc. Factores externos no relacionados e independientes de la calidad de la red, como el tiempo de procesamiento de cuadros o velocidades de cuadros inconsistentes . [1] [2] Netcode como término tiende a usarse solo en la comunidad de jugadores, ya que no se reconoce como una ciencia informática real.término. [3] [4]
Tipos de código 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 hay 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.). [5] Durante un partido en línea, los juegos deben recibir y procesar la entrada de los jugadores dentro de un cierto tiempo para cada cuadro (por ejemplo, 16 ms 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 ya se está ejecutando otro (por ejemplo, en el cuadro número 20, 160 ms después), se produce la desincronización entre simulaciones de jugadores. Hay dos soluciones principales para resolver este conflicto y hacer que el juego funcione sin problemas:
Basado en retardo
La solución clásica a este problema es el uso de un código de red basado en retardos. Cuando las entradas de un jugador remoto llegan tarde, el juego retrasa las entradas del jugador local al mismo tiempo para sincronizar las dos entradas y ejecutarlas simultáneamente. El hecho de que las entradas de los jugadores locales no se ejecuten instantáneamente puede ser molesto para los jugadores (especialmente cuando hay una latencia alta entre ellos), pero en general el cambio no es muy notable. El verdadero problema de este sistema es su inconsistencia, ya que el retraso de las entradas del reproductor remoto puede variar en función de la latencia actual, que puede fluctuar inesperadamente. Cuando la latencia entre jugadores es tan alta que la entrada del jugador remoto no puede enviarse a un búfer de, digamos, 3 cuadros (48 ms), el juego debe esperar, lo que hace que las pantallas se "congelen" (un código de red basado en demoras no permitir que la simulación continúe hasta que reciba las entradas de todos los jugadores en el marco en cuestión). [6] Debido a que este retraso puede ser variable, esto causa una experiencia más inconsistente y sin respuesta 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 de ritmo rápido y sensibles al tiempo, como los juegos de lucha . [7]
Retroceder
Un sistema alternativo al código de red anterior es el código de red de reversión. Este sistema ejecuta inmediatamente las entradas del jugador local (para que no se retrasen como con el código de red basado en retardo), 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 formas: 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 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 retroceso que se está utilizando. La reversión es bastante eficaz para ocultar los picos de retraso u otros problemas relacionados con las inconsistencias en las conexiones de los usuarios, ya que las predicciones a menudo son correctas y los jugadores ni siquiera se dan cuenta. No obstante, este sistema puede resultar problemático cuando el juego de un cliente se ralentiza (normalmente debido a un sobrecalentamiento), ya que pueden producirse problemas de ruptura que provoquen un intercambio de tickets entre máquinas a tarifas 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 otros a un ritmo normal (esto se conoce como uno- retroceso lateral). [8] Para abordar este flujo de entrada desigual (y, en consecuencia, un flujo de tramas desigual también), 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 demoras) o más ingeniosas 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 se encuentre con el problema en cuestión pueda recuperar los fotogramas saltados para sincronizar gradualmente las instancias de los juegos en las distintas máquinas . [9]
Rollback netcode requiere que el motor del juego pueda regresar su estado, lo que requiere modificaciones a muchos motores existentes, y por lo tanto, la implementación de este sistema puede ser problemática y costosa en juegos tipo AAA (que generalmente tienen un motor sólido y un alto rendimiento). -red de tráfico), como lo comentó el productor de Dragon Ball FighterZ , Tomoko Hiroki, entre otros. [10]
Aunque este sistema a menudo se asocia con una arquitectura de igual a igual y con 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 la 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 redes de reversión en un juego (principalmente juegos de lucha). [11]
Causas potenciales de problemas de netcode
Latencia
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 haya entre los jugadores, mayor será la sensación de que el juego no responde a sus entradas). [1] Que la latencia de la red de los jugadores (que está en gran parte 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. Hay 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). [12]
Tickrate
Una única actualización de una simulación de juego se conoce como tic. La velocidad a la que se ejecuta la simulación en un servidor a menudo se conoce como la tasa de tictac del servidor; esto es esencialmente el servidor equivalente a la velocidad de fotogramas de un cliente , sin ningún sistema de renderizado. [13] El tickrate está limitado por el tiempo que lleva ejecutar la simulación y, a menudo, se limita intencionalmente aún más para reducir la inestabilidad introducida por un tickrate fluctuante y para reducir los costos de transmisión de datos y CPU. Un tickrate más bajo aumenta la latencia en la sincronización de la simulación del juego entre el servidor y los clientes. [14] La tasa de ticks para juegos como los juegos de disparos en primera persona suele ser de 120 ticks por segundo (como es el caso de Valorant ) , 60 ticks por segundo (en juegos como Counter-Strike: Global Offensive y Overwatch ), 30 tics por segundo ( como en la edición de consola de Fortnite y Battlefield V ) [15] y 20 tics por segundo (tales son los casos polémicos de Call of Duty: Modern Warfare , Call of Duty: Warzone y Apex Legends ). [16] [17] Una tasa de tick más baja también reduce naturalmente la precisión de la simulación, [13] que en sí misma podría causar problemas si se lleva demasiado lejos, o si las simulaciones de cliente y servidor se ejecutan a tasas significativamente diferentes.
Debido a las limitaciones en la cantidad de ancho de banda disponible y el tiempo de CPU que toma 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 el tickrate, esto aumenta efectivamente la latencia de sincronización. Los motores de juego pueden limitar la cantidad de veces que las actualizaciones (de una simulación) se envían a un cliente en particular y / u 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 notable en algunos casos. [13] [18]
Errores de software
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 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 de paso cerrado donde se asume 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. [13] [19]
Protocolo de la capa de transporte y código de comunicación: TCP y UDP
La elección del protocolo de la capa de transporte de un juego (y su administración y codificación) también puede afectar los problemas de redes percibidos.
Si un juego usa un Protocolo de control de transmisión (TCP), habrá una mayor latencia entre los 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 confiables, estables, ordenadas y fáciles de implementar, y se utilizan en prácticamente cualquier operación que hacemos en Internet (desde la navegación web hasta el correo electrónico o el chat a través de un IRC ). Sin embargo, estas conexiones 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 ( Protocolos de transmisión en tiempo real ) 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 algoritmo de Nagle, esté desactivado), que se enviará a través de la conexión establecida entre las máquinas, en lugar de directamente (sacrificando la velocidad por la seguridad). Este tipo de protocolo también tiende a responder muy lentamente cada vez que pierden 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, 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 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 , suma de comprobación , etc.); esto aumenta la complejidad del motor y podría generar problemas. [20]
Ver también
- Juego en linea
- Lag (juegos en línea)
enlaces externos
- Sitio web oficial de GGPO
Referencias
- ^ a b c d Huynh, Martin; Valarino, Fernando (2019). Un análisis de modelos de consistencia continua en juegos de lucha peer-to-peer en tiempo real .
- ^ a b "Direccionamiento de" Netcode "en Battlefield 4" . EA Digital Illusions CE . Marzo de 2014 . Consultado el 30 de marzo de 2014 .
- ^ "Lista de términos de programación e informática" . Labautopedia .
- ^ "Término de programación informática" . Esperanza informática .
- ^ "Netcode [p1]: Fightin 'Words" . ki.infil.net . Consultado el 7 de diciembre de 2020 .
- ^ Personal, Ars (18/10/2019). "Explicando cómo los juegos de lucha usan el código de red basado en demoras y retroceso" . Ars Technica . Consultado el 7 de diciembre de 2020 .
- ^ Pináculo. "La diferencia entre esports LAN y Online" . Pináculo . Consultado el 1 de diciembre de 2020 .
- ^ Lee, Gerald (8 de abril de 2020). Análisis: Por qué es mejor deshacer el código de red (Youtube).
- ^ Hills, Dakota 'DarkHorse' (29 de abril de 2020). "Skullgirls recibe una actualización de código de red mejorada creada inicialmente por un fanático del juego" . EventHubs . Consultado el 11 de diciembre de 2020 .
- ^ Hills, Dakota 'DarkHorse' (10 de diciembre de 2020). "La era del código de red basado en retardos puede haber terminado definitivamente en los juegos de lucha, dependiendo de lo que haga SNK con The King of Fighters 15" . EventHubs . Consultado el 10 de diciembre de 2020 .
- ^ Pusch, Ricky (18 de octubre de 2019). "Explicando cómo los juegos de lucha usan el código de red basado en demoras y retroceso" . Ars Technica . Consultado el 14 de diciembre de 2020 .
- ^ "Métodos de compensación de latencia en el diseño y optimización de protocolos cliente / servidor en el juego" . Comunidad de desarrolladores de válvulas . Consultado el 11 de diciembre de 2020 .
- ^ a b c d "Fuente de redes multijugador" . Válvula . Consultado el 30 de marzo de 2014 .
- ^ "Titanfall, de l'importance d'un bon tickrate" . gamekult.com. 2014-03-29 . Consultado el 30 de marzo de 2014 .
- ^ "Tasa de tic del servidor de Battlefield V revelada y por qué es importante" . www.glitched.online . Consultado el 5 de diciembre de 2020 .
- ^ Davison, Ethan. "Los servidores ultrarrápidos de Valorant están atrayendo a streamers y profesionales en masa. He aquí por qué" . Washington Post . ISSN 0190-8286 . Consultado el 5 de diciembre de 2020 .
- ^ "¿Qué tan malo es el código de red de Apex Legends en comparación con Fortnite y PUBG?" . Dexerto . 2019-11-23 . Consultado el 5 de diciembre de 2020 .
- ^ "Arquitectura de redes irreal" . Juegos épicos . Consultado el 7 de septiembre de 2014 .
- ^ Glenn Fiedler. "Lo que todo programador necesita saber sobre redes de juegos" . Consultado el 8 de septiembre de 2014 .
- ^ Fiedler, Glenn (1 de octubre de 2008). "UDP frente a TCP" . Gaffer en juegos . Consultado el 14 de diciembre de 2020 .