13 Juin 2022
Teenage Mutant Ninja Turtles sur NES (ou plutôt Teenage Mutant Hero Turtles chez nous à cause de la censure anglaise du mot Ninja qui donnera aussi Shadow Warriors chez Tecmo ou Blue Shadow chez Natsume) est un jeu Konami culte ici notamment grâce au bundle qui lui était dédié.
Dans ce billet je vais tenter de vous dévoiler quelques informations utiles que j’ai pu observer avec mes outils et qui soit un peu différente.
Je vais commencer par ma spécialité, la visualisation des hitbox, que je vais compléter avec des informations utiles sur les caractéristiques de chaque tortue que j'ai pu extraire du code.
Je suis notamment assez fier de ce premier gif qui permet de visualiser et comparer avec une grande précision les 3 attaques (front, up, down) de chaque tortue synchronisée. Un grand mystère enfin dévoilé ^^.
hitbox dynamique de chaque attaque
Un gif qui permet de constater que les attaques sont assez complexes. Ce n'est pas juste une hitbox statique et très brève comme dans la plupart des jeux de l’époque. Ici on a une longue séquence dynamique pour chaque attaque.
Une complexité qui permet une identité propre à chaque attaque. Le gif permet alors de comparer la durée, la portée et le déroulé de chaque attaque.
Parfois l'attaque frontale tape même dans le dos, ou au-dessus, ou revient plusieurs fois sur le devant (en faisant tourner l’arme).
Des attaques qui peuvent être très longues. Jusqu'à 42 frames pour l'attaque frontale de Donatello donc un très faible fire rate.
Mais ce n'est pas très grave car les ennemis/boss ont tous 48 frames d'invulnérabilités (autant que le joueur, ce n'est pas commun) donc peu d'impact sur le dps en duel (plus embêtant quand les ennemis sont nombreux ce qui est souvent le cas). Leonardo et Raphael ont un cycle d’attaque de 22 frames et 18 pour Michelangelo le plus rapide.
Les tortues se distinguent aussi par les dégâts de leurs attaques principales:
Leo: 7 dmg (+3 = 10 dmg)
Raph: 9 dmg (+0 = 9 dmg)
Mike : 7 dmg (+5 = 12 dmg)
Don: 15 dmg (+1 = 16 dmg)
Il faut savoir qu'il y a un mode berserk qui donne un boost de dégâts (c’est la partie que j’ai ajouté entre parenthèses) lorsque nos PV tombent en dessous des 50%.
Tout ça permet de donner une identité à chaque tortue. Et on constate que même le boost a des valeurs très variables selon leur "personnalité".
Il y a aussi 4 armes de jet dont vous pouvez observer les hitbox ici:
Hitbox des quatres armes de jet
Et voici les dégâts de chacune:
Shuriken: 18 dmg
Triple Shuriken: 14 dmg
Boomerang: 16 dmg
Kiai: 29 dmg
Le Kiai est très puissant mais aucun ennemi du jeu n'en drop. L’unique moyen d'en obtenir nécessite de faire des détours souvent coûteux.
Je conseille plutôt le boomerang qui fait encore plus de dégât qu'une attaque standard de Donatello tout en ayant un très bon fire rate et surtout utilisable à l'infini si on fait attention de les réceptionner à chaque fois. Sans oublier qu’il sont échangeables et donc partageables entre les tortues (en switchant après un lancé). Vraiment un incontournable!
Mais les hitbox des armes de jet ont un bug rigolo. Quand on s'accroupit ça abaisse la hitbox du joueur mais aussi celle de l'arme de jet même après l'avoir jeté donc on peut rectifier son tir après coup pour éliminer un petit ennemi 🙂.
Bug hitbox armes de jet
On remarque aussi sur ce gif que la hitbox des tortues en position debout dépasse largement au-dessus de la tête donc attention. On y gagne vraiment en s'accroupissant, plus qu’il y paraît.
Le saut bénéficie d’une hitbox dédiée lors de sa phase de spin en boule (ce n'est pas le cas dans Ninja Gaiden par exemple). Une hitbox vraiment petite à exploiter aussi.
Hitbox du saut
Sous l'eau il y a ce tourniquet de l’enfer qui a des hitbox mal placé, une dizaine de pixel trop haut. C’est bon à savoir pour prendre la bonne trajectoire.
J'ai aussi analysé un peu la physique. Il se trouve que sous l'eau, appuyer sur haut ou bas n'a aucun effet, ni sur les vitesses de montée ou descente, ni sur la hitbox. Le savoir permet de simplifier un peu ces épreuves de nage en se concentrant uniquement sur le mashing et la direction.
Le tourniquet de l’enfer
L'unique cas où le bouton “bas” a un effet (le bouton “haut” n’en a jamais) c'est quand on baigne dans un courant (indiqué par la trajectoire des bulles), peu importe sa direction. Dans ces conditions, si on appuie sur bas on va couler inéluctablement (la fréquence de mashing pour ne pas couler passe alors de 2,2 hz à 8,6 hz et même 11 hz si le courant est descendant, ça veut dire 11 fois par seconde. Autant dire impossible à tenir), ce qui est dangereux quand on passe au-dessus des algues/coraux mortelles.
Ne cherchez pas la logique. Le plus simple est de ne jamais appuyer sur haut ou bas, juste se concentrer sur le mashing de bouton pour les déplacements verticaux.
A cela j’ajouterais que sur l’axe horizontal il n'y a aucune inertie (démarrage et arrêt immédiat) ce qui facilite encore un peu plus les contrôles.
Ennemis et boss
Allons voir maintenant du côté des hitbox des ennemis et boss, c'est toujours amusant.
Par exemple, il y a cet ennemi dont la hitbox prend une taille extrême quand il tire. On ne comprend pas bien la raison. Le code va probablement piocher la mauvaise hitbox comme ca peut arriver parfois (j’ai déjà montré des exemples illustrés dans Ninja Gaiden 3, Astyanax ou Splatterhouse: Wanpaku Graffiti entre autre).
La mauvaise hitbox
Cet ED-209 donne l'impression de tirer un laser alors qu'en réalité ce sont quatres shots très serrés. Je pense qu'ils ont oublié de caper son fire rate donc il tire à chaque frame possible (et le jeu ne peut gérer que 4 shots ennemi max à l'écran). Sans doute un problème de finition parmi d’autre.
Quadruple shot
Le boss du stage 3 est gratuit mais c'est sympathique de le voir en action avec ses hitbox.
D'ailleurs il y a un bug ici aussi. Je ne le montre pas sur le gif mais si on active le menu pendant qu'il a la gueule ouverte alors ça referme sa gueule mais la hitbox reste active. On peut alors continuer de le frapper la gueule fermée.
Le T-Rex
Et bien entendu on ne va pas oublier le Technodrome très riche en hitbox. Ça vaut le coup de les visualiser .
Le Technodrome
J'ai aussi analysé la routine de sélection aléatoire de la position du Technodrome au stage 5 et j'ai fait une découverte intéressante et utile.
Comme vous le savez probablement déjà, le Technodrome se trouve aléatoirement dans l'un des 3 tunnels du stage correspondant mais ce que vous ne savez sans doute moins c’est que la routine utilisée pour faire ce choix aléatoire a un biais qui implique que le Technodrome à 2 fois plus de chance d'être dans le tunnel sud-ouest (E).
Probabilité emplacement Technodrome
A savoir aussi que lorsqu’on utilise un continu, ça efface la variable qui stock la position du Technodrome sans la réinitialiser. Elle est alors corrompue et quand cette variable est corrompue alors le jeu choisi par défaut le tunnel sud-ouest (E).
Ainsi dans cette situation (cette a dire apres usage d’un continu) c'est 100% de chance de le trouver ici. Voilà un bon protip ^^.
Quelques précisions pour mieux comprendre le système de PV du jeu.
Un seul segment rouge de PV pour le joueur ou les ennemis correspond en réalité à 16 PV dans le compteur interne. Le HUD à donc une précision limitée pour représenter la réalité des PV qui est donc approximative sur l’écran (comme souvent).
La règle de représentation pour chaque segment est la suivante:
[8 à 16 PV] = un segment plein
[1 à 7 PV] = une moitié de segment
0 PV = un segment vide
Les mobs ont entre 3 et 57 PV (le robot Kangourou).
Shreder est l'ennemi qui a le plus de PV et qui fait le plus de dégâts comme tout boss final qui se respecte. Il a 160 PV et il fait 58 de dégâts soit quasiment la moitié de notre barre de vie de 128 PV. Heureusement il est simple à manipuler comme on peut le voir ici:.
Shreder en mauvaise posture
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. Pas si difficile que ça (grâce au sacrifice de tortue que permet le jeu) mais qui en a quand même traumatisé plus d’un.
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) donc j'en ai fait une approximation simpliste et rapide.
Voilà ce que ca donne:
Hitbox champ d’algues
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.
Algue sans collision
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 ^^.
Risque maximum
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 ^^.
Avec un courant latéral c’est une autre histoire
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.
Les bulles indiquent la présence et le sens du courant
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.
Protip pour éviter la présence de courant dans le champ d’algues
Ç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).
Sans courant latéral c’est tellement plus simple
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.
Le second champ d’algues
A savoir aussi que dans le code du jeu j’ai pu observer qu’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.
Flickering 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.
Black strip composé de sprite
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.
Un HUD guirlande de noel
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).
Ca glitch sur les bords
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.
Une caméra mal adapté
Ce type de caméra pas très agréable 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 ennemis.
C’est embêtant comme caméra mais ça aurait pu être pire comme dans Super Turrican (pour lequel j’ai créé un code Game Genie qui corrige la caméra: TNTGVVAG + ANYGETEU).
Super Turrican
Cette caméra trahit donc une gestion un peu basique des spawns ennemis. Pourtant un jeu Konami bien plus vieux (1986) comme Castlevania avait déjà une gestion partiel du hors champ pour éviter ce genre situation sans sacrifier la caméra. C'est ce qu'il aurait fallu à TMNT pour recentrer la caméra.
L’autre alternative serait de faire un choix à la Ninja Gaiden avec uniquement des ennemis qui se one-shot ce qui réduit la nécessité de retrait et contourne un peu le problème mais TMNT avait sans doute besoin de différencier ses tortues par la puissance de leurs attaques et donc par la résistance relative des ennemis.
Des bonnes idées plutôt attrayantes mais beaucoup de maladresse un peu partout (technique, Game Design, Level Design) 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.
Il y aurait encore des choses à dire mais il faut savoir s'arrêter.
Ce genre d’analyse est assez représentatif de ce que j’aime faire et de ce que permettent aujourd’hui les outils modernes. Je le fais pour beaucoup de jeux de façon informel mais je n’ai pas le temps de les partager.
Malgré tout, je le fais quand même de temps à autre sur mon compte twitter qui contient beaucoup d’autres exemples de ce type.
Et en ce qui concerne plus particulièrement les hitbox, il y a plein d'autres exemples dans mon billet qui traite du sujet. Le billet est un peu daté par contre il réunit en fin de page toutes les autres analyses de hitbox que j’ai pu exposé et qui doit couvrir pas loin d’une vingtaine de jeux NES.
/image%2F2902198%2F20231214%2Fob_fe1742_megacdmini2.png)
/image%2F2902198%2F20230228%2Fob_ab04a3_miniature2.png)
/image%2F2902198%2F20221023%2Fob_3f70a8_arthur.png)
/image%2F2902198%2F20220714%2Fob_ca2383_18287-zelda-no-densetsu-the-hyrule-fa.png)