DU CLONAGE CHEZ KONAMI?

4 Octobre 2021

J'aime beaucoup dénicher les influences entre les jeux et bien entendu les exemples ne manquent pas puisque c’est un peu dans l’ADN du jeu vidéo de s’inspirer les uns les autres. Par exemple, j'ai déjà écrit un billet sur le Star Wars Famicom de Namco (Quand Star Wars mime Alex Kidd). Un projet qui s’est clairement construit sur les bases de Alex Kidd in Miracle World. C’est l’une de mes découvertes préférées.
Ou plus récemment ce thread twitter sur la filiation plus subtile entre Ninja Gaiden et Castlevania.

Mais cette fois on est dans un cas de figure d’un tout autre niveau que je n’avais jamais vu jusqu'à maintenant et qui mérite largement un billet.
Il s’agit de Tiny Toon Adventures de Konami sur NES qui fait bien plus que seulement s’inspirer de Super Mario Bros 3 ou le copier de façon empirique en le regardant tourner comme le ferait d’autres. Konami a très probablement fait du reverse engineering sur SMB3 pour piquer une partie des datas qui contrôle le gameplay et la physique du jeu. Je vais essayer de vous convaincre de la forte crédibilité de cette hypothèse surprenante.

Les premiers soupçons...

Avant d'évoquer les éléments vraiment troublants, je commence d’abord en douceur par les indices ordinaires que beaucoup ont déjà pu observer et par lesquels le doute s’est immiscé. Mon envie de creuser plus loin n’est effectivement pas venu par hasard.

Le premier point commun évident c’est tout d’abord ce gameplay que j'appelle "pure platformer". C'est à dire un gameplay entièrement focus sur le saut qui est indispensable même dans les confrontations avec les ennemis (SMB, Sonic, Ducktales…). On saute sur les ennemis pour les éliminer et avec aussi cette possibilité en plus de rebondir dessus pour exécuter un super saut. Des éléments que l’on retrouve dans ces 2 jeux.

Le cœur du gameplay: Je saute, j'élimine, je rebondis

On retrouve aussi ces surfaces inclinées qui étaient l'une des nouveautés de SMB3 (absent de SMB1 et SMB2). C'est pas si anodin car pas fréquent à l'époque. TTA propose les 2 mêmes variantes de pentes au ratio de tuile 1:1 et 1:2 (45° et 27°) ni plus ni moins. Mais surtout on constate la même mécanique de glissade associée à ces pentes avec le même déclencheur (presser le bouton bas) et exactement la même fonction qui est de donner au joueur une forte accélération et surtout offrir un moyen alternatif pour éliminer les ennemis sur le trajet en les percutant. Et ça c'était vraiment pas obligé, c'est très marqué "SMB3".

Les costumes de Mario sont en quelque sorte remplacés ici par les capacités des différents Tiny Toons. On remarque que la capacité de Plucky est exactement la même que celle du costume Raccoon de SMB3 qui permet de planer en mashant le bouton.

On constate aussi les mêmes configuration de stage et dans une répartition équivalente. C’est à dire des stages majoritairement à scrolling horizontal (avec backtracking) parfois sur un seul écran de haut et parfois avec une verticalité sur 2 écrans (avec un scrolling multidirectionnel dans ce cas) et bien plus rarement des stages uniquement verticaux mais d'un seul écran de large. TTA suit de près la recette dans les mêmes proportions.

Du côté plus technique on remarque aussi la même gestion et configuration du scrolling en mirroring horizontal double screen avec la colonne de background et de sprite désactivée sur la gauche de l’écran et les color glitch sur la colonne de droite. Je ne vais pas entrer plus dans les détails techniques mais pour résumer on perçoit aussi l’influence sur ce point même en restant en surface.

Et sur la forme on a ce HUD à la configuration très similaire, au raster ( les gros HUD comme cela en background sont effectivement le résultat d’un raster effect, pas si simple quand il y a un scrolling multidirectionnel), placé au même endroit avec le même style visuel (et petit glitch de synchro à la transition) et surtout une police de caractère des chiffres qui est quasiment la même malgré qu'elle ne soit pas si classique.

