Boulder Dash, un jeu moderne de 1984

J’ai joué à Boulder Dash des heures et des heures sur Amstrad CPC 6128. Un petit bonhomme qui à mes yeux ressemblait à un extra-terrestre se frayait un passage dans des niveaux afin d’y collecter des diamants, tout en évitant les pièges formés par la présence de rochers instables et d’ennemis aux couleurs… limitées par la machine, mais bien visibles.

Sur cette machine, c’est probablement le jeu auquel nous avons le plus joué, en famille, chacun son tour, décortiquant les meilleurs mouvements pour se sortir des situations périlleuses de chaque niveau de ce puzzle game. Car Boulder Dash est un puzzle game avant tout, mélangé d’un peu d’appel aux réflexes du joueur pour certaines résolutions.

Le jeu débute sur un écran de titre avec une musique qui est toujours gravée dans ma mémoire. Et probablement pas que la mienne. Si ce n’est pas la musique de jeux vidéo la plus emblématique ou tout cas pas la plus connue de cette époque, elle a son lot de reprises et remixes. L’écran de titre fait aussi office de sélection des niveaux. Mais pas de tous. Les niveaux sont séparés en ensembles, et le menu ne donne accès qu’au premier niveau de chaque ensemble. Dans un premier temps, on essaie donc de réussir indépendamment chaque ensemble pour, une fois le jeu complètement maîtrisé, tenter la réussite de bout en bout.

Une fois la partie lancée, le niveau se révèle case par case puis le silence se fait. À présent, seul les bruitages du mouvement du personnage, la récupération des diamants et la chute des rochers ponctueront les niveaux. Il faut pouvoir se concentrer. C’est que ce n’est pas tout de comprendre la méthode, le cheminement, pour collecter le nombre minimal de diamants permettant l’ouverture de la sortie, il faut aussi maîtriser les mouvements du bonhomme. Et ces mouvements constituent le seul élément aléatoire de ce jeu sinon entièrement déterministe.

En effet, à chaque fois qu’une direction est donnée, de préférence au clavier car le timing est essentiel, le personnage va se déplacer vers la case voisine indiquée en un temps… aléatoire. La variance entre les temps est faible, mais donne un certain niveau de stress lorsque le niveau demande d’aller sur une case précise mais surtout pas la suivante ! Ce coquin peut en effet, aléatoirement, tout à fait enchaîner un déplacement lent, qui tendra à faire laisser le doigt du joueur un peu trop longtemps sur la touche, et un déplacement très court, provoquant le mouvement de trop.

Le reste, comme je l’ai dit, est parfaitement déterministe. La chute des éléments mobiles, rochers et diamants, se fait toujours de la même manière et toujours selon le même timing. Les entités mobiles, que l’on pourrait appeler ennemis car leur collision est fatale, ont des mouvements connues une fois observés.

Et ces éléments de gameplay, ces situations de chutes, sont parfaitement bien dosés. En termes modernes, on parlerait d’ingrédients de gameplay. Le level design, lui, pioche dans ces ingrédients pour les amener petit à petit, dans une progression bien dosées, à l’attention du joueur. Les premiers niveaux présentent des situations simples, puis chaque niveau apporte sa petite touche supplémentaire : limitations de l’espace de déplacement, ennemis qui bougent, ennemis qui gardent les diamants, ennemis qui génèrent les diamants, rochers bien arrimés, rochers piège qui ferment le chemin du retour, rochers provoquant des éboulements sans fin,…

J’ai récemment vu un remake de Boulder Dash, avec un rendu 3D précalculé digne des années 2000 qui n’avait apparemment par fait l’effort de l’exercice de lecture du jeu original, de la compréhension de son design qui le rend si intéressant et qui en faisait finalement un jeu moins maîtrisé que l’original. Le tout avec une musique qui n’égalait pas l’original.

Dans ce que l’on appelle le retrogaming, Boulder Dash fait pour moi office d’une pépite. Un jeu à la difficulté maîtrisée, prenant et qui plus est, techniquement bien réalisé. Si vous en avez l’occasion, je vous conseille d’y (re)jouer !

boulder-dash-low

Que la couleur soit !

Après avoir parcouru un tout petit morceau des débuts de l’affichage graphique des jeux vidéo dans l’article précédent, je continue ma vision personnelle de ce voyage.

Nous avions laissé les jeux vidéos sur des machines principalement dédiées à l’affichage de texte en noir et blanc. Ajoutons dans cet article un peu de couleurs.

La couleur est un vaste problème. Le premier étant que la grande majorité des moniteurs n’a pas de couleurs. C’est une époque de domination de l’écran à affichage monochrome, vert ou ocre. Mais cela existe, particulièrement pour les ordinateurs dits familiaux.

Le problème côté informatique est que la couleur est une information supplémentaire et qu’une information, on l’a vu dans l’article précédent, cela doit se stocker et donc nécessite de la mémoire.

Extrait de publicité GAI

