Mais si il y a bien un élément du jeu dont les joueurs veulent connaître tous les secrets c’est le célèbre champ d’algues du niveau de l’eau. Pas si difficile que ça.
En premier lieu il faut comprendre que les collisions avec les algues ne font pas appel à des hitbox à proprement parler. Les algues étant juste un élément du décors, les collisions les concernant se contentent d’exploiter plus ou moins la routine de collision déjà utilisée pour identifier celles entre le joueur et les murs/sol. C’est donc une toute autre routine très différente et c’est difficile d’avoir une représentation fidèle de ces collisions car elles sont complexes (et parfois contextuelles selon que l’on presse le pad ou pas) en voici une approximation simpliste et rapide.
Le premier constat qu’on peut faire c’est la très mauvaise concordance entre la map de collision et le visuel. Ils ont voulu donner un côté plus organique en ajoutant une variété de tuile partiel d’algue à la fonction uniquement esthétique pour éviter d’avoir un aspect trop “blocky” mais en termes de design c’est problématique.
On voit ici un exemple d’algue graphiquement présente mais physiquement inexistante. Le joueur se trouve alors face à une information visuelle inexploitable pour savoir quel trajet suivre.
Mais à partir du moment où l’on voit la « matrice » on peut alors se permettre ce genre de taquinerie et prendre des bains d’algues.
Avec une hitbox aussi large, les couloirs de 32 pixels du champ d’algues sont difficiles à négocier mais c’est faisable à condition qu’il n’y ai pas de courant comme c’est le cas sur le tout premier gif que je vous ai montré en tête du paragraphe mais pour être honnête, en situation habituel il y a bien un courant latéral et ça donne plutôt ça.
Impossible alors de se faufiler dans ces couloirs étroits avec seulement 5 pixels de marge tout en exécutant des secousses gauche-droite.
Mais ce courant latéral n’est pas une fatalité. Il est causé par un autre bug. En réalité, cette zone du champ d’algue est bien marquée comme une zone sans courant (observez les bulles qui montent tout droit à la vertical sans perturbation).
En effet ce courant latéral s’active dans l’écran précédent quand on s’approche de la zone de la bombe dans le coin à droite (c’est donc inévitable car on doit s’approcher de la bombe pour la neutraliser).
On peut identifier la présence de courant sous marin en observant la direction que prennent les bulles comme on peut voir sur ce gif a l’approche de la bombe.
Mais pourquoi ce courant n’est-il pas annulé quand on passe à l’écran du dessus qui n’en a pas?
Il y a une explication à ce bug. Le courant agit sur la partie décimale de la vitesse horizontale du joueur alors que les directions du Dpad agissent uniquement sur la partie entière sans jamais toucher à la partie décimale (ce qui est maladroit comme choix technique).
Donc même lorsque l’on sort de la zone de courant marin et que l’on veut s’arrêter avec le Dpad, il reste toujours un reliquat de la vitesse du courant stocké dans la partie décimale de notre vitesse horizontale (seul la partie entière tombe à zéro) qui nous pousse indéfiniment et qu’on ne pourra réinitialiser qu’en se posant au sol (car oui, entrer en contact avec le sol remet l’intégralité de la vitesse horizontale à zéro afin de stopper net le joueur).
La solution consiste donc à sortir de la zone de courant des bombes puis se poser au sol pour reset notre vitesse horizontale et ensuite revenir tout doucement vers la route du champ d’algues en s’arrêtant juste avant d’atteindre la limite de la zone d’activation du courant qui correspond à l’apparition à l’écran de la seconde colonne électrique.
Tout est résumé dans ce gif. Il suffit de reproduire cela.
Ça laisse peu de marge pour pouvoir monter vers le champ d’algues, juste quelques pixels, mais dans cette position on peut alors accéder au champ d’algue et cette fois sans activer le courant et le bug qui va avec. Il devient alors vraiment possible de franchir ce passage sans prendre de dégât (à condition d‘avoir quand même bien assimiler la map de collision au préalable).
Mais tout ça fait perdre un peu de temps donc faut pas traîner car le chrono peu généreux continue de tourner. Le défi reste donc intact.
Pour finir je vous montre quand même aussi le second champ d’algues du stage beaucoup moins célèbre car sensiblement plus simple mais qui mérite de dévoiler aussi ses secrets.
A savoir aussi que dans le code du jeu il existe une possibilité de courant ascendant mais qui n’est pas exploité dans le jeu (contrairement aux courants descendants utilisé en général au-dessus des algues/corraux jaunes mortelles que l’on voit juste sur ce dernier gif).
J’ai déjà évoqué plusieurs bugs dans les paragraphes précédents mais il y a un certain nombre d’autres éléments qui trahissent une technique un peu bancale ou un gros manque de finition. Autant l’art est plutôt sympathique (pixel art, musique, cutscene…), autant la technique est plutôt en retrait, surtout pour du Konami qui a très souvent montré un haut niveau de code sur NES.
Le premier constat concerne le framerate. TMNT est un jeu à 30 fps (ou 25 fps en PAL). Pas dramatique mais le standard étant le 60fps sur NES, c’est un peu décevant venant de Konami (cf. les Contra ou même Castlevania et son framerate 60fps ultra stable malgré que ce soit un très vieux jeu de 1986).
Mais parfois il est préférable de caper un jeu à 30 fps plutôt qu’avoir un framerate totalement instable comme le triste Contra Force toujours chez Konami (à ne pas confondre avec les Contra. C’est un reskin d’un jeu qui n’avait rien à voir avec la série). Malheureusement le 30 fps n’empêche pas TMNT d’avoir malgré tout des drops de frame assez fréquents.
Mais surtout le plus surprenant c’est que chaque fois qu’il y a une frame qui drop, le HUD glitch totalement comme on voit sur ce gif (il disparaît littéralement, c’est pas un bug d’émulation). Pour le coup c’est assez honteux d’avoir laissé passer un glitch de ce type car des drops il y en a souvent dans le jeu (en NTSC, beaucoup moins en PAL). Ça ne fait vraiment pas très pro. Le HUD qui glitch à chaque drop.
J’explique même pas comment ils ont pu laisser passer ça. Mais c’est aussi un indicateur intéressant pour le joueur. Chaque fois que vous voyez le HUD clignoter c’est que le framerate du jeu tombe sous les 30 fps (ou 25 fps en PAL).
Le problème du 30 fps sur NES ce sont les conséquences sur le flickering (clignotement) de sprite qui sert à contourner les limites d’affichage. En effet, la plupart du temps le flickering de sprite va aussi être géré en 30 fps comme le reste du jeu (même si c’est pas une obligation) ce qui implique un clignotement de sprite à 15 hz.
Et du flickering à 15 hz (12,5 hz en PAL) c’est vraiment désagréable surtout dans un jeu comme TMNT qui n’hésite pas à saturer régulièrement les sprites sans se préoccuper des limites. C’est pour cette raison qu’il est encore plus important sur NES qu’ailleurs de viser les 60fps. Ce jeu aurait vraiment gagné à être en 60 fps. Ça aurait aussi enlevé un peu de lag dans les contrôles.
Je me demande même si le saut lunaire du jeu n’est pas un reliquat des tout premiers builds qui visaient peut être le 60 fps car la valeur de gravité choisit dans le jeu correspond bien à celle qu’on trouve dans des jeux 60 fps mais ici appliqué qu’une frame sur 2 d’où le côté lunaire du saut (qui peut durer plus d’une centaine de frames).
Le jeu a aussi cette particularité d’ajouter à droite une bande noire composée de sprite. C’est une solution rarement utilisé (à juste titre) mais qu’on retrouve par exemple dans Ys, Felix the Cat ou Arumana no Kiseki, et qui sert à masquer les color glitch inévitables sur les bords quand il y a un scrolling multidirectionnel sur NES.
Sur une console qui ne peut afficher que 8 sprites sur la même ligne, c’est un choix vraiment discutable de réduire cette limite à 7 avec cette bande noire omniprésente, d’autant plus quand t’as l’idée saugrenu d’afficher une barre de vie composé de 8 sprites alignés sur la même ligne qui donc est condamné à clignoter sans discontinuer à cause du 9ème sprite ajouté par la bande noire.
C’est un choix assez étonnant car le flickering de sprite est par principe quelque chose de conjoncturel, réservé à une situation ponctuel de débordement, mais qui ici devient donc structurel. Encore une fois c’est assez curieux de laisser passer quelque chose comme ça.
Et tout ça (la bande noire) pour ne même pas réussir au final à cacher les glitchs de scrolling présent dans les 2 orientations verticale et horizontale (à gauche et en bas).
On a aussi une caméra avec des triggers tardifs ce qui implique que le joueur se trouve assez proche du bord de l’écran quand il progresse avec donc peu de visibilité et d’anticipation sur les ennemis qui surgissent. C’est d’autant plus problématique que les contrôles sont un peu laggé. Il vaut mieux connaître par cœur pour anticiper.
Ce type de caméra apparaît souvent comme une solution de facilité pour les jeux qui ont un système de spawn des ennemis un peu rudimentaire qui fait respawn les ennemis chaque fois qu’on fait reculer le scrolling d’un poil. Un recul souvent inévitable dans TMNT car les ennemis nécessitent plusieurs coups pour la plupart et donc des stratégies de retrait. Avec ce type de trigger tardif de la caméra on peut alors reculer un petit peu sans faire reculer le scrolling et donc sans faire respawn trop vite les ennemi.
Pour conclure il y a de bonnes idées mais beaucoup de maladresse un peu partout (technique, Game Design, Level Design), ce qui semble peut être trahir qu’il s’agit d’une équipe peu expérimentée. Mais il est difficile d’avoir des informations sur le développement de ce jeu qui sera pour beaucoup de personnes leur premier jeu vidéo, car il était en bundle avec la NES.