On peut même noter que dans des builds plus anciens le timer était représenté par un petit cadran d'horloge comme dans SMB3 pour finalement être remplacé par un T.

un cadran d'horloge pour le timer en bas a droite

On pourrait sans doute trouver d'autres points communs de ce type mais ces éléments de surface, que certains avaient déjà remarqué, ne sont pas ceux qui m'ont interpellés et qui justifient ce billet, ça ne serait vraiment pas suffisant.
Si ces éléments ont eu le mérite de chatouiller ma curiosité, ce qui m'a vraiment interpellé est apparu lorsque j'ai creusé à l'intérieur du jeu. C’est bien moins accessible au tout venant mais beaucoup plus révélateur.

Les preuves troublantes

Grâce à des outils je suis donc allé récupérer dans le jeu les données qui contrôlent certains éléments du gameplay et de la physique de Tiny Toon Adventures pour avoir des éléments de comparaison objectifs et quantifiables avec précision et c’est là effectivement que ça devient très troublant...

Super Mario Bros 3 est un jeu qui propose 3 paliers de vitesse de déplacement. La marche, la course en pressant un bouton, et la super course qu’on enclenche dans certaines conditions (et avec une animation dédiée). C’est quelque chose d’assez singulier et propre à SMB3 (voir unique?) et pourtant qu’on retrouve dans TTA… mais ce n’est pas tout! On retrouve exactement les 3 mêmes valeurs Vmax de 1.5 , 2.5 et 3.5 pixels par frame qui cape la vitesse de chacun de ces paliers… mais ce n’est pas tout! La mécanique pour enclencher la super course est strictement la même (et avec aussi une animation dédiée), c’est à dire qu’il faut atteindre la vitesse max de la course (2.5 ppf) et ensuite la maintenir pendant exactement 49 frames pour enfin enclencher la super course (qui permet de monter jusqu'à 3.5 ppf), ceci dans les 2 jeux!

Exactement 49 frames pour enclencher la super course dans les 2 jeux

Mais il y a encore plus surprenant sur ce point. La routine qui permet d'activer la super course dans SMB3 (le "Power") est plus complexe que simplement compter 49 frames. En réalité c'est une routine qui check uniquement toutes les 8 frames (ou 24 frames quand la jauge se vide) si toutes les conditions sont bien réunies et si c'est le cas alors la routine remplit un segment supplémentaire du "Power Meter" que l'on aperçoit dans le HUD. En effet SMB3 affiche une jauge composée de 7 segments pour indiquer au joueur si la "super course" est sur le point de s'enclencher.

La jauge de super course de SMB3 ou "Power Meter"

Si je vous explique tout ça c'est parce que TTA n'affiche pas de jauge de ce type à l'écran (la jauge que l'on aperçoit concerne une autre feature) et pourtant on retrouve exactement la même routine, le même bout de code, qui en interne remplit la même jauge de 7 segments que SMB3 à la différence qu'elle ne sera donc jamais affiché!
Et comme c'est la même routine, on peut donc aussi exploiter les mêmes tricks utilisés dans les TAS (Tool-Assisted Speedrun) de SMB3 qui consistent à exploiter ce petit délai de liberté entre 2 check.

La vitesse dans Tiny Toon est encodée exactement dans le même format à virgule fixe 4b.4b que je n'ai vu que dans SMB3 (même pas dans SMB1), en général c’est plutôt du 8b.8b (voir du 3b.5b). L'accélération/inertie utilise aussi la même valeur de base 0.10 que SMB3 mais surtout le même mécanisme qui consiste à “sauter” certaines frames (des frames ou aucune accélération n’est appliqué) pour obtenir une finesse d'accélération/inertie supérieure à ce que permet ce format 4b.4b un peu limité.
Et cela avec une méthode de sélection des frames à "sauter" assez étrange et bizarroïde que je n’ai vu que dans SMB3 et qu’on retrouve pourtant dans TTA (code très similaire) sauf que ce dernier applique ce mécanisme uniquement pour la décélération (inertie). Donc au final, malgré une valeur de base commune, l’accélération effective est légèrement supérieure dans TTA.

