Rollback netcode: pasado, presente y futuro de la lucha online
Repasamos la historia y funcionamiento de una solución contra el lag con cada vez más relevancia en la escena competitiva de los fighting games.
A poco que estéis interesados en los juegos de lucha, seguramente habréis leído más de una vez el término rollback netcode. Dista de ser una invención reciente; de hecho, es un sistema con más de una década a sus espaldas, pero la pandemia y la cancelación de eventos de lucha presenciales como el EVO han reabierto y aumentado el debate a su alrededor. Precisamente uno de los fundadores de dicho torneo, Tony Cannon, fue quien dio con esta solución, diseñando un software para mejorar el rendimiento online de juegos antiguos, y desde entonces se ha convertido en un nuevo estándar para jugar a través de internet a clásicos y novedades por igual.
Un estándar, no obstante, con el que algunas compañías —particularmente en Japón— todavía se muestran reticentes. Super Smash Bros. Melee, a pesar de ser estrenado en 2002 y sin online, a día de hoy ofrece un netcode más eficiente que Ultimate, entrega de 2018 con servicio de pago proporcionado por Nintendo. Y Dragon Ball FighterZ, uno de los nombres estrella de la escena competitiva actual, se ha resentido más en 2020 que juegos como Killer Instinct o Mortal Kombat 11 debido a su permanencia en el sistema antiguo, conocido como delay-based netcode. Es algo que, por suerte, Arc System Works remediará en Guilty Gear Strive, juego cuya beta ha servido para recordar por qué rollback es el camino a seguir. Así que hoy caminaremos hacia atrás, al inicio de dicho camino, para ver cómo se trazó en primer lugar.
Érase una vez... La lucha en línea
Todo empezó en Cupertino, California. Bueno, se podría decir que empezó en muchos sitios. En las universidades donde se crearon tanto los primitivos primeros videojuegos como las primeras infraestructuras online. En las oficinas de los estudios que probaron suerte con la lucha desde innumerables perspectivas antes de que Street Fighter II redefiniese el género. O, claro, en la propia sede de Capcom, que hace ya treinta años lanzó una de las obras más esenciales del medio. Pero por el bien de la brevedad, obviaremos todo eso y saltaremos directamente a 1994, cuando una compañía mucho menos conocida, Catapult Entertainment, creó un periférico llamado XBAND.
Distribuido por THQ y vendido en la cadena de videoclubs Blockbuster, XBAND era un módem que permitía jugar online en Mega Drive y SNES. El artefacto consiguió el visto bueno de Sega y Nintendo, aunque sus autores tuvieron que implementar la compatibilidad por su cuenta, usando ingeniería inversa para habilitarla en una selección de juegos que incluía Super Mario Kart, Killer Instinct, Mortal Kombat 3, los títulos deportivos de EA (Madden, NBA Live, NHL) y, cómo no, Super Street Fighter II. Fue un primer intento con éxito bastante moderado y prácticamente limitado a Estados Unidos —no llegó a Europa y su presencia en Japón fue anecdótica—, pero funcional y con prestaciones como emparejamiento por nivel de habilidad, descarga de tablas de clasificación, chat de texto y la celebración ocasional de torneos nacionales.
Si bien no fue el inicio del juego online como tal, XBAND sí dejó patente tanto su potencial como las posibles limitaciones en consolas. Usando la línea de teléfono, el programa escrito por Catapult enlazaba los módems de dos jugadores y hacía creer a sus juegos que los mandos estaban conectados a la misma consola. Una proeza tecnológica sorprendentemente viable, pero desafiada por la necesidad de registrar el presionado de los botones en uno y otro mando e intercambiar dicha información entre las dos casas antes de mostrar sus efectos en pantalla. Este proceso de espera para la transferencia y ejecución de cada maniobra es lo que conocemos como network delay (retardo de red) y, en un escenario ideal, se lleva a cabo en un lapso tan corto que resulta prácticamente imperceptible para el jugador.
Sin embargo, los casos ideales no tienen por qué ser la norma, ni ahora ni entre 1994 y 1997 (periodo en activo de XBAND). La velocidad de conexión sí era suficiente para transmitir instrucciones tan sencillas como las que requería Street Fighter II, pero, como sabrán los versados, el tiempo necesario para transmitir datos depende de la latencia (o ping, medido en milisegundos), y ese factor era más variable según zona y distancia, creando a veces retrasos importantes en el procesamiento de acciones (network lag). El paliativo más sencillo era intentar conectar con jugadores lo más cercanos posible, aunque los diseñadores de WeaponLord (juego de SNES y Mega Drive creado con XBAND ya en mente) también intentaron contrarrestarlo con un combate más basado en la complejidad que la velocidad y un sistema de parries con armas que facilitaba defenderse de cross-ups en situaciones con lag.
Nuevo milenio, nueva oportunidad
A pesar de la viabilidad demostrada por una compañía third party en consolas de 16-bits, hubo que esperar dos generaciones más para ver una apuesta plena por el servicio. Catapult implementaría XBAND en Saturn, que ofreció su propio módem first party (Sega Net Link), y Nintendo también tuvo sus escarceos en Japón mediante el fallido periférico 64DD, pero fue Dreamcast la que inició una nueva era de online en consolas a escala global. Probablemente algunos recuerden la llegada de ChuChu Rocket! a Europa en el verano de 2000, lanzamiento simbólico, pero apenas antesala de lo que sería jugar a Phantasy Star Online o a Quake III: Arena. O a Halo 2 cuando Microsoft recogió el testigo de Sega con su Xbox Live. Las infraestructuras mejoraron y se acercaron a un nivel que los ordenadores llevaban años ofreciendo.
Sin embargo, los juegos de lucha seguían planteando sus propios retos. Sí, las conexiones eran más rápidas y permitían que se conectaran más jugadores a la vez, en juegos con operaciones cada vez más complejas. Pero en el 1 contra 1 de la lucha, donde las victorias se decidían en décimas de segundo, la latencia seguía siendo el factor clave y, a la vez, el más falible. Títulos emblemáticos de la época como Street Fighter III: 3rd Strike o Soul Calibur I, II y III (pseudo sucesores de WeaponLord y su combate con armas y parries) salieron a la venta sin online. Era un género todavía orientado a los salones recreativos, a las partidas locales y a los torneos presenciales (como el EVO), condenado a la categoría de nicho a medida que internet se iba convirtiendo en una presencia más y más importante para el multijugador.
Good Game, Peace Out
En agosto de 2006, meses antes de la llegada de Wii y PlayStation 3, Capcom relanzó Street Fighter II: Hyper Fighting en la tienda digital de Xbox 360 y se convirtió en el más vendido de la plataforma durante sus primeras 24 horas. Un éxito, eso sí, pronto deslucido por las quejas sobre el lag, presentes tanto entre la prensa como entre los usuarios. Al igual que en los lejanos días del XBAND, el delay-based netcode solo ofrecía una experiencia de juego del todo fluida si la latencia era suficientemente baja como para intercambiar la información de los dos jugadores y dibujar el resultado sincronizado en un lapso inferior a los 50 milisegundos (o 3 frames de un juego que corra a 60 fps), algo que ni en 2006, ni ahora en 2021, se puede garantizar.
Una idea importante, antes de avanzar más, es que el lag como tal siempre va a existir. Un ping de 0 milisegundos es inviable porque, incluso en un escenario ideal, la señal debe recorrer una distancia física y someterse a protocolos de identificación por el camino. A partir de ahí, factores como un buen netcode, la cercanía entre jugadores o el uso de cable Ethernet contribuyen a su reducción, mientras que un netcode congestionado y la pérdida de paquetes de información contribuyen a su incremento. Pero ni la mejor de las conexiones sirve para conseguir la ausencia de lag, la consistencia total en el ritmo de transmisión ni, por supuesto, que el jugador al otro lado no lastre la experiencia si padece sus propias fluctuaciones en la línea.
Aquí es donde volvemos a Cupertino y a Tony Cannon —sin relación con Catapult Entertainment, pero oriundo de la misma ciudad—. Viendo los problemas que aquejaban a Street Fighter II en su relanzamiento de Xbox 360, el co-fundador del EVO se frustró por la incapacidad de Capcom para reavivar en un género en declive y se puso a trabajar en su propia solución. El resultado fue el rollback netcode, sistema implementable mediante un programa llamado GGPO (Good Game, Peace Out) que, naturalmente, no reducía la latencia —algo fuera de las posibilidades del juego—, pero sí mitigaba sus efectos reemplazando la espera por una predicción que luego era corregida —en caso de ser necesario— al llegar la información del otro extremo.
Para que no suene abstracto, hagamos una pequeña dramatización con un ejemplo de cada método. En la casilla inicial de la imagen que hay bajo estas líneas, basada en el método de delay-based netcode, el jugador que controla a Ryu presiona un botón de ataque. Jugando offline, la acción se reflejaría en el frame siguiente, pero jugando online, el tránsito de información detiene la acción (una cantidad imperceptible o perceptible de tiempo según la latencia) para sincronizarse y empezar a ejecutar el ataque tras registrar la nueva posición de Guile. La misma operación se repite luego en la casilla 4, cuando el juego vuelve a verificar la posición del otro jugador.
Si la latencia es baja, este intercambio tiene lugar en pocos milisegundos y el jugador no percibe pausas. Si la latencia es alta, aumenta la cantidad de frames necesarios para una correcta sincronización —el framerate no solo actualiza la representación visual, también la lógica jugable subyacente—, lo que puede dar lugar a parones claros e incluso a una partida prácticamente injugable en casos más extremos.
Ahora veamos la misma situación usando rollback netcode: tras pulsar el botón de ataque, la animación empieza a ejecutarse al instante porque el juego se encarga de simular momentáneamente las acciones de Guile (ilustrado abajo mediante el uso de blanco y negro). Una vez la información del otro jugador aparece, si dicha simulación coincide con lo que ha ocurrido en el otro lado (de nuevo, hablamos de milésimas de segundo), el juego sigue su curso como si no hubiese intercedido. Si hay disparidad —como la que creamos abajo poniendo un ejemplo con lag notable—, retrocede (de ahí el término rollback) y muestra de inmediato la ubicación correcta del otro jugador.
Huelga decir que si la latencia es muy alta, esta especie de “teletransporte” también se puede convertir en un problema serio, que impide el correcto transcurso de las partidas. Es un truco ingenioso, no magia. Pero dentro de unos márgenes comunes, o incluso más taxativos, el rollback consigue que la experiencia de juego sea más fluida y precisa que el delay-based, ya que los inputs de ambos jugadores siempre se registran y ejecutan al instante —algo que no ocurre en el sistema con retardo—.
Hibridación y expansión
Otro aspecto clave del rollback es que no se trata solo de una alternativa, sino también de un complemento. Ambos sistemas pueden coexistir en un mismo juego así que, en cuanto la solución de GGPO empezó a coger tracción tanto en el panorama de la emulación como entre los desarrolladores de ports oficiales (como Super Street Fighter II Turbo HD Remix o Street Fighter III: 3rd Strike Online) e incluso de juegos nuevos (como Skullgirls), pronto se dio una hibridación: Killer Instinct y Injustice 2, por ejemplo, establecieron 3 frames máximos de retraso, momento en el que el rollback entra en efecto para impedir que la acción se detenga; mientras otros, como Darkstalkers Resurrection o el ya citado Skullgirls, han optado por implementar selectores para que los jugadores elijan su propio equilibrio entre sistemas.
Entonces, si aporta beneficios tan claros y no anula el otro método, ¿por qué el rollback sigue sin estar en juegos de gran relevancia casi 15 años después del estreno de GGPO? Un factor recurrente, que ya dejamos caer al principio, es la mayor reticencia de los desarrolladores japoneses a incorporar tecnología creada fuera. Sagas occidentales como Injustice o Mortal Kombat saltaron rápidamente al nuevo vagón, y ports modernos de Capcom como Street Fighter o Darkstalkers corrieron a cargo de Iron Galaxy, estudio americano también responsable de las últimas temporadas de Killer Instinct, pero en tierras niponas han preferido seguir trabajando con sus métodos, familiares y funcionales en conexiones dentro del país. Ahora, por suerte, el giro hacia el rollback empieza a materializarse en promesas como las de Guilty Gear Strive o King of Fighters XV, aunque todavía es una aclimatación en proceso.
Claro que introducir rollback no es solo una cuestión de abrirse a otras tecnologías, sino también de preparar nuevas infraestructuras y optimizar —o crear desde cero— otro tipo de operaciones. Conseguir que en Dragon Ball FighterZ el juego asuma el control de un personaje, simule su comportamiento hacia delante, almacene los estados intermedios y revierta a cualquiera de ellos o a uno nuevo de forma instantánea es una tarea bastante más complicada que en Street Fighter II. En esencia, requiere procesar escenarios teóricos que no se muestran en pantalla, y que quizá nunca se lleguen a mostrar, pero que consumen capacidad computacional de todas formas.
Puede que un trabajo de ingeniería eficiente permita parchear una solución un día de estos (Mortal Kombat X lo hizo bastantes meses después de su lanzamiento), pero lo ideal, cómo no, es construir los juegos con el rollback netcode en mente desde el principio. Así que incluso aunque algunas de estas oportunidades presentes pasen por perdidas, si la industria sigue empujando para hacerlo un requisito de la competición online, seguramente acabará siéndolo más tarde o más temprano.
Fuentes: YouTube, GameSpy, Gamasutra, GGPO, The Complete Killer Instinct Guide