Deconstructulator

• Artiste: Ben Fry
• Lien: http://acg.media.mit.edu/people/fry/deconstructulator/

La machine Deconstructulator de Ben Fry permet tout simplement de voir les mécanismes de construction graphique du célèbre jeu video Super Mario Bros. pendant qu’on y joue. Au centre de l’écran, le jeu lui-même : Mario saute, cogne et tombe; il cherche des pièces de monnaie, écrase des méchants, et mange des champignons magiques; il s’aggrandit, se raptisse, et glisse dans de gros tuyaux. A gauche, nous voyons l’ensemble des icônes accessibles dans la mémoire « dure » de l’ordinateur, c’est-à-dire dans la cartouche physique qui l’alimente : chacune de ces images est composée par des tableaux de 8 pixels par 8 pixels. A droite, on voit ces images à l’oeuvre, c’est-à-dire celles qui sont actuellement utilisées dans la mémoire « volatile » ou « temporaire » de la machine : il n’y a que 64 de ces images (appellées des sprites) qui puissent être sur l’écran à un moment donné, ce qui implique un jeu de passe passe impressionnant de la part des concepteurs pour représenter une figure comme Mario. En réalité, Mario n’est même pas une « image » complète : il est une collection de 4 sprites agglutinés ensemble, et quand il s’inspire d’Alice au pays des merveilles et mange un champignon qui le fait s’aggrandir, il faut du coup 8 sprites pour composer sa figure (cf. Mariosoup). Ces 4 ou 8 sprites changent en permanence, comme on peut voir quand Mario se met à courir : toutes les positions de ses jambes (de la collection à gauche) sont utilisées tour à tour par le huitième sprite et neuvième sprite (à droite). Enfin, en bas de la fenêtre, nous voyons les « palettes » de couleurs : notons, par exemple que la huitième palette de couleurs change en permanence sa deuxième valeur; ce qui donne à la pièce de monnaie en haut de l’écran son apparence de pièce qui tourne. Car comme les sprites qui ne peuvent pas être en nombre supérieur à 64, les couleurs sont également limitées dans Super Mario Bros. : il n’y a que 8 x 4 couleurs qui puissent être sur l’écran à un moment donnée, ce qui limite la mémoire nécessaire pour animer le jeu vidéo, mais nécessite en retour beaucoup d’effort pour orchestrer la danse autour de ces peu de couleurs disponibles. Ces couleurs peuvent changer, comme on voit quand on passe surtout d’un niveau à l’autre, mais il n’y a que 8 x 4 disponibles à un moment donnée.

Derrière le rideau de la représentation, toute une activité de préparation à la figuration. Super Mario Bros. est surtout un jeu issu de l’architecture des machines de Nintendo. Il illustre cette architecture presque comme un mode d’emploi. Les machines de Nintedo ont pour la plupart privilégié la logique du sprite dans la construction de l’image. Du NES (Nintendo Entertainment System) au SuperNES, Gameboy, Gameboy Advance et même dans une certaine mesure l’actuel Nintendo DS, l’architecture est la même : un nombre limité de sprites bougent par dessus un nombre limité de « tiles » (carreaux) qui composent le fond. Ces deux matières sont ensuite colorés par des « palettes » qui déterminent les pixels de ceux-ci à partir d’un choix très réstreint de 32, 64, 128, ou 256 couleurs (selon le console). Le programme peut générer pratiquement n’importe quelle couleur, mais ne peut utiliser que ce nombre limité de couleurs en même temps. Le mouvement est également largément prédéterminé par l’architecture des machiens : les sprites et « tiles » peuvent bouger très facilement à l’horizontal ou à la vérticale ou les deux à la fois. Ensemble, ces deux composants donne presque sans effort supplémentaire la forme du jeu de plateforme comme Super Mario Bros. : en bougeant le fond sans bouger les sprites, ou en bougeant certains sprites dans le sens du fond et d’autres dans le sens inverse, on donne l’impression que le joueur découvre un espace continu beaucoup plus grand que l’écran lui-même.