On retrouve aussi la petite glissade quand on se met accroupi pour passer sous un bloc ainsi que les mêmes valeurs d’accélération lors des glissades en pente. Une accélération de 0.12 dans les pentes à 45° et 0.06 dans les pentes à 27°. Par contre la Vmax de la glissade est capée plus bas dans TTA.

L’autre gros morceau très intéressant à analyser et comparer c’est évidemment le saut qui est au centre du gameplay et cette unique comparaison devrait suffire à convaincre n’importe qui tellement elle est édifiante car il existe vraiment beaucoup de façons de paramétrer le saut dans un jeu, des milliers, aucune raison d'avoir 2 fois la même.

D'abord dans TTA et SMB3 on a un saut avec nuancier vertical et air-control total (la même inertie horizontale qu’au sol, pas plus).
Ensuite la verticalité du saut dans un platformer est en général définie par une impulsion initiale (la vitesse verticale à laquelle se propulse le personnage au moment où l'on appuie sur le bouton saut) et la force de gravité qui tend à le faire retomber. Dans SMB3 il y a même 2 valeurs différentes de gravité selon les conditions. On retrouve tout ça à l'identique dans TTA. La même force de gravité faible de 0.06 tant qu’on maintient le bouton saut (comme si on était sur la Lune) et une force de gravité forte de 0.31 (retour sur Terre) quand on lâche le bouton ou que la vitesse verticale passe en dessous des 2 pixels par frame (donc quand on approche du sommet du saut).

La même physique, les mêmes comportements

Ca fait donc déjà 3 valeurs identiques en plus d'avoir les mêmes mécanismes déclencheur mais ce n’est pas tout! Il se trouve que SMB3 a pas moins de 5 types de saut différent avec 5 valeurs différentes d’impulsion de saut (5 hauteurs potentielles différentes) qui dépend de la vitesse de déplacement horizontal selon des paliers bien définis (excepté pour la 5ème hauteur de saut qui est celle du saut de rebond sur un ennemi).
On va non seulement retrouver ce même panel de exactement 5 sauts différents dans TTA mais avec aussi strictement les mêmes 5 valeurs d’impulsion à la décimal prêt (respectivement 3.44, 3.56, 3.69, 3.94 et 4.00 ppf) qui s'enclenche sur les mêmes palier de vitesse (moins de 1 ppf, entre 1 et 2 ppf, entre 2 et 3 ppf et plus de 3 ppf). La seule chose qui diffère c’est la valeur qui sert à caper la vitesse max de chute qui, comme pour la glissade en pente, est plus basse dans TTA.
Mais on a donc 10 des 11 valeurs qui caractérisent le saut de SMB3 présent à l'identique à la décimal prêt dans TTA. Un sacré score!

On peut aussi revenir rapidement sur ce vole plané de Plucky qui utilise exactement le même tempo que le Racoon de SMB3. Chaque fois qu'on appuie sur le bouton saut on plane pendant exactement 16 frames donc il faut masher le bouton à une fréquence minimum de 3.75 hz dans les 2 cas pour avoir un vole plané optimal. Un paramètre de plus qui s’aligne sur la même valeur (par contre la vitesse de chute du Racoon est 2x plus élevé que Plucky, tout n’est pas identique évidemment).

Même la gestion de la caméra est parfaitement similaire. Il y a des milliers de façon de gérer et calibrer une caméra dans un jeu 2D (jetez un œil rapide sur cet article plein d’exemples en gif: Theory and practice on the camera in platformers) mais comme par hasard dans TTA on va encore une fois retrouver les mêmes paramètres à l’identique. Le point de contrôle du metasprite qui sert à piloter la caméra placée au même endroit avec exactement le même cadre, la même fenêtre (largeur, hauteur, position), pour trigger la caméra.

Les mêmes points de contrôle et triggers de camera au même endroit

Il faut bien comprendre que les marqueurs que l’on voit sur ce gif ce n’est pas moi qui les ai placés ici. Mon script ne fait qu'utiliser les données générées par le jeu lui même pour placer ces marqueurs.
Et si on superpose les images des 2 jeux ces marqueurs se confondent parfaitement au pixel près. Ce sont 6 valeurs identiques de plus.

Mais comment?

J'ai énuméré un paquet de mécaniques et de valeurs précises qu’on retrouve à l'identique dans les 2 jeux (il y a aussi des différences bien sûr, TTA n’est pas SMB3, la plus marquante selon moi étant la perte de nuancier vertical du saut quand on court dans TTA, un choix curieux et très discutable). On pourrait sans doute en trouver d'autres en continuant l’investigation mais ça me paraît déjà largement suffisant pour affirmer que ce n'est pas une coïncidence évidemment.

Le hasard n’a rien à voir là dedans. Il est même impossible d'obtenir tout cela juste en observant le jeu tourner, empiriquement, comme le faisaient habituellement les autres développeurs dans leurs tentatives de mimétisme. Même entre les Megaman NES, faisant donc partie de la même série par la même équipe et considérés comme des sortes de copier-coller, je ne trouve pas autant de similitudes (à part entre l'épisode 4 et 5 qui sont vraiment très jumeaux sur les valeurs de gameplay/physique). A cette époque chaque jeu est une pièce unique. Donc il s’est clairement passé quelque chose sur ce TTA pour qu’il y ai autant de similitudes, quelque chose que je n'avais jamais observé ailleurs jusque là.

