Qué es el Rollback Netcode: la salvación de los juegos de pelea

Después de una larga jornada de trabajo, me dispongo a despejarme jugando unas partidas online de Dragon Ball FighterZ. Gano la primera, la segunda me cuesta un poco más pero la saco adelante. Y es en la tercera, muy reñida, que la conexión decide que 17 frames de delay es algo aceptable para jugar. Pero… plot twist: no lo es. Y pierdo miserablemente, aunque no del todo por mi culpa.

Este escenario debe ser conocido para varios de ustedes, incluso fuera de los juegos de pelea. El golpe que no sale cuando tiene que salir, el personaje que se teletransporta, ese combo que offline te sale 10 de 10 veces pero online te sale media, y puedo seguir hasta mañana con ejemplos.

Hoy voy a escribir una nota que está buenísima, pero que la van a leer hasta el final, con suerte, dos personas (una es Juan, porque la edita). Pero no me importa. Es tan importante que la necesité como referencia en al menos otras tres que escribí para Press Over. Por lo que tenía que existir.

El tema a tratar es de una relevancia tal que trae repercusiones en el mundo de la Fighting Games Community, incluso a nivel competitivo, con quejas y sanciones en el medio. Un componente esencial en la construcción de un juego de pelea exitoso para los tiempos que corren, el cuco de los desarrolladores nipones, la solución que existe hace más de 10 años pero que extrañamente no es utilizada en el 100% de los juegos, el rollback netcode.

Pero para hablar de rollback netcode, primero tengo que hablar del hermano mayor (pero no por eso mejor), el que actualmente rige en la mayoría de los juegos nipones: el delay based netcode.

Los juegos de pelea, por diseño, corren a 60 frames por segundo para estandarizar inputs de movimientos y determinar sus velocidades de ejecución. Digamos que yo estoy jugando una partida de Dragon Ball FighterZ en Buenos Aires y matcheo con alguien de San Pablo. Esta conexión tiene un tiempo de viaje (un ping) de un punto a otro (ida y vuelta) medida en milisegundos y que tiende a ser variable.

A efectos de este ejemplo, voy a pasar esos milisegundos a frames, por lo que mandar y recibir data tarda aproximadamente tres frames. Con esto en mente, el delay based netcode funciona de la siguiente manera: una vez establecido el vínculo, el juego para avanzar si o si necesita los inputs míos y los de mi rival. Los míos ya los tiene y los de mi rival tienen que hacer ese viajecito de tresframes, lo cual ya nos da un delay en el juego de esa misma cantidad de frames. Aprieto un botón y el movimiento va a salir tres frames más tarde de lo que lo haría de manera offline.

Hasta acá todo muy tolerable y rico pero, como bien sabemos, las conexiones suelen fluctuar e incluso hasta perder paquetes y es acá donde empezamos a ver las fallas de este tipo de netcode, que se va a quedar esperando inputs y eso se traduce en pantalla como el famoso lag, llevando partidas al punto de lo injugable.

Esto no solo afecta la experiencia del jugador en las partidas, sino que también, a la hora de hacer matchmaking, con este tipo de tecnología voy a querer buscar partidas de ping bajo para que el delay de los inputs sea medianamente aceptable, achicando automáticamente mi alcance, e incluso matcheando con jugadores de nivel superior al mío solo porque tienen una conexión tolerable dentros de los parámetros del netcode.

Parece una boludez, pero esto genera que jugadores principiantes abandonen juegos a causa de no jugar contra rivales con la misma experiencia que uno, que en estos casos es fundamental para una progresión natural de nuestras habilidades. ¿Ya sienten que fueron al colegio? Esperen porque todavía falta.

Con esta problemática en mente, allá por 2007 los hermanos Tom y Tonny Cannon revelan GGPO, un entorno para desarrollar e implementar netcode usando como base el delay based netcode, pero agregándole muchas herramientas y evolucionarlo a su “forma final”: el rollback netcode.

