Las consolas de ahora se encarecen por la RAM, pero Sonic iba como un tiro hace 35 años en una Mega Drive con 64 KB

Cuando empecé a jugar a las consolas solo podías ser de dos bandos: o de Mario o de Sonic. O lo que es lo mismo: tenías que decidirte entre Nintendo y su Super Nintendo o Sega y su Mega Drive.  Las dos empresas marcaban el rumbo de los videojuegos a comienzos de los 90, al menos en el ámbito doméstico. Y cada una necesitaba distinguirse con algún rasgo único. En Sega optaron por la velocidad.

Sonic iba rápido, la Mega Drive no. El hardware de la máquina no estaba mal para la época, pero tenía ciertas limitaciones. El obstáculo estaba, principalmente, en el procesador: el Motorola 68000 que montaba, a 7,67 MHz, era un chip bastante apto, pero carecía de un componente especializado en cálculos matemáticos complejos. Sus 64 KB de memoria RAM tampoco ayudaban (con otros 64 KB dedicados a vídeo).

Dado que Mega Drive necesitaba un Sonic a la altura para vender la máquina, en Sega le encargaron el proyecto a Yuji Naka, cocreador de la saga. Según explicaba en este vídeo con motivo del vigésimo aniversario de Sonic, Yuji tenía claro que los programadores no podían renunciar a la velocidad.

El nivel Green Hill Zone de Sonic

Naka lo explicaba así al recordar el origen del proyecto:

"Me gustan las cosas rápidas y pensé que sería interesante crear un juego en el que, cuanto más hábil te volvieras, menos tiempo necesitaras para completar un nivel".

"Los videojuegos de aquella época no tenían sistemas para guardar las partidas, así que cada vez que jugabas tenías que empezar desde el principio. Hoy en día puedes retomar un juego desde donde lo dejaste, pero entonces era necesario comenzar de cero".

"Como consecuencia, los jugadores repetían el primer nivel una y otra vez, hasta que terminaban dominándolo. Por eso pensamos que estaría bien aprovechar esa habilidad para que pudieran completar los niveles cada vez más rápido. Esa es la idea que dio origen a la velocidad de Sonic. También creímos que esta característica ayudaría a diferenciar a Sonic de Mario".

Un rival para Mario. Sega buscaba plantarle cara al dominio de Nintendo y su NES. El equipo que acabaría convirtiéndose en el Sonic Team quería crear un juego de acción frenético basado en la inercia y la velocidad. Ahora puede parecer algo corriente, pero a comienzos de los 90 no había nada parecido.

Recorrer el Green Hill Zone, sobre todo los míticos loopings, exigía simular continuamente las trayectorias mediante fórmulas trigonométricas. Calcular senos y cosenos en tiempo real habría saturado el procesador de la Mega Drive, con sus correspondientes tirones. Así que el equipo de Naka diseñó un motor a medida para superar esas limitaciones.

La solución. Esta consistía en guardar en el cartucho una especie de catálogo con los resultados listos de antemano. En vez de repetir operaciones complejas a cada momento, el motor de Sonic consultaba una tabla para encontrar el valor de cada ángulo y determinar cómo debía afectar al movimiento. Eran las llamadas tablas de consulta o "lookup tables".

Además de las tablas, los programadores del Sonic Team diseñaron otras soluciones ingeniosas para superar las limitaciones de la máquina:

• Dos sensores bajo los pies: detectaban la distancia al suelo y calculaban la inclinación de las pendientes para adaptar el movimiento de Sonic.
• Velocidad e impulso: la física permitía a Sonic aprovechar su velocidad para recorrer pendientes y superar los famosos loopings.
• Movimiento y animación independientes: la posición se actualizaba 60 veces por segundo (en NTSC, en Europa jugábamos con los 50 Hz de la versión PAL). Y los sprites cambiaban según la velocidad del personaje.
• Código optimizado: Naka utilizó la técnica loop unrolling para eliminar comprobaciones repetitivas y ahorrar ciclos del procesador Motorola 68000.
• Recursos concentrados en pantalla: los enemigos y objetos fuera de cámara dejaban de procesarse para reducir la carga del sistema.
• El mito del Blast Processing: Sega convirtió esa fluidez en un reclamo publicitario, aunque la rapidez de Sonic se debía principalmente a la optimización del código, no a un componente secreto.

Sega y Sonic Team lograron un juego que, a día de hoy, sigue maravillando por lo veloz que va, incluso en la Mega Drive, una máquina de hace 36 años. Aún recuerdo aquella primera vez que metí el cartucho en la consola, cargué el nivel Green Hill y me maravillé porque Sonic iba mucho más rápido que mi propia vista. No he vuelto a tener esa sensación de velocidad con ningún otro juego.

La optimización es historia. Yuji Naka y Sega demostraron que el ingenio y la optimización terminan rompiendo las barreras de la máquina. Es una lección que no parece haber cuajado lo suficiente, porque los desarrolladores de hoy en día tienden a crear auténticos monstruos con sus juegos. Gigas de recursos, requerimientos altísimos de hardware... Y luego tenemos consolas que son cada vez más caras solo para dar cobertura a todas esas necesidades.

La ironía de la vida parece que ha dejado a Nintendo como auténtica heredera de toda aquella optimización: los juegos de la Switch son un monumento a la optimización. Porque Sonic no necesitó una consola más potente para correr más rápido: requirió programadores que supieran aprovechar hasta el último ciclo del procesador. Treinta y cinco años después, no sería mala idea recuperar aquella filosofía.

Imagen de portada | Joshua Doherty para Unsplash