Tout ça me rappelle aussi un peu le cas des samples WSG de Zelda Famicom Disk créés par Konji Kondo et que l’on retrouve à l'identique, octet pour octet, dans le catalogue de sample des jeux Konami FDS. Plus de détails dans ce billet: Le pixel art audio sur Famicom Disk System.

Les samples WSG dans les jeux Konami Famicom Disk comparé à Zelda

La relation entre Nintendo et Konami semble décidément pleine de surprise. Est ce que Konami a eu accès au code source de SMB3? Ce n'est pas l’hypothèse qui a ma préférence. Ça me paraît peu probable. Même pour les portages officiels de jeux d'arcade ou de jeux console/micro sur d'autres plateformes, les codes sources ne circulaient pas. La très grande majorité du temps les éditeurs se contentaient de fournir le jeu, la console ou la board arcade, à l'équipe en charge du portage mais pas le code source. Libre ensuite au programmeur de jouer encore et encore au jeu pour tenter de reproduire au mieux le gameplay. Souvenez-vous de tous ces portages de jeux d'arcade sur les micros 8/16bit...
Même le portage de grosses licences sur de grosses consoles comme Megaman sur Megadrive ou Ninja Gaiden sur PC-Engine, étaient conçu à priori dans les mêmes conditions, de façon empirique, sans code source, et donc sans aucune fidélité dans la physique et le gameplay avec les originaux. Et là on parle de projets au service et sous le controle d'un éditeur commun. C'est dire si c'est pas simple à cette époque de transférer un gameplay d'un jeu à un autre. Alors entre 2 éditeurs et 2 jeux qui n'ont rien en commun...

Je ne vois personne non plus de l'équipe de TTA qui viendrait de SMB3. Et puis lorsque je compare le code des 2 jeux, je peine à trouver des similitudes. Le code semble très différent (même la routine IRQ qui gère le raster effets du HUD est radicalement différente). De plus, Konami est plutôt reconnu pour la qualité de leur code dans les jeux NES, je ne les imagine pas se rabaisser à reprendre le code d’un jeu d’une autre compagnie.

Je n’ai pas le temps de comparer tous le code mais j'ai quand même réussi à trouver un petit bout de code très similaire. Celui qui concerne justement le format de vitesse particulier de SMB3.

Et surtout le bout de code de cette routine qui sert à remplir le Power Meter de SMB3 dont je vous ai parlé plus haut et qui pour le coup est réellement un copier-coller ce qui est quand même assez troublant quand on sait que cette routine n'est pas très pertinente dans TTA qui n'affiche pas de jauge de charge.

Cela dit ça reste peu pour l'instant, juste des petits bouts noyés dans la masse. C'est peut être explicable autrement.
Selon moi, ce que Konami avait besoin pour TTA ce n’est pas tant le code de SMB3 que ses valeurs, ses paramètres, qui lui donne son feeling. Mon hypothèse c’est plutôt que Konami est passé par une grosse phase de reverse engineering sur SMB3. Konami a probablement fait tourner le jeu dans leurs outils debug qui ont permis d’analyser et récupérer les valeurs qui les intéressaient pour mimer SMB3 voir copier des petits bout de code utiles à cela.