Extrait de publicité DAI. Scanné par Frédéric Goset pour le site Abandonware Magazines

Mais la couleur est attendue, elle est même mise en avant dans les articles qui présentent de nouvelles machines. Combien de couleurs, choisies dans une palette à combien de possibilités ?

Pour offrir de la couleur en n’augmentant pas drastiquement la mémoire nécessaire, les astuces sont nombreuses et très diverses. Certaines machines n’admettent un changement de couleur que caractère par caractère. D’autres font un compromis entre taille du pixel et couleur.

La série de Amstrad CPC, au milieu des années 80, fonctionne comme cela : il y a trois mode d’affichages appelés avec grande originalité les modes 0, 1 et 2. Tous ces modes offrent le même nombre de lignes graphiques (200) mais diffèrent par leur nombre de pixels en largeur et le nombre de couleurs simultanément disponibles.

En fait, chaque ligne dispose de 640 bits de données. En mode 2, le plus précis, chaque bit représente un pixel, et la définition est donc de 640 par 200. Cependant, un bit ne code que deux informations, 0 et 1, soit deux couleurs différentes. Le CPC permet d’allouer à 0 une couleur et à 1 une autre couleur, les deux choisies parmi une palette prédéfinie.

En mode 0, chaque pixel est représenté par 4 bits. Cela donne un choix de 16 couleurs choisies parmi la même palette. Par contre, le nombre de pixel en largeur fait chuter la définition à 160 par 200.

Le mode 1 est le mode intermédiaire, et le mode par défaut dans lequel la machine s’allume : 320 par 200 et 4 couleurs.

Haute définition monochrome ou arc-en-ciel en gros pixels, ce type de choix était assez standard pour les machines de cet époque, lorsqu’elles offraient ce choix.

La couleur sur ce système n’est pas donnée directement mais passe par un concept de palette et de crayons. La palette est l’ensemble des couleurs que l’ordinateur est capable de générer vers l’affichage. 8, 16, 32 ou même 4096, cela dépend. À chaque crayon, dont le nombre est moins grand, est ensuite assigné une de ces couleurs.

Le nombre de crayons va déterminer le nombre de couleurs affichables simultanément à l’écran (hors astuce). Leur nombre réduit permet d’utiliser peu de mémoire tout en permettant d’utiliser une palette plus étendue.

Palette de 27 couleurs (combinaison des possibilités avec les composantes Rouge Verte Bleue à des valeurs nulles, moyennes, pleines). C'est la palette de l'Amstrad CPC.

Palette de 27 couleurs (combinaison des possibilités avec les composantes Rouge Verte Bleue à des valeurs nulles, moyennes, pleines). C’est la palette de l’Amstrad CPC.

Mais la stratégie des Amstrad CPC n’est pas la seule. Une autre consiste à se reposer sur la méthode des caractères semi graphiques déjà évoqués précédement et de donner aux blocs une couleur d’écriture (bloc allumé) et une couleur de fond (bloc éteint).

Ainsi, le ZX Spectrum code ses attributs de couleurs sur une grille de 32 par 24 qui correspond à son nombre de colonnes et lignes en mode texte. Dans chacune des cases de cette grille se trouve une couleur de fond et une couleur d’écriture. Le choix de couleur se fait sur une palette de 8 couleurs en mode soit normal, soit brillante, soit 16 teintes (en fait, 15, car le noir mat ou brillant se rend de la même façon). Chaque couleur peut donc être codée sur 4 bits, soit 8 bits pour les deux couleurs.

Cela donne 768 octets pour coder toutes les couleurs, ce qui est très acceptable à l’époque et très en dessous des 24ko qui auraient été nécessaire pour coder la possibilité de 16 couleurs sur chacun des pixels de la résolution graphique de 256 par 192.

Ce compromis provoque un artefact graphique bien reconnaissable. Comme les couleurs choisies sont forcément les mêmes pour un bloc graphique de 8 par 8 pixels, il arrive que la couleur d’un décors « bave » sur un élément en mouvement, ou inversement.

Exemple d'Attribute/Color clash (illustration du domaine publique disponible sur Wikipedia)

Exemple d’Attribute/Color clash (illustration du domaine publique disponible sur Wikipedia)

Je vous conseille d’aller jeter un œil à cette page avec des illustrations qui gèrent cet artefact.

Au fur et à mesure des générations, le nombre de couleurs pouvant être générées par la puce graphique va augmenter. Le nombre de couleurs pouvant être affichées simultanément aussi.

Progressivement vont être possible des modes marketés « vraies couleurs » où la palette est vaste et où toutes les couleurs sont affichables simultanément. Les modes où chaque pixels est codé sur 16 bits, pour un total de 65536 couleurs puis sur 24 bits, pour un total de 16 milions (et quelques) couleurs.

À ce stade là, la compétition entre carte graphique s’était déplacée sur un autre tableau dont je parlerai plus tard : la 3D.