Editando Netcode (sección)

== 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>