Autant aujourd'hui c’est facile à faire avec un émulateur qui intègre des outils debug (la preuve, c’est ce que je fais ici), autant à l'époque c’est une autre histoire. Ça demande du hardware dédié qui permet d’ajouter ce type de fonction debug avancé. Ce n'est pas quelque chose qu'on va trouver chez le développeur NES standard. Mais TTA sortant tardivement en décembre 1991, plus de 3 ans après SMB3, on peut supposer que Konami avait peut être alors des devkit NES plus perfectionnés de type "in-circuit debugger" ou “in-circuit emulator” ou équivalent qui permet de visualiser ce qu’il se passe dans le CPU ou la RAM, placer des break point...

Un "in-circuit emulator" 6502 d'époque. Le CPU qui équipe la NES

La difficulté étant que le 6502 de la NES n’est pas “discrete”. Ce n'est pas un simple 6502 standard isolé comme dans un C64 ou un Apple II. Dans la NES il est intégré à un chip custom plus global (le 2A03) ce qui à mon avis complique les choses mais les gens de l’époque étaient sans doute suffisamment ingénieux pour contourner cette difficulté supplémentaire.

Il semble que Intelligent System avait été mandaté par Nintendo pour leur concevoir un devkit Famicom avec ce type de fonctions comme ils l’ont fait plus tard pour la SNES il me semble.

Un devkit Famicom avec des fonctions debug?

Est ce que ce devkit avait de tel fonction même partiel? Tout ça reste quand même très flou pour moi. J’essaie juste de donner des pistes. Mais même si ce genre de devkit devait être rare sur NES, il suffit que ça existe pour supposer sans trop de risque que Konami faisait partie des bénéficiaires étant donné combien Konami pèse sur NES. Que se soit de leur propre conception (car c’était un peu la règle à l’époque, démerde toi seul pour les devkit), ou par l'intermédiaire de Nintendo en utilisant leur influence.

Conclusion

Konami ne s’est pas inspiré de Super Mario Bros 3 mais a littéralement copié sans scrupule une partie des fondations du jeu dans son Tiny Toon Adventures ce qui implique soit un accès au code source, soit un reverse engineering poussé, au nez et à la barbe de Nintendo. Je mise plutôt sur la seconde hypothèse mais le copier-coller de la routine du Power Meter est quand même un peu troublant.

SMB3 est un énorme succès. Durant ces 3 années qui le sépare de TTA, la majorité des joueurs ont eu l’occasion d’y jouer et souvent des dizaines d’heures étant donné la taille et la qualité du jeu. Je suppose que Konami a voulu capitaliser là-dessus en proposant un jeu dans lequel le joueur aurait immédiatement des sensations familières et agréables, une prise en main intuitive, et pour cela quoi de mieux que copier au plus près le gameplay du jeu sur lequel tout le monde a passé des dizaines d’heures. C’est un coup de poker plutôt intelligent (mais peu conventionnel et discutable).
De plus TTA est peut être le premier vrai “pure platformer” de Konami (selon la définition très personnelle que j’en donne en première partie), il est alors très tentant de copier la référence du genre pour ne pas se tromper, mais à ce degrés la ca reste un exemple exceptionnel.

Quant à l’absence supposée de réaction de Nintendo qui pourtant s’en est sans doute rendu compte (au moins par l'intermédiaire des programmeurs de SMB3), on peut simplement deviner que Nintendo s’en contrefiche car au final c’est tout aussi dans leur intérêt que la qualité des jeux NES soit maximale.

Il se cache sans doute une histoire passionnante derrière tout ça mais il est fort probablement malheureusement qu'on ne connaisse jamais vraiment la vérité. Malgré tout, je trouve toujours incroyable de pouvoir continuer à faire ce genre de découverte 30 ans après, seul devant mon écran. Une autre démonstration s' il fallait des bienfaits des émulateurs et de leurs outils. Ça motive à continuer à faire ce genre de choses.

Pour terminer, sachez qu’il existe un ROM hack de Tiny Toon Adventures qui remplace les éléments graphiques du jeu par des équivalents venant de l’univers de Mario ce qui permet de boucler la boucle :)