Test et analyse de Zelda 1 :
Le tilemaping
Plateforme du jeu : NES
Développeur : NINTENDO
Voici notre première analyse de jeu du point de vue de la programmation. Ce premier test servira aussi à présenter ce qu'est le tilemaping, et comment il fonctionne.
Pour cela, nous allons tester l'un des plus grands jeux de la NES, qui a inspiré des centaines d'autres titres : The Legend of Zelda de Nintendo. Bien entendu, vous connaissez tous déjà ce jeu qui est devenu un classique (si non, il faut l'essayer d'urgence 
), et il serait inutile de tester ce jeu comme le font les magazines de jeux vidéo spécialisés (avec une note finale, etc... 
). Nous, ce qui nous intéresse, c'est la programmation et donc de voir comment d'autres ont fait, pour adapter ces techniques et les perfectionner dans nos propres jeux.
1. Screenshot issu de The Legend of Zelda, copyright Nintendo.
Ici, nous commençons vraiment avec les bases (eh oui, c'est le 1er test !) : le tilemapping dans un jeu en 2D.
 2. Screenshot issu de The Legend of Zelda, copyright Nintendo. |
Si nous examinons les deux screenshots 1 et 2, nous remarquons d'emblée que beaucoup de motifs sont (très) répétitifs. C'est particulièrement bien visible sur des jeux de cette époque. On le remarque aussi sur des jeux 16bits ou récents, mais moins. Pourquoi ? Tout simplement parce que si pour chaque niveau-écran de Zelda, il avait fallu stocker une grande image faisant tout l'écran, le jeu ne serait jamais rentrer dans la cartouche (ou alors il aurait été très très court  ) ! Bien entendu, aujourd'hui, avec les capacités de stockage actuelles, on pourrait le faire et certains jeux le font d'ailleurs (comme les point'n clicks par exemple).Mais par souci d'économies de la mémoire, et aussi par souci pratique comme nous allons le voir aussi, on a inventé la technique du tilemaping. |
|
Si on regarde bien notre écran, on aperçoit déjà deux grandes parties :
- le HUB en haut (nom anglais désignant les indicateurs de vie, score, etc.)
Le tilemaping ne concerne que l'affichage de la carte que parcourt Link. Le HUB est blitté (= affiché) au-dessus (il peut aussi être blitté par transparence par dessus l'écran de jeu (comme dans Wiwi's Adventures par exemple
).Si on observe maintenant la carte, on s'aperçoit qu'on peut la découper selon une grille régulière (cf. screenshot 3). Chaque carreau ainsi découpé est ce qu'on appelle une tile (ou tuile parfois en français). Sa taille est fixe : généralement 32 x 32 pixels mais sur le jeux plus anciens, elles pouvaient être de 8 x 8 ou 16 x 16, voire 8 x 16 pixels et peut monter à 64x64 ou plus dans des jeux HD. En tous les cas, sa taille est une puissance de 2 pour des facilités évidentes de calcul . |
 3. Screenshot issu de The Legend of Zelda, copyright Nintendo. |
C'est la question qu'on peut se poser a priori. Au début peut-être, mais on va voir que cela va nous simplifier la vie. En effet, si on reprend notre écran précédent et qu'on compte le nombre de tiles différentes : on n'en compte.... que 3 
? (cf. screenshot 4) Eh oui ! Cela veut dire qu'on peut afficher cet écran avec seulement trois dessins de tile de 32 x 32 pixels ! Quelle économie de mémoire !
Alors bien sûr, si on veut un jeu plus varié, on va utiliser plus de tiles différentes, mais c'est pour l'exemple!
Bon d'accord, on gagne de la mémoire, mais en quoi ça nous simplifie la vie ?
 4. Screenshot issu de The Legend of Zelda, copyright Nintendo. |
Eh bien, c'est là que ça devient intéressant ! Cela va nous simplifier la vie pour gérer les collisions de notre personnage! En effet, dans le jeu, Link peut marcher sur le chemin (tile 0) mais ne peut pas traverser les arbres (tile 1). Enfin, quand il marche sur les escaliers, il change de niveau (tile 3). Eh bien le jeu va gérer ça de la même façon que le joueur en fait. En utilisant la croix directionnel, Link va en effet se déplacer en haut, en bas, à gauche ou à droite de quelques pixels par seconde et à chaque fois, le programme va tester si la tile sur laquelle il se trouve est un chemin (on laisse avancer Link), un arbre (on empêche Link d'avancer et on le colle contre l'arbre), ou un escalier (on change de niveau). Ici, c'est très simple, car il n'y a que trois tiles : 0 = tile traversable, 1 = tile solide, 3 = tile spéciale -> changement de niveau, mais on peut complexifier comme dans Wiwi's Adventures. Le screenshot 5 indique par exemple le tileset de Wiwi's Adventures 1.5 et son résultat dans un niveau. |
5. Screenshot et tileset issus de Wiwi's Adventures II, copyright Meruvia Game Studio.
Eh bien, c'est ce que nous verrons dans la suite de notre tutoriel. Mais pour faire court, on va utiliser un tableau à 2 dimensions représentant l'écran de jeu, comme par exemple celui-ci pour l'écran de Zelda (screenshot 4) :
| 1 | 1 | 1 | 0 | 1 | 1, etc... |
| 1 | 1 | 1 | 0 | 1 | 1 |
| 0 | 0 | 0 | 0 | 0 | 0 |
Et dans notre boucle de jeu, la fonction chargée de l'affichage lira ce tableau et blittera la bonne tile au bon endroit : par exemple 0.png (représentant le chemin) quand on a 0, 1.png (représentant un arbre) quand on a 1 et 3.png (représentant les escaliers) quand on a 3. (Oui, je viens de m'apercevoir que j'avais zappé le 2 , c'est pas grave, on pourra la garder pour une autre tile .)
Idem pour les collisions, la fonction correspondante, vérifiera la tile présente aux coordonnées du joueur et agira en conséquence : elle laissera passer si c'est 0, bloquera si c'est 1 ou changera de niveau si c'est 3.
Dans mon tileset, c'est pareil, en un peu plus compliqué : les premières tiles sont traversables (dont certaines ramassables - mais on verra ça plus tard ), les suivantes sont traversables partout sauf en tombant dessus (plateformes traversables), les autres sont solides (et les premières cassables) et les dernières sont des tiles spéciales. C'est plus compliqué et on verra donc ça plus en détails dans un autre tuto ou une autre analyse !
