Si vous avez joué à Crash Bandicoot sur PlayStation en 1996, vous avez remarqué quelque chose à chaque fois que vous chargiez un niveau : vous couriez toujours dans la même direction. Toujours vers l'avant, vers l'écran. Des chemins linéaires à travers les temples de la jungle, les ruines antiques et les couloirs d'usine, toujours dans une seule direction, sans possibilité de faire demi-tour ni d'explorer sur le côté. Ce design en couloir est devenu la signature de Crash. Et cela n'avait presque rien à voir avec une intention créative.

La vraie raison était un problème de maths. La PS1 avait 2 mégaoctets de RAM système. Un seul niveau de Crash Bandicoot contenait 32 à 40 mégaoctets de données.

Ce n'est pas une faute de frappe. Un jeu fonctionnant sur un matériel avec 2 Mo de mémoire de travail devait rendre des environnements 15 à 20 fois plus grands. La seule question était de savoir comment.

Le Problème en Chiffres

La dernière ligne mérite qu'on s'y attarde un instant. Quand Naughty Dog a terminé Crash Bandicoot et pressé le disque pour sa sortie, le jeu tenait dans son budget mémoire de 2 Mo avec exactement 4 octets de marge. Pas 4 kilo-octets. Pas 4 cent octets. Quatre octets, sur un total de 2 097 152.

Le Moteur de Streaming d'Andy Gavin

Crash Bandicoot avait deux programmeurs : Andy Gavin et Jason Rubin. Gavin s'occupait du moteur, et la situation de la mémoire l'a forcé à inventer quelque chose que la PS1 n'avait jamais été conçue pour supporter.

Sa solution a été un système de streaming CD en temps réel. Pendant que le joueur parcourait un niveau, le moteur lisait en continu des données depuis le disque du jeu, important trois blocs de 64 kilo-octets par seconde à un débit soutenu d'environ 300 kilo-octets par seconde. Au fur et à mesure que Crash avançait, les données de la section suivante du niveau arrivaient du disque dans la RAM. Quand il s'éloignait des sections précédentes, ces données étaient déchargées de la mémoire pour libérer de la place.

Le mot clé est "avant". Le moteur de streaming ne pouvait précharger de manière fiable que dans une seule direction. Il devait prédire, avec une précision quasi parfaite, quelles données le joueur aurait besoin ensuite. Un chemin ramifié, une salle où le joueur pourrait revenir en arrière, ou toute disposition non linéaire aurait brisé cette logique prédictive et aurait fait planter le jeu en cherchant à charger les bons éléments.

"Nous avions des niveaux avec plus de 10 Mo de données, et cela devait être paginé dynamiquement, sans accroc." Andy Gavin, sur les contraintes de conception derrière Crash Bandicoot.

Les couloirs linéaires n'étaient pas un choix stylistique. C'était la seule géométrie de niveau qui permettait au système de streaming de fonctionner. L'architecture de la gestion de la mémoire du jeu a déterminé la forme de chaque niveau.

Ce Que Cela A Coûté au Lecteur CD

Le débit de streaming était suffisamment extrême pour que les ingénieurs hardware de Sony en soient alarmés. Sony avait évalué le lecteur CD de la PlayStation pour environ 400 000 lectures au cours de sa vie. Lorsque les chiffres de streaming de Gavin furent partagés en interne, la réponse de Sony fut une inquiétude immédiate : au rythme exigé par Crash Bandicoot, un jeu continu épuiserait un lecteur en environ trois semaines.

La plupart des joueurs, bien sûr, ne jouaient pas au jeu en continu. Mais l'écart des spécifications vous indique à quel point Naughty Dog avait poussé le hardware au-delà de son utilisation prévue.

Faire Entrer 4 Octets Dans un Budget de 2 Mo

La pression sur la mémoire ne s'est pas arrêtée à l'architecture de streaming. Gavin et Rubin ont passé la dernière ligne droite du développement à compresser le code et les données d'une manière sans précédent.

Certaines techniques étaient structurelles, comme le système de streaming lui-même. D'autres étaient plus désespérées :

• Tasser des données dans les deux bits de poids faible des pointeurs, exploitant le fait que toutes les adresses mémoire du processeur R3000 de la PS1 étaient alignées sur 4 octets, laissant ces bits inutilisés
• Permuter le code C sous des formes sémantiquement identiques mais syntaxiquement différentes pour convaincre le compilateur de générer une sortie 200 octets plus petite, puis 125, puis 50, puis 8
• Auditer chaque variable, chaque ressource, chaque octet de surcharge d'exécution jusqu'à ce qu'il ne reste plus rien

Le nombre final était de 4 octets de mémoire libre, sur plus de deux millions. Gavin a documenté toute l'histoire sur son blog, et cela se lit moins comme un compte-rendu post-mortem de développement que comme un puzzle résolu en public.

Pourquoi Cette Histoire de Mémoire A Sa Place Dans Votre Histoire du Jeu Vidéo

Crash Bandicoot a 30 ans cette année. Beaucoup de joueurs se souviennent de l'attaque tournoyante, des caisses, du masque Aku Aku. Moins nombreux sont ceux qui savent que la caractéristique visuelle la plus distinctive du jeu, ces courses linéaires dans la jungle, est venue directement d'une solution programmée à une crise de mémoire.

Ce contexte ne rend pas le jeu plus nostalgique. Il le rend plus intéressant. Les contraintes ont produit le design, et le design est devenu une référence du genre.

Si Crash fait partie de votre histoire du jeu vidéo, l'endroit pour le consigner est The EndWiki, où vous pouvez suivre tous les classiques PS1 auxquels vous avez joué ou que vous prévoyez de jouer. Le pilier Gaming Memories approfondit pourquoi ces premières sessions PlayStation produisent le genre de souvenirs qui restent gravés pendant des décennies. Et si votre collection s'étend sur plusieurs plateformes, importez tout en une seule fois pour construire l'image complète de votre histoire du jeu vidéo en un seul endroit.

Les 4 octets ne signifieront rien tant que vous ne saurez pas ce qu'il a fallu faire pour les trouver. Maintenant, vous savez.