A partir de ese entonces el paradigma cambia, y al día de hoy varios juegos occidentales (por no decir todos) utilizan este tipo de netcode que, a diferencia de su antecesor es, cuanto menos, notable. Estableciendo un delay arbitrario como base, el netcode cuando nota algún tipo de alteración en la conexión predice los movimientos del jugador y los autocompleta: es decir, si el jugador estaba caminando hacia adelante a la hora de la alteración, el netcode va a asumir que el jugador sigue yendo hacia adelante (lo cual es cierto un 80% de las veces). De esta forma, el juego sigue su curso sin ningún inconveniente pero… ¿qué pasa cuando la predicción no es correcta? Acá viene lo bueno y la razón por la cual se llama rollback netcode.

Lo que hace el código al detectar algo diferente a su predicción es “rebobinar” al momento en que se produce la discrepancia “predicción vs input real” y actualiza el estado del juego con el input del jugador. ¿Cómo hace esto sin que visualmente sea un espanto? Fácil, utiliza ese delay pre-establecido como resguardo para hacer las correcciones, hasta a veces recorta frames de activación de los movimientos que son invisibles al ojo humano.

El resultado de implementar una tecnología de esta índole es que de repente no necesitamos buscar gente exclusivamente con ping bajo, haciendo que nuestro espectro de rivales se mucho más amplio, que la búsqueda sea más rápida y que se enfoque más en el nivel del próximo oponente, generando así una experiencia más agradable mientras desarrollamos nuestras habilidades dentro del juego.

Los ejemplos de juegos con esta tecnología bien implementada al día de la fecha son: Mortal Kombat 11, Skullgirls, Them Fightin’ Herds y Killer Instinct. Siendo este último el mayor exponente de implementación y el cual recomiendo porque se van a sorprender. ¿Ejemplos de esta tecnología mal implementada? Street Fighter V.

Y ahora que poseen el conocimiento, estoy seguro que se preguntarán: ¿por qué existiendo esta tecnología desde 2007, hay juegos que siguen teniendo un netcode pésimo? Las respuestas son varias, pero podemos reducirlas a: “porque Japón”.

El desarrollador nipón es reacio a implementar algo que no conoce y que, sobretodo, no creo él mismo. Esto, sumado a que Japón en sí es un país pequeño y con conexiones de internet de otro planeta, conforman el brebaje perfecto sabor “que me importa tu netcode nuevo, si este que usamos en nuestro país funciona flama y los yankees lo siguen comprando” (patente pendiente).

También podemos agregar, como variable, que los japoneses suelen usar el mismo motor de un juego para crear su continuación (Under Night in-Birth, BlazBlue, Guilty Gear Xrd), y como en ese motor ya está implementado el delay based, modificarlo implicaría cambiar la lógica del juego en su totalidad y eso sale un montón de plata.

Por suerte, el primer llamado de atención respecto a este tema sucedió a causa de la pandemia y su impacto en la (cancelada) EVO 2020. Y es que esta situación excepcional obligó a replantear el line-up de juegos que formarían parte del evento, dado que ninguno de los ocho juegos tenía rollback, reemplazándolos por cuatro juegos que si lo tenían (casualmente los cuatro que nombré más arriba). ¿Lo bueno? ArcSystem Works parece haber tomado nota de esto y decidió cambiar a mitad de desarrollo el netcode del Guilty Gear Strive. Implementación que esperemos que esté más cerca del Killer Instinct que del Street Fighter V.

Si llegaron hasta acá los felicito, se ganaron una galletita con forma de hadouken. También se ganaron recomendaciones de material (en inglés) para ahondar en esto que trate de explicar de la mejor manera y en la menor cantidad de caracteres posibles. Por un lado, está este artículo que es LA MERCA para explicar el tema. Por el otro, está este video de Adam “Keits” Heart, desarrollador de Killer Instinct y eminencia en el tema.

Espero hayan disfrutado de la lectura y será hasta el próximo round.