Edición de «Netcode»

'''Netcode''' se trata de un [[hiperónimo]] utilizado en la comunidad [[Jugador de videojuegos|gamer]] para denominar cualquier cosa que se relacione a la gestión de redes (''networking'' en [[Idioma inglés|inglés]]) de los [[Videojuego en línea|juegos en línea]], a menudo refiriéndose a problemas de sincronización entre clientes y servidores. Los jugadores habitualmente hacen afirmaciones sobre "netcodes malos" cuando se encuentran problemas de conexión en un juego, a pesar de que las causas de estos problemas podrían estar completamente fuera del control de su [[Motor de videojuego|motor]] (algunas causas habituales: [[latencia]] alta entre el servidor y el cliente, pérdida de paquetes, [[Congestión de red|congestión de la red]], etc.). Incluso podrían ser causados por factores externos que no tienen nada que ver con la calidad de la red como el tiempo de [[renderización]] de los fotogramas o velocidades inconsistentes de [[Fotogramas por segundo|fotogramas]].<ref name=":0">{{Cita libro|título=An analysis of continuous consistency models in real time peer-to-peer fighting games|url=http://urn.kb.se/resolve?urn=urn:nbn:se:hkr:diva-19404|fecha=2019|nombre=Martin|apellidos=Huynh}}</ref><ref name=":1">{{Cita web|url=http://battlelog.battlefield.com/bf4/news/view/addressing-netcode-in-bf4/|título=Addressing "Netcode"; in Battlefield 4|fechaacceso=30-03-2014|sitioweb=Battlelog}}</ref> Netcode como término tiende a ser utilizado solamente en el mundo de los videojuegos, y no es reconocido por la [[comunidad científica]] de las [[ciencias de la computación]].<ref>{{Cita web|url=http://www.labautopedia.org/mw/index.php?title=List_of_programming_and_computer_science_terms#N|título=List of programming and computer science terms|sitioweb=Labautopedia}}</ref><ref>{{Cita web|url=http://www.computerhope.com/jargon/program.htm|título=Computer programming term|sitioweb=Computer Hope}}</ref>

== Tipos de netcode ==
A diferencia de una partida local donde las entradas de todos los jugadores se ejecutan al instante en una misma simulación o instancia del juego, en una partida en línea hay varias simulaciones paralelas (una para cada jugador) donde las entradas de sus jugadores respectivos se reciben instantáneamente, mientras que las entradas para el mismo fotograma de los otros jugadores llegan con un cierto retraso (mayor o menor dependiendo de la distancia física entre los jugadores, la calidad y rapidez de las conexiones a la red de los jugadores, etc.).<ref>{{Cita web|url=https://ki.infil.net/w02-netcode.html|título=Netcode [p1]: Fightin' Words|fechaacceso=2020-12-07|sitioweb=ki.infil.net}}</ref> Durante una partida en línea, los juegos tienen que recibir y procesar la entrada (''input'' en inglés) de los jugadores en un tiempo determinado para cada fotograma (por ejemplo, 16 [[Milisegundo|ms]] a 60 [[Fotogramas por segundo|FPS]]), y si la entrada de un jugador remoto de un fotograma concreto (por ejemplo, del fotograma número 10) llega en el momento en el que ya se está ejecutando otro (por ejemplo, en el fotograma número 20, 160 ms más tarde) se produce una desincronización entre las simulaciones de los jugadores. Para resolver este conflicto y conseguir que el juego funcione con fluidez hay dos soluciones principales:

=== Basado en retraso ===
[[Archivo:Diagrama de un netcode basado en retraso.png|miniaturadeimagen|Diagrama sobre la ejecución y sincronización de las entradas de dos jugadores (con un [[ping]] de 90 ms entre ellos) en un juego en línea que utiliza un netcode basado en retraso en un modelo de igual a igual.]]
La solución clásica a esta problemática se trata de la utilización de un netcode '''basado en retraso''' (''delay-based'' ''netcode'' en inglés). Cuando las entradas de un jugador remoto llegan tarde lo que hace el juego es retrasar las entradas del jugador local el mismo tiempo para sincronizar las dos entradas y ejecutarlas vez. El hecho de que las entradas del jugador local no se ejecuten instantáneamente puede ser molesto para los jugadores (sobre todo cuando hay una latencia alta entre ellos), pero en general el cambio no es muy notable. El verdadero problema de este sistema se trata de su inconsistencia, ya que el retraso de las entradas de los jugadores remotos puede variar adecuándose a la latencia del momento, la cual puede fluctuar inesperadamente. Cuando la latencia entre jugadores es tan alta que no se puede enviar la entrada del jugador remoto dentro de una [[memoria intermedia]] (''buffer'' en inglés) de, por ejemplo, 3 fotogramas (48 ms), el juego debe esperar, causando que se "congelen" las pantallas (un netcode basado en retraso no permite continuar con la simulación hasta que no reciba las entradas de todos los jugadores del fotograma en cuestión).<ref>{{Cita web|url=https://arstechnica.com/gaming/2019/10/explaining-how-fighting-games-use-delay-based-and-rollback-netcode/|título=Explaining how fighting games use delay-based and rollback netcode|fechaacceso=2020-12-07|apellido=Staff|nombre=Ars|fecha=2019-10-18|sitioweb=Ars Technica|idioma=en-us}}</ref> Como este retraso puede ser variable, la experiencia de los jugadores en partidas en línea resulta ser menos agradable y responsiva que con partidas ''offline'' (o en una red [[Red de área local|LAN]]), y puede llegar a afectar negativamente el rendimiento de los jugadores en juegos altamente sensitivos y de acción rápida como los [[Videojuego de lucha|juegos de lucha]].<ref>{{Cita web|url=https://www.pinnacle.com/en/esports-hub/betting-articles/strategy/the-difference-between-lan-and-online/7e32u7tktr9fwyz7|título=The difference between LAN and Online esports|fechaacceso=2020-12-01|apellido=Pinnacle|sitioweb=Pinnacle|idioma=en}}</ref>

=== Retrospectivo ===
[[Archivo:Diagrama de un netcode retrospectivo.png|izquierda|miniaturadeimagen|Diagrama sobre la ejecución y sincronización de las entradas de dos jugadores (con un ping de 90 ms entre ellos) en un juego en línea que utiliza un netcode retrospectivo en un modelo de igual a igual.]]
Un sistema alternativo al netcode anterior es el netcode '''retrospectivo''' (''rollback'' en inglés). Este sistema ejecuta inmediatamente las entradas del jugador local (de forma que no se retrasan como con el netcode basado en retraso), como si se tratara de una partida ''offline'', y predice las entradas del jugador o jugadores remotos en lugar de esperarlos (suponiendo que harán la misma entrada que la del ''tick'' anterior). Una vez llegan estas entradas remotas (suponemos, por ejemplo, 45 ms después), el juego puede actuar de dos maneras: si la predicción es correcta, el juego continúa tal cual, de manera totalmente fluida; si la predicción era incorrecta, el estado del juego se revierte y el juego continúa desde el estado corregido, por lo que el otro u otros jugadores verán el [[cambio de estado]] en forma de un pequeño salto temporal (equivalente a 45 ms, siguiendo el ejemplo).<ref name=":0" /> Algunos juegos utilizan una solución híbrida para disimular estos "saltos" (los cuales pueden llegar a ser problemáticos a medida que la latencia entre los jugadores crece, ya que cada vez hay menos tiempo para reaccionar a las acciones de los otros jugadores) mediante un retraso de entrada fijo y luego aplicando el sistema de ''networking'' retrospectivo. El netcode retrospectivo resulta bastante efectivo al momento de disimular subidas breves de la latencia de los jugadores u otros problemas relacionados con inconsistencias de las conexiones de los clientes, ya que las predicciones son a menudo correctas y los jugadores ni se dan cuenta. No obstante, cuando este sistema se encuentra con la situación de que el juego de un cliente se ralentiza (normalmente por sobrecalentamiento), se pueden causar problemas de ''rift'' que lleven a un intercambio de entradas entre máquinas a ritmos desiguales. Esto genera [[Glitch|errores visuales]] (''glitches'' en inglés) que dificultan el juego a los jugadores que reciben las entradas a un ritmo más lento, mientras el jugador cuyo juego está ralentizado tendrá una ventaja sobre el resto recibiendo a un ritmo normal las entradas de los otros (esto se conoce como ''rollback'' unilateral).<ref>{{Cita video|url=https://www.youtube.com/watch?v=0NLe4IpdS1w&ab_channel=Core-AGaming|title=Analysis: Why Rollback Netcode Is Better|date=04-08-2020|last=Lee|first=Gerald|type=Youtube|language=EN}}</ref> Para solucionar este desequilibrio desigual de entradas (y en consecuencia, de fotogramas), hay soluciones lógicas como la espera de todas las máquinas para sincronizar las entradas que llegan tarde (similar al modelo de netcode basado en retraso) o soluciones más ingeniosas como el empleado actualmente en el juego [[Skullgirls]], la cual 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 este pueda recuperar los fotogramas omitidos para así poco a poco sincronizar las instancias de los juegos en las diversas máquinas.<ref>{{Cita web|url=https://www.eventhubs.com/news/2020/apr/29/skullgirls-receives-improved-netcode-update-initially-created-fan-game/|título=Skullgirls receives an improved netcode update initially created by a fan of the game|fechaacceso=2020-12-11|apellido=Hills|nombre=Dakota 'DarkHorse'|fecha=2020-04-29|sitioweb=EventHubs|idioma=en}}</ref>

El netcode retrospectivo requiere que el motor del juego pueda retroceder su estado, lo que exige modificaciones en muchos motores existentes y, por tanto, la implementación de este sistema puede ser problemática y cara en títulos del tipo [[AAA (industria del videojuego)|AAA]] (los cuales suelen tener un motor sólido y una red con mucho tráfico), como ha comentado el productor de [[Dragon Ball FighterZ]] Tomoko Hiroki, entre otros.<ref>{{Cita web|url=https://www.eventhubs.com/news/2020/dec/10/delay-netcode-ending-kof-future/|título=The era of delay-based netcode may finally be over for good in fighting games depending on what SNK does with The King of Fighters 15|fechaacceso=2020-12-11|apellido=Hills|nombre=Dakota 'DarkHorse'|fecha=2020-12-10|sitioweb=EventHubs|idioma=en}}</ref>

Aunque este sistema sea a menudo asociado al modelo de [[Peer-to-peer|igual a igual]] (''peer-to-peer'' en inglés) y a los juegos de lucha, hay formas de ''networkings'' retrospectivos que también se utilizan habitualmente en arquitecturas [[cliente-servidor]] (como los [[Planificador|planificadores]] agresivos que encontramos en los [[Sistema de gestión de bases de datos|sistemas de gestión de bases de datos]], los cuales incluyen una funcionalidad retrospectiva) y en otros [[Género de videojuegos|géneros de videojuegos]].<ref name=":0" />

Hay una librería popular con [[licencia MIT]] llamada GGPO diseñada para facilitar la implementación del ''networking'' retrospectivo a un juego (principalmente los de lucha).<ref>{{Cita web|url=https://arstechnica.com/gaming/2019/10/explaining-how-fighting-games-use-delay-based-and-rollback-netcode/|título=Explaining how fighting games use delay-based and rollback netcode|fechaacceso=2020-12-12|apellido=Pusch|nombre=Ricky|fecha=2019-10-18|sitioweb=Ars Technica|idioma=en-us}}</ref>

== Causas potenciales de problemas de netcode ==

=== Latencia ===
La latencia es inevitable en los juegos en línea, y la calidad de la experiencia de los jugadores está estrictamente ligada a esta (cuanta más latencia hay entre los jugadores, mayor es el sentimiento de que el juego no es responsivo a sus entradas).<ref name=":0" /> Hay que tener en cuenta el hecho de que la latencia de la red de los jugadores (la cual está en gran parte fuera del control de los juegos) no es el único factor en cuestión, sino también la latencia inherente a la manera en que las simulaciones de los juegos se ejecutan. Para disfrazar o disimular la latencia y para corregir problemas causados por valores altos de esta se han desarrollado varios métodos de compensación de [[lag]].<ref>{{Cita web|url=https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization#Lag_Compensation|título=Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization - Valve Developer Community|fechaacceso=2020-12-11|sitioweb=developer.valvesoftware.com}}</ref>

=== Tickrate ===
La medida temporal mínima de una reiteración de acciones en un juego se conoce como ''tick''. La tasa a la cual la simulación es ejecutada en un servidor es referido a menudo como el ''tickrate'' (o tasa de actualización) de un servidor; esto es esencialmente el equivalente de los [[fotogramas por segundo]] del cliente.<ref name=":2">{{Cita web|url=https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking|título=Source Multiplayer Networking|fechaacceso=2020-12-11|sitioweb=Valve Developer Community}}</ref> El ''tickrate'' es limitado por el periodo de tiempo que la simulación necesita para ejecutarse, y es a menudo intencionadamente limitado todavía más para reducir la inestabilidad introducida por una tasa fluctuante (y también para reducir los costes de la CPU y de transmisión de datos). Un ''tickrate'' bajo incrementa la latencia de la sincronización entre la simulación del servidor y las de los clientes.<ref>{{Cita web|url=http://www.gamekult.com/actu/titanfall-de-limportance-dun-bon-tickrate-A130413.html|título=Titanfall, de l'importance d'un bon tickrate|fechaacceso=2014-03-30|fecha=2014-03-29|editor=gamekult.com}}</ref> El ''tickrate'' en juegos de acción rápida como los [[Videojuego de disparos en primera persona|shooters en primera persona]] a menudo se encuentra entre los 120 ''ticks'' por segundo (cómo es el caso de [[Valorant]]), los 60 ''ticks'' por segundo (en juegos como [[Counter-Strike: Global Offensive]] u [[Overwatch]]), los 30 ''ticks'' por segundo (como en [[Fortnite]] y en la versión de consola de [[Battlefield V]])<ref>{{Cita web|url=https://www.glitched.online/battlefield-v-server-tick-rate/|título=Battlefield V Server Tick Rate Revealed & Why It Matters|fechaacceso=2020-12-05|idioma=en-ZA}}</ref> y los 20 ''ticks'' por segundo (cómo con los polémicos casos de [[Call of Duty: Modern Warfare (videojuego de 2019)|Call of Duty: Modern Warfare]], [[Call of Duty: Warzone]] y [[Apex Legends]]).<ref>{{Cita publicación|url=https://www.washingtonpost.com/video-games/esports/2020/04/14/valorant-tick-rate-servers-pros-streamers/|título=Valorant’s super-fast servers are attracting streamers and pros in droves. Here’s why.|apellidos=Davison|nombre=Ethan|publicación=Washington Post|idioma=en-US|issn=0190-8286}}</ref><ref>{{Cita web|url=https://www.dexerto.com/apex-legends/how-bad-is-apex-legends-netcode-compared-to-fortnite-pubg-1290489/|título=How bad is Apex Legends netcode compared to Fortnite and PUBG?|fechaacceso=2020-12-05|fecha=2019-11-23|idioma=en}}</ref> Un ''tickrate'' bajo, naturalmente, también reduce la precisión de la simulación, de manera que podría llegar a causar problemas si se lleva a extremos, o si las simulaciones del cliente y del servidor se encuentran ejecutándose a tasas significativamente diferentes.

Debido a limitaciones en la cantidad de la anchura de banda disponible y el tiempo de la CPU dedicado a la comunicación de la red, algunos juegos priorizan ciertas comunicaciones vitales mientras se limita la frecuencia y prioridad de otros tipos de información menos importantes. Igual que con el ''tickrate'', esto aumenta la latencia de la sincronización. Los motores de juego pueden limitar las veces por segundo que las actualizaciones (de la simulación) son enviadas a un cliente determinado y/o a objetos determinados 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 de la anchura de banda. Esta carencia de precisión puede llegar a ser notable.<ref name=":2" /><ref name="EpicNet">{{Cita web|url=http://udn.epicgames.com/Three/NetworkingOverview.html|título=Unreal Networking Architecture|fechaacceso=2014-09-07|fecha=|editor=[[Epic Games]]}}</ref>

=== Errores de software ===
Hay varios errores de sincronización de una simulación entre máquinas que suelen ser considerados como "problemas de netcode". Por ejemplo, podemos encontrar varios [[Error de software|bugs]] que causen que la simulación avance y se desarrolle de manera diferente entre una máquina y otra, o que algunos objetos o elementos no se comuniquen entre ellos aunque el usuario perciba que deberían hacerlo.<ref name=":1" /> Tradicionalmente, los [[Videojuego de estrategia en tiempo real|juegos de estrategia en tiempo real]] (por ejemplo, [[Age of Empires (serie)|Age of Empires]]) utilizaron modelos de gestión de redes peer-to-peer del tipo ''lock-step'' donde se asume que las simulaciones se ejecutan de manera exactamente igual para todos los clientes; aun así, si un cliente perdiera el paso por cualquier razón, la desincronización puede ser grave y volverse irrecuperable.<ref>{{Cita web|url=http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/|título=What every programmer needs to know about game networking|fechaacceso=2014-09-08|apellido=Glenn Fiedler|fecha=}}</ref>

=== Protocolos de capa de transporte y código de comunicación: PCT y PDU ===
El tipo de protocolo de [[capa de transporte]] (y su gestión y programación) escogido para un juego también puede causar problemas de ''networking''.

Si un juego utiliza un [[protocolo de control de transmisión]] (PCT, TCP en inglés), habrá una latencia añadida entre los jugadores. Este protocolo se basa en la conexión entre dos máquinas, en la cual estas pueden intercambiar datos y leerlas. Este tipo de conexiones son muy fiables, estables, ordenadas y fáciles de implementar, y se utilizan en prácticamente cualquier operación que hacemos por internet (tanto en la navegación de la web como en los [[Correo electrónico|correos electrónicos]] o los [[Internet Relay Chat|IRC]]). Estas conexiones, sin embargo, no se adecuan correctamente a las velocidades de red que los juegos de acción rápida necesitan, ya que este tipo de protocolo (los [[Protocolo de transmisión en tiempo real|protocolos de transmisión en tiempo real]]) agrupa los datos automáticamente en paquetes (los cuales no se enviarán hasta alcanzar un volumen de información determinado) que se enviarán a través de la conexión establecida entre las máquinas, en vez de manera directa (sacrificando la velocidad por seguridad). Este tipo de protocolo también tiende a responder muy lentamente cuando se encuentra con la situación de que ha perdido un paquete, o que han llegado en un orden incorrecto o duplicados, lo que puede ser muy perjudicial para un juego en línea en tiempo real (hay recordar que este protocolo no se diseñó para este tipo de software).

Si el juego en cambio utiliza un [[protocolo de datagramas de usuario]] (PDU, UDP en inglés), la conexión entre las máquinas será muy rápida, ya que en vez de establecer una conexión entre ellas se enviarán y recibirán los datos directamente. Este protocolo es mucho más sencillo que el anterior, pero no goza de su fiabilidad y estabilidad y requiere la implementación de código propio para encargarse de las funciones indispensables para la comunicación entre máquinas que el PCT incluye (tales como la división de datos en paquetes, la detección automática de la pérdida de paquetes, la [[suma de verificación]], etc.); esto aumenta la complejidad del motor, por lo que se podrían provocar problemas.<ref>{{Cita web|url=https://gafferongames.com/post/udp_vs_tcp/|título=UDP vs. TCP|fechaacceso=2020-12-11|fecha=2008-10-01|sitioweb=Gaffer On Games|idioma=en-us}}</ref>

== Véase también ==

* [[Videojuego en línea|Juegos en línea]]
*[[Género de videojuegos]]
* [[Retardo (telecomunicación)|Lag (juegos digitales)]]
* [[Protocolo de datagramas de usuario#Comparativa entre UDP y TCP (Transmission Control Protocol)|Comparativa entre los protocolos UDP y TCP]]

== Enlaces externos ==

* [https://www.ggpo.net/ Página oficial de la librería GGPO]

== Referencias ==
{{Listaref}}
{{Control de autoridades}}
[[Categoría:Videojuegos multijugador]]
[[Categoría:Servidores]]
[[Categoría:Desarrollo de videojuegos]]
[[Categoría:Plataformas de videojuegos]]