Editando Netcode (sección)

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