Nous avons parlé plus haut d’un « jeu de passe passe » dans le remplacement des sprites sur l’écran. Celui-ci serait en même temps un jeu de chaises musicales, tellement les places disponibles se réduisent au fur et à mesure de l’avancée dans le jeu. Cette limitation matérielle du jeu est structurante pour son intrigue : on ne peut pas voir l’ensemble des figures sur l’écran, du coup on introduit des figures de plus en plus difficiles de mannière progressive. Cette arrivé progressive d’attaquants construit une sorte de narration interne au jeu et donne envie au joueur d’avancer pour découvrir ces nouveaux personnages : plus j’avance dans le jeu, plus les attaquants vont évoluer. Par conséquence, je vais moi aussi évoluer. Cette avancée est progressive avant tout parce que le nombre d’attaquants simultanés est réstreint matériellement. Mais l’attaque en goutte d’eau transforme le jeu en une véritable jeu de découverte ou d’aventure. Il illustre simultanément la progression de la narration et le rend même physique. Je sens par le stress que le jeu me provoque où je me trouve dans l’histoire.

Si Deconstructulator démontre les mécanismes de construction des sprites, il est assez silencieux sur la construction du terrain dans lequel Mario évolue (les carreaux, ou « tiles » en anglais). On voit sur la gauche les sous-tableaux qui composent ce fond, mais on n’a pas de représentation dans Deconstructulator autre que ce que nous voyons dans le jeu à proprement parler. Il se peut que le fait que le terrain n’évolue pas — c’est-à-dire que ce que nous voyons sur l’écran corréspond parfaitement (avec un rapport de 1:1) aux données qui le structurent — explique pourquoi Benjamin Fry n’a pas donné de représentation supplémentaire à cet aspect. Si nous voulons savoir comment les données du terrain sont structurées, nous n’avons qu’à regarder le terrain lui-même. Il n’empêche que — comme nous avons expliqué dans Mariosoup — le terrain du jeu est une des données les plus intéressantes du jeu Super Mario Bros.. Car le terrain est composé de deux données brutes — les carreaux (ou « tiles ») et la carte des carreaux — qui n’ont pas le même statut. Les carreaux sont des données brutes assez simples : elles décrivent les couleurs qui doivent être placées à tel ou tel emplacement. La carte, par contre, décrit l’emplacement de ces même carreaux, ce qui donne deux couches d’abstraction dans la construction de l’image. Toutes les deux données sont des listes de chiffres qui ressemble à ceci:

{{20 85 01 24 20 86 54 24 20 9A 01 24 20 A5 C9 24
20 BA C9 24 20 A6 0A 24 24 24 24 24 24 24 24 24
24 20 C6 0A 24 24 24 24 24 24 24 24 24 24 20 E6
0A 24 24 24 24 24 24 24 24 24 24 21 06 0A 24 24
24 24 24 24 24 24 24 24 21 24 14 24 24 24 24 24
24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 21
46 14 24 24 24 24 24 24 24 24 24 24 24 24 24 24
24 24 24 24 24 24 21 66 46 24 21 6C 0E 24 24 24
24 24 24 24 24 24 24 24 24 24 24 21 86 14 24 24
24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24
24 24 21 A6 14 24 24 24 24 24 24 24 24 24 24 24
24 24 24 24 24 24 24 24 24 21 C5 16 24 24 24 24
24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24
24 24 21 ED 0E 24 24 24 24 24 24 24 24 24 24 24}}

Mais dans le premier cas ces chiffres décriront les couleurs qui composent une l’image, alors que dans le deuxième cas ces chiffres décriront une image à partir des images définies précédément. Il aurait pu être intéressant alors de trouver une façon de décrire ce double-mouvement de données brutes dans des données brutes, car il s’agit de deux couches d’abstraction dans la figuration informatique. Il s’agit également d’une transformation à l’usage des données brutes en carrément des instructions fonctionnelles.

Nous mettrions également une réserve à l’usage du terme de « déconstruction » ici pour décrire ce qui est finalement de notre point de vue plutôt une forme d’analyse, proche en réalité de ce qui pourrait se faire en linguistique. La déconstruction, par opposition, est fondamentalement liée au principe Heideggerien d’« aletheia », c’est-à-dire à l’ambiguité du « dé-voilement » (cf. Heidegger Die Frage nach der Technik dans The Question Concerning Technology, p.21; et Heidegger Early Greek Thinking). Nous voyons les rapports entre le code et la figuration suffisament riches pour ne pas les simplifier à outrance comme un simple principe de mis-à-plat de la complexité du code. Le fait que le Deconstructulator rend lisible les principes de construction de l’image est une chose, mais il est très loin d’introduire une crise interne à ces deux couches comme le fait des machines comme Carbon (cf. zigzag) de Servovalve, le jeu untitled game et le site wwwwwwwww.jodi.org de JODI, ou plus important encore, car basé sur le même jeu de départ, Super Mario Clouds de Cory Archangel.