Netcode

[5]​ 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 ms a 60 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: 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 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).

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).

[1]​ 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.

Esto genera 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).

[9]​ 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 (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.

[1]​ 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).

Este protocolo se basa en la conexión entre dos máquinas, en la cual estas pueden intercambiar datos y leerlas.

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