Meruvia - Analyse : les collisions

Test et analyse de Zelda & Mario :
Collisions entre sprites

Plateforme : NES
Développeur : NINTENDO

Et voilà donc notre deuxième analyse de jeu du point de vue programmeur, qui va nous amener à réfléchir à la notion de collisions entre sprites.

Pour cela, nous allons encore nous appuyer sur : The Legend of Zelda de Nintendo sur NES (et ses successeurs en 2D), mais aussi sur : Super Mario Bros.

1. Screenshot issu de Super Mario Bros NES, copyright Nintendo.

2. Screenshot issu de Super Mario Bros NES, copyright Nintendo.

Commençons sans doute par le cas le plus simple : Super Mario Bros.

Pour détecter les collisions entre le joueur (Mario) et les ennemis, on va utiliser la technique des bounding box. C'est-à-dire qu'on va considérer Mario et les ennemis comme des rectangles et qu'on va tester s'ils se touchent (cf. screenshot 2).

Si les rectangles se touchent, c'est que Mario et un ennemi entrent en collision. Mais alors que faire ? Eh bien, cela dépend de la position de Mario et de son ennemi.

J'ai choisi Mario comme premier exemple, car c'est relativement simple. Mario ne gère que deux types de collisions :
1. Mario saute sur la tête de son ennemi, l'ennemi est aplati

!
2. Mario touche l'ennemi sans être au dessus de lui : il rapetisse ou meurt

!

Dans le premier cas (cf. screenshot 3), on va d'abord tester s'il y a collision puis on va tester si Mario est bien au-dessus du sprite du monstre, en laissant une certaine marge de manoeuvre pour éviter les morts frustrantes dues au pixel perfect

3. Screenshot issu de Super Mario Bros NES, copyright Nintendo.

Si Mario fait 40 pixels de haut par exemple et que ses pieds en font 10, on pourra vérifier si : positionMario.y + tailleMario - taillePieds < positionEnnemi.y .

Soit, si Mario est à y = 205 et l'ennemi à y = 240 :
positionMario.y + tailleMario - taillePieds < positionEnnemi.y
205 + 40 - 10 < 240
= 235 < 240

Dans ce cas, les deux sprites se touchent et les pieds de Mario recouvrent de 5 pixels le dessus du monstre -> donc le monstre est aplati !

4. Screenshot issu de Super Mario Bros NES, copyright Nintendo.

Dans tous les autres cas (il suffit d'un else

), Mario rétrécit ou meurt.

Le screenshot 4 donne un aperçu de ces possibilités : Mario est touché par devant ou par derrière alors qu'il touche le sol, par au-dessus (carapace qui lui tombe sur la tête

), etc.

C'est sans doute le cas le plus simple à programmer, mais nous allons voir maintenant que pour un jeu comme Zelda, ça ne peut pas vraiment marcher...

En effet, Link est vu du dessus et ne peut pas sauter (screenshot 5). Si on réutilise notre technique des bounding box autour de lui, on peut facilement savoir s'il entre en collision ou non avec un monstre, mais comment savoir comment réagir à cette collision ?

5. Screenshot issu de The Legend of Zelda sur NES, copyright Nintendo.

En effet, il faut d'abord savoir s'il attaque ou non : on pourrait donc envisager un booléen isAttacking, qui serait soit true, soit false. Si la collision a lieu quand Link attaque, on tue le monstre, sinon, Link perd des points de vie.

Cela a l'air bien a priori , mais : et si Link attaque avec son épée vers le haut, et que le monstre arrive par derrière ou sur un côté ? Eh bien le monstre sera tué , ce qui n'est pas logique. Alors bien sûr, on pourrait rajouter d'autres variables pour envisager toutes les possibilités, mais il y a beaucoup plus simple (ouf ! ).

6. Sprites de Link, copyright Nintendo.

Il suffit en fait de dissocier Link de son épée, à l'aide de deux sprites différents et de faire deux détection des collisions distinctes (cf. illustration 6). En plus, si Link doit changer d'arme, il suffit de changer le sprite de l'épée (ce qui est plus simple

).

On va donc désormais faire 2 détections de collisions bounding box par boucle de jeu :
1- La première : player (Link) - monstre : s'il y a collision, on enlève un coeur à Link.
2- La deuxième : épée - monstre : s'il y a collision, on tue le monstre (par exemple).

Et voilà qui est tellement plus simple et qui gère tous les cas de figure.

Pour finir les illustrations 7, montrent l'adaptation de cette technique aux jeux Wiwi's Adventures et Legend of Meruvia.