Si jugaste Crash Bandicoot en la PlayStation en 1996, te diste cuenta de algo cada vez que cargabas un nivel: siempre corrías en la misma dirección. Hacia adelante, hacia la pantalla. Caminos lineales a través de templos selváticos, ruinas antiguas y pasillos de fábricas, siempre avanzando en una dirección, sin posibilidad de dar marcha atrás o explorar hacia los lados. Ese diseño de pasillo se convirtió en el sello distintico de Crash. Y casi no tenía nada que ver con la intención creativa.

La verdadera razón era un problema matemático. La PS1 tenía 2 megabytes de RAM del sistema. Un solo nivel de Crash Bandicoot contenía entre 32 y 40 megabytes de datos.

No, no es un error tipográfico. Un juego que se ejecutaba en un hardware con 2 MB de memoria de trabajo necesitaba renderizar entornos que eran de 15 a 20 veces ese tamaño. La única pregunta era cómo.

El problema en números

| Qué | Tamaño | |---| | RAM del sistema PS1 | 2 MB (2.097.152 bytes) | | Nivel típico de Crash Bandicoot | 32 a 40 MB | | Datos cargados en un momento dado | Menos de 2 MB | | Bytes restantes en memoria al terminar | 4 |

Vale la pena detenerse un momento en esa última fila. Cuando Naughty Dog terminó Crash Bandicoot y grabó el disco para su lanzamiento, el juego se ajustó a su presupuesto de memoria de 2 MB con exactamente 4 bytes de sobra. No 4 kilobytes. No 400 bytes. Cuatro bytes, de un total de 2,097,152.

El "Streaming Engine" de Andy Gavin

Crash Bandicoot tuvo dos programadores: Andy Gavin y Jason Rubin. Gavin se encargó del motor, y la situación de la memoria le obligó a inventar algo para lo que la PS1 nunca fue diseñada.

Su solución fue un sistema de "streaming" desde el CD en tiempo real. Mientras el jugador corría por un nivel, el motor leía continuamente datos del disco del juego, extrayendo tres bloques de 64 kilobytes por segundo a una velocidad sostenida de aproximadamente 300 kilobytes por segundo. A medida que Crash avanzaba, los datos de la siguiente sección del nivel llegaban del disco a la RAM. A medida que se alejaba de las secciones anteriores, esos datos se descargaban de la memoria para dejar espacio.

La palabra clave es "hacia adelante". El "streaming engine" solo podía precargar de forma fiable en una dirección. Necesitaba predecir, con una precisión casi perfecta, qué datos necesitaría el jugador a continuación. Un camino bifurcado, una habitación a la que el jugador pudiera regresar, o cualquier diseño no lineal habría roto esa lógica predictiva y habría provocado que el juego se detuviera mientras intentaba cargar los recursos correctos.

"Teníamos niveles con más de 10 MB de datos, y esto tenía que paginarse dinámicamente, sin interrupciones.” Andy Gavin, sobre las limitaciones de diseño detrás de Crash Bandicoot.

Los pasillos lineales no fueron una elección estilística. Eran la única geometría de nivel que hacía funcionar el sistema de “streaming”. La arquitectura de la gestión de memoria del juego determinó la forma de cada nivel.

Lo que esto le costó a la unidad de CD

La tasa de “streaming” fue tan extrema que los ingenieros de hardware de Sony se alarmaron. Sony calificó la unidad de CD de PlayStation para aproximadamente 400,000 lecturas durante su vida útil. Cuando se compartieron internamente los números de “streaming” de Gavin, la respuesta de Sony fue de preocupación inmediata: al ritmo que Crash Bandicoot exigía al disco, el juego continuo agotaría una unidad en aproximadamente tres semanas.

La mayoría de los jugadores, por supuesto, no jugaban el juego continuamente. Pero la brecha en las especificaciones te dice hasta qué punto Naughty Dog había forzado el hardware más allá del uso previsto.

Metiendo 4 bytes en un presupuesto de 2 MB

La presión de memoria no terminó en la arquitectura de “streaming”. Gavin y Rubin pasaron la fase final del desarrollo exprimiendo código y datos de formas que no tenían precedentes.

Algunas técnicas eran estructurales, como el propio sistema de “streaming”. Otras fueron más desesperadas:

• Insertar datos en los dos bits inferiores de los punteros, explotando el hecho de que todas las direcciones de memoria en el procesador R3000 de la PS1 estaban alineadas a 4 bytes, dejando esos bits sin usar.
• Permutar código C en formas semánticamente idénticas pero sintácticamente diferentes para obligar al compilador a generar una salida 200 bytes más pequeña, luego 125, luego 50, luego 8.
• Auditar cada variable, cada recurso, cada byte de sobrecarga de tiempo de ejecución hasta que no quedara nada.

El número final fue de 4 bytes de memoria libre, de más de dos millones. Gavin documentó la historia completa en su blog, y se lee menos como un análisis post-mortem de desarrollo que como un rompecabezas resuelto en público.

Por qué esta historia de memoria pertenece a tu historia de videojuegos

Crash Bandicoot cumple 30 años este año. Muchos jugadores recuerdan el ataque giratorio, las cajas, la máscara de Aku Aku. Menos saben que la característica visual más distintiva del juego, esas carreras lineales por la jungla, provino directamente de la solución de un programador a una crisis de memoria.

Ese contexto no hace que el juego sea más nostálgico. Lo hace más interesante. Las limitaciones produjeron el diseño, y el diseño se convirtió en un referente del género.

Si Crash es parte de tu historia de videojuegos, el lugar para registrarlo es The EndWiki, donde puedes seguir cada clásico de PS1 que hayas jugado o planees jugar. El pilar Gaming Memories profundiza en por qué esas primeras sesiones de PlayStation producen el tipo de recuerdos que perduran durante décadas. Y si tu colección abarca múltiples plataformas, importa todo a la vez para construir la imagen completa de tu historia de videojuegos en un solo lugar.

Los 4 bytes no significarán nada hasta que sepas el costo de encontrarlos. Ahora lo sabes.