31 Janvier 2025
Dans ce billet je vais partager mes récentes découvertes sur le jeu Ghouls’n Ghosts, un jeu que j'affectionne particulièrement et sur lequel j’ai toujours eu envie d’écrire un billet (avec Super Mario Bros 2 ^^).
Il s’agit notamment de confirmer à quel point les portages consoles ou X68000 sont fidèles à la version arcade, et pour cause, j’ai pu vraiment constater qu’elles s'appuient toutes directement sur les données et le code source du jeu d’arcade.
J’ai aussi fait la découverte d’un système de ranking dans Ghouls’n Ghost que j’ignorais et qui fait varier la difficulté selon les performances du joueur tel que cela se fait dans certains shmups. J’ai pu analyser tout ce système et saisir l’occasion pour faire une sorte de comparatif entre les différentes versions du jeu.
Plus globalement, on va beaucoup parler de la fidélité de ces portages avec la version arcade, même sur le plan graphique.
J’ai analysé et comparé 8 versions différentes du jeu pour ce billet. Les 4 versions arcade (la première version japonaise originale, la révision japonaise plus tardive, la version US et la version World), 2 versions Mega Drive (la première version japonaise originale et la version internationale), la version SuperGrafx et la version X68000. Si je me suis concentré sur ces versions, c’est justement parce qu’elles partagent littéralement le même ADN ce qui rend le comparatif plus simple contrairement par exemple aux portages Amiga, Atari ST, C64, CPC, SMS… qui sont de tout autre jeux.
Ça ne sera pas exhaustif ni la vérité absolue. Je vais juste partager ce que j’ai eu le temps d’analyser et de comparer jusque là. Il y aurait moyen de faire encore beaucoup mieux et plus en profondeur. N'hésitez pas à utiliser le plan du google doc sur la gauche pour naviguer entre les chapitres.
On savait déjà que la version X68000 était très fidèle à l'arcade. Au point d’alimenter le mythe que le X68000 serait lui-même une sorte de prototype du système d’arcade CPS de Capcom. Il n'en est rien. Le X68000 est un hardware très différent du hardware CPS et donc cette version du jeu est bien un portage qui a nécessité un travail d'adaptation (que je détaillerai un peu plus dans le chapitre X68000) mais au vu du résultat quasi parfait, il était tout à fait raisonnable de supposer que ce portage s’appuyait directement sur le code source et les données du jeu d’arcade d’autant que cette version a été développée en interne par Capcom il me semble.
Mais en ce qui concerne les versions Mega Drive et SuperGrafx, ça semblait beaucoup plus improbable. Ce sont des plateformes moins ambitieuses et des portages qui sont externalisés et pris en charge par des tiers (Sega, Nec Avenue / Alfa System). On sait qu'à l'époque, les portages de jeux d’arcade se faisaient principalement de manière empirique, en regardant la borne tourner (le luxe étant juste de disposer de la borne ou la PCB dans le studio de développement en charge du portage). Et les acteurs historiques de l’arcade ne semblaient jamais très impliqués dans tout ça.
En tout cas, c’est ce que je pensais jusqu'à récemment. Mais il se trouve que dans le cas du portage Mega Drive et SuperGrafx, j’avais déjà identifié auparavant de gros indices qui tendaient à prouver que ces versions étaient probablement basées aussi sur le code source et les données du jeu d’arcade original.
Notamment, j’avais constaté que les bugs et glitchs très spécifiques de la version arcade était reproductible à l'identique dans ces versions Mega Drive et SuperGrafx. Un florilège en gif :
Le bug du pont qui permet de faire un OoB (Out of Bounds) pour rejoindre directement le boss en ligne droite.
Le fameux bug mystérieux de l'échelle invisible qu’on trouve aussi au stage 5.
Le one shot du premier boss qui n’est pas exactement un bug mais qui trahit un traitement particulier des collisions.
Les glitchs de “téléportation”.
Tous ces bugs et glitchs, ici sur la version SuperGrafx, sont exactement les mêmes dans la version arcade ou Mega Drive. Il est très difficile d’expliquer cela sans en déduire que le code source du jeu d’arcade a directement été utilisé dans ces portages.
J’avais donc déjà de fortes présomptions quand, lors d’un débat sur la difficulté des différentes versions du jeu, j’ai appris qu’il y avait un menu d’option caché dans la version SuperGrafx (à peine caché, il suffit de maintenir le bouton 1 appuyé avant de lancer la partie) qui donne accès aux dip switchs de la version arcade qui permettent de modifier divers paramètres de difficulté. Il s’agit exactement des mêmes settings qu’on trouve aussi dans la version X68000 mais dans un menu d’options directement accessible à l'écran titre.
Non seulement l’accès à ces “dip switchs” cachés tendait à confirmer encore l’hypothèse que cette version SuperGrafx contient tout l’ADN de la version arcade mais ça m'offrait aussi tout un terrain de jeu. En effet, pour moi, la version SuperGrafx a une particularité par rapport à toutes les autres. Elle tourne sur une machine supportée par l’émulateur Mesen qui contient les meilleurs outils debug possibles et que je connais très bien. C’est alors beaucoup plus simple pour moi de fouiller dans le code de cette version.
C'était donc l’occasion de jouer avec les “dip switchs” de la version SuperGrafx pour observer comment ça altère le jeu et ensuite comparer empiriquement avec les autres versions du jeu.
Après avoir découvert et décrypté le système de ranking interne au jeu (que je détaille dans le chapitre suivant), ainsi que la façon dont les différents modes de difficulté influencent celui-ci, j'ai pu constater une nouvelle fois que toutes les versions fonctionnaient exactement de la même façon sur ces points.
Je suis alors passé à l'étape supérieure. Je voulais comparer directement les ”ROM” de chaque version, côte à côte, dans un éditeur hexadécimal pour faire des recherches. Pour les versions consoles c’est simple, on a des dumps qui prennent la forme d’un fichier unique. Pour le X68000 c’est un peu plus compliqué car tout est compressé sur les disquettes. J’ai donc fait des dumps de la RAM pour chaque stage que j’ai concaténé ensuite. Pour les versions arcade, c’est encore un peu plus compliqué car c’est souvent des dizaines de ROM qui sont dumpées et donc des dizaines de fichiers par jeu. Il fallait pouvoir concaténer tout ça de la bonne façon. C’est-à-dire assembler les ROM (cpu) dans le bon ordre et en tenant compte que parfois ce sont des ROM 16 bits et d’autre fois des ROM 8 bits (ou les 2 en même temps) mais toujours sur un bus 16 bits ce qui nécessite, pour les ROM 8 bits, d’entrelacer un par un les octets de deux ROM à la fois. Tout ça nécessite de savoir exactement où se place chaque ROM dans l’espace mémoire CPU. Heureusement, on trouve ces informations. Il a fallu alors écrire un petit script pour concaténer les ROM des différentes versions arcade en fonction de ces spécificités.
À la fin, j’avais donc un dump sous la forme d’un fichier unique pour chacune des 8 versions que je voulais comparer.
J’ai alors commencé à chercher, toujours dans la version SuperGrafx, les tables de données utilisées pour piloter le comportement des différents mobs du jeu (utilisées soit par le système de ranking, soit par la RNG). Je retrouvais systématiquement ces tables de données à l'identique dans toutes les autres versions (les seules exceptions concernent la version Arcade World. J’y reviendrai sur le dernier chapitre dédié aux spécificités de chaque version).
C’est quasiment une centaine de tables de données que j’ai pu comparer et retrouver à l'identique dans toutes ces versions (mais ce n’est qu’une partie de la totalité).
Je vous donne un exemple pour illustrer. Ici, la table de données qui sert à définir le délai de spawn du prochain squelette (donc leur fréquence d’apparition) en fonction du ranking et du nombre de squelettes déjà tués.
Cette table de 128 valeurs 16 bit est strictement identique dans les 8 versions du jeu que j’ai comparées. Je vous la mets ici en 3 versions:
La seule différence est que, sur la version SuperGrafx, ils ont converti la table au format 8 bits pour optimiser l’espace car le format 16 bits est ici inutile. On retrouve quelques fois ce type d’optimisation sur SuperGrafx (des tables 16 bits converties en 8 bits ou des tables 32 bits converties en 16 bits) mais la plupart du temps, elles gardent le même format.
Non seulement toutes ces tables sont identiques mais j'ai pu constater aussi la similarité de structure. Chaque ennemi est associé à un un bloc en ROM composé de multiples routines pour contrôler son comportement, entrelaçant des bouts de code et des tables de données. Juste en observant dans l’éditeur hexadécimal, on constate le même ordre et le même agencement des tables et bouts de code qui s'entremêlent sur toutes les versions parce qu’elles utilisent toutes le même code source comme base.
Dans le cas de la version Mega Drive qui utilise le même CPU qu’en arcade on peut même reconnaître les opcode en hexadécimal des instructions des différents bouts de code qui entourent ces tables de données (autant que possible car notamment tout le mapping mémoire est forcément différent d’une machine à l'autre ce qui change en partie la valeur hexa des instructions qui utilisent des adresses en opérande). Vous pouvez constater ça sur le bout de code qui précède la table dans le screenshot précédent.
Je suis maintenant évidemment totalement convaincu que Sega et Nec Avenue / Alfa System ont reçu de Capcom le code source et le dump des ROMs du jeu d’arcade original (la version japonaise). Bien sûr, il a fallu adapter. Le mapping mémoire des machines est différent. La partie affichage et la partie audio sont différentes. Dans le cas de la version Mega Drive, il y a eu aussi de grosses contraintes d’espace ROM qui a nécessité un gros travail d’adaptation. Du côté de la version SuperGrafx, il y a un peu moins de contraintes d’espace mais c’est le code qu’il a fallu entièrement traduire car le CPU est différent de l’arcade (et en architecture 8 bits). J'aborderai les quelques spécificités de chaque version dans le chapitre du comparatif.
Malgré tout, on retrouve entièrement l’ADN de la version arcade dans ces versions consoles. Le code source original transparaît dans chaque octet de ces versions, c’est frappant !
Pour ces raisons, cette version SuperGrafx est devenue la pierre de Rosette. En effet, c’est en quelque sorte le jeu d’arcade mais sous une forme que je peux facilement décrypter et dans le code de laquelle je peux fouiller grâce aux outils de debug disponibles, chose qui serait beaucoup plus compliquée sur la version arcade (et compliquée aussi sur Mega Drive qui n’a pas de très bons outils de debug). Il suffit juste ensuite de confirmer les découvertes pour les autres versions, ce qui est beaucoup plus simple. Sur Mega Drive je fais même un peu plus car j’ai identifié certaines variables en RAM (et encore une fois on peut constater des similarités avec la version SuperGrafx dans le format et la disposition de ces variables en RAM qui s’explique par le code source commun).
Cette version SuperGrafx me permet donc de comprendre le fonctionnement des autres versions telle une pierre de Rosette. Moi qui ai une affection particulière pour Ghouls’n Ghosts, c’est une très belle opportunité. Je n’aurais jamais pensé pouvoir découvrir certains secrets de la version arcade de cette façon détournée.
Un exemple: Il y a environ 1 an j’avais codé un script pour visualiser les hitbox de la version SuperGrafx. J’en avais fait un thread twitter ici .
Ce script m’avait notamment permis de constater que certains tests de collision avec les ennemis sont exécutés seulement à 15 Hz (une fois toutes les 4 frames). Par exemple, les tests de collision avec les squelettes sont à 60 Hz donc très précis et réactifs, mais en 15 hz pour les vautours, donc une précision plus approximative. On peut le constater ici sur ce gif:
À ce moment-là, je me suis simplement dit que c’était certainement une optimisation spécifique à la version SuperGrafx qui a moins de ressources (c'est le CPU d’une simple PC-Engine, pas plus). Mais à la lumière de ces nouvelles découvertes, si la version SuperGrafx contient tout l’ADN de la version arcade alors il devenait pertinent de vérifier… Et bingo ! Avec un peu de méthode, j’ai pu très vite vérifier que cette discrimination de qualité dans les tests de collision est présente aussi sur la version arcade. Les tests de collision avec les vautours se font aussi à 15 Hz en arcade. Et c’est la même chose dans la version Mega Drive.
Encore une fois, le constat du partage du même code source sur toutes les versions est frappant.
Maintenant qu’on sait que toutes les versions du jeu (Arcade, X68000, Mega Drive, SuperGrafx) partagent le même code source, je vais aborder une autre découverte que j’ai faite à cette occasion et qui m’a un peu surpris aussi. Ghouls’n Ghosts a un système de ranking tel qu’on pourrait le trouver dans certains shmups. C’est-à-dire que la difficulté du jeu varie constamment selon les « performances » du joueur. C’est un système de difficulté dynamique.
J’ai donc analysé ce système de ranking et les différents modes de difficulté qui accompagnent le jeu. Encore une fois tout ce système est commun à toutes les versions donc ce que je vais expliquer dans ce chapitre est valable pour toutes les versions. Certaines spécificités seront détaillées dans le dernier chapitre dédié à chaque version.
La difficulté dans Ghouls’n Ghosts à l’instant T dépend uniquement du rank, pas du mode de difficulté sélectionné.
En interne le jeu est découpé en 16 ranks de difficulté. Le ranking influence l’agressivité des ennemis (leur vitesse de déplacement, leur nombre max à l'écran, fréquence de spawn, cadence de tir, vitesse de bullet…) et il augmente en fonction du temps ou diminue quand on termine un stage ou quand on meurt. Sa façon d'évoluer dépend aussi du mode de difficulté sélectionné avant de lancer la partie.
Je viens de vous faire un bref résumé du système de ranking mais je vais maintenant vous détailler comment ça se passe concrètement en mettant tout ça en situation car il y a quelques subtilités.
Considérons que je sélectionne le mode de difficulté normal avant de lancer la partie (qui est la difficulté 4 sur 8). Le jeu débute alors en fixant le rank sur la valeur de « start » défini pour le mode normal qui, dans ce cas, est le rank 6 (sur 16). Puis le jeu me laisse tranquille pendant exactement une minute. Au bout d’une minute, l’auto-incrémentation du ranking s’enclenche et fait monter le rank d’un niveau et cela toutes les 15 secondes par la suite.
Lorsque je termine le premier stage, le rank baisse d’un niveau, une sorte de récompense, mais dès le début du stage suivant l’auto-incrémentation reprend immédiatement (sans le délai de 1 minute) et donc ça continue de monter très vite, toutes les 15 secondes. Si je ne meurs pas, j'atteins très vite le rank max, qui est le rank 16, dès le début du stage 2 (voir dès la fin du stage 1 si j'ai un peu traîné).
Ensuite, 15 secondes après avoir atteint le rank 16, le jeu n’incrémente pas vers le rank 17 (qui n’existe pas) mais par contre il verrouille le système d’auto-incrémentation définitivement. La difficulté ne peut faire que descendre à partir de ce moment-là (descendre d’un rank chaque fois qu’on termine un stage) tant que je ne meurs pas.
Si je meurs ça réinitialise le rank avec la valeur de « start » donc le rank 6 (ou rank 9 dans la seconde boucle, car le rank de « start » dépend aussi de la boucle) en t’offrant à nouveau 1 minute de délai avant de relancer l’auto-incrémentation du ranking. Et si je meurs une seconde fois dans le même segment du jeu (demi-stage) alors je redémarre avec la valeur de « start » précédente moins 1 donc au rank 5 etc… Au bout de 6 morts dans le même segment (et cela même si j’utilise des continus) le jeu me fait donc descendre au rank 1, le plus bas. Si jamais j’arrive a sortir de ce segment et que je meurs dans le segment suivant, mon rank est réinitialisé à nouveau sur le rank 6 de « start ».
En plus du système de ranking, le jeu propose différents réglages de difficulté (avant de lancer la partie) qu’on retrouve à l'identique dans toutes les versions. Sous la forme de dip switch pour l’arcade ou d’options dans des menus (caché ou pas) pour les versions X68000, SuperGrafx. Sur Mega Drive c’est beaucoup plus limité mais ces paramètres sont tout de même présents sur la ROM dans les données du jeu.
On peut notamment modifier le nombre de vies par crédit, de 3 à 6 vies. Par défaut, toutes les versions sont réglées sur le minimum soit 3 vies. On peut modifier aussi les paliers de scoring pour obtenir des 1UP plus ou moins facilement. Il y a 4 niveaux de difficulté pour ces paliers. Par défaut, toutes les versions, même SuperGrafx ou Mega Drive, sont réglées sur le niveau 3.
Et l’élément qui va nous intéresser le plus, la possibilité de régler le mode de difficulté sur une gamme de 1 à 8. Par défaut, toutes les versions, même SuperGrafx ou Mega Drive, sont réglées sur 4, le mode normal.
Tous ces réglages que je viens de citer correspondent aussi aux valeurs par défaut de l’arcade quand tous les dip switch sont en position OFF.
Sur X68000 et SuperGrafx on a donc accès aux 8 modes de difficulté des versions arcade (par un menu caché sur SuperGrafx). Par contre sur Mega Drive on n’a accès qu'à 2 modes. Le mode 1 qui est le mode « practice » et le mode 4 qui est le mode « professional ». Même si, en réalité, les 8 modes sont aussi présents dans le code de la version Mega Drive, j’y reviendrai.
Comme je l'évoquais brièvement plus haut, les modes de difficulté sélectionnables dans le jeu n’agissent pas directement sur la difficulté intrinsèque du jeu. Le mode de difficulté sert uniquement à paramétrer le système de ranking mais c’est le rank qui définit la difficulté. Que l’on joue en very easy (1) ou en very hard (8), si on atteint le rank 16 (ou le rank 1), ça donnera la même difficulté in-game. Ce qui change c’est juste la cadence à laquelle on va atteindre tel ou tel rank.
Le mode de difficulté choisi en début de partie sert uniquement à calibrer 4 paramètres du ranking:
Ce sont donc 4 valeurs (16 bit) par mode de difficulté soit une simple table de 32 valeurs pour les 8 modes de difficultés. Une table qu’on retrouve intégralement dans toutes les versions, même la version Mega Drive qui n’utilise pourtant que le mode 1 et 4. Encore une fois, on constate une grande fidélité au code source original malgré les ajustements spécifiques.
Cependant, cette table utilise des valeurs différentes dans la version Arcade World et dans la version Mega Drive (pour le mode 1, le mode « practice »). Je détaillerai tout ça dans le dernier chapitre dédié aux spécificités de chaque machine.
Voici un tableau qui dévoile les 4 valeurs de contrôle du ranking selon le mode de difficulté ainsi qu’un petit calcul pour constater combien de temps s’écoule avant d’atteindre le rank max quand on ne meurt pas :
On peut noter que quel que soit le mode difficulté ou la boucle, on atteint le rank max (16) en seulement 2 à 4 mn sans mourir soit environ 3 mn en moyenne. Ça va vite. Donc peu importe le mode de difficulté choisie au départ, si on connaît bien le jeu et qu’on meurt peu, la difficulté réelle sera sensiblement la même. C’est important de comprendre cela.
Maintenant qu’on connaît tous les secrets du système de ranking, est-ce qu’on peut en déduire des comportements plus optimaux à adopter?
Je dirais : pas vraiment. La seule véritable déduction que j’en ai tirée est qu’il peut être intéressant de tenter le « one life » car le « one credit » est finalement le contexte qui te pousse le plus haut dans le ranking. En 1CC, on meurt suffisamment rarement pour être quasiment tout le temps au rank max mais comme on meurt quand même de temps en temps, on ne peut pas profiter du verrouillage du système de ranking et du cumul de baisse de rank lors des fins de stage contrairement à un « one life ».
Dans le cas d’un « one life », on peut en déduire la stratégie optimale. Par exemple, en mode normal (le mode par défaut de toutes les versions), il faudrait idéalement attendre 3mn30 avant de tuer le premier boss afin de verrouiller le ranking dès le stage 1 et profiter de la décrémentation de rank de fin de stage dès le tout premier. En cumulant toutes les décrémentations de fin de stage que permet un « one life », on affronterait alors le boss final au rank 6, c’est-à-dire le rank de « start » de la première boucle. Cela signifie aussi que dans ce contexte, on traverse tous les stages de la seconde boucle avec un rank plus bas que dans la première boucle sauf le premier stage.
Donc on peut dire qu’il y a certains avantages dans le « one life » mais la RNG chaotique du jeu rend les « one life » un peu compliqués…
En bonus, je vous propose mes 2 scripts Lua qui permettent de visualiser le ranking dans le HUD du jeu en temps réel pour la version SuperGrafx et Mega Drive.
Quand le rank passe en orange, comme sur ce gif, ça indique que le système de ranking est verrouillé.
Ce sont des scripts à utiliser dans l’émulateur Mesen pour la version SuperGrafx et l’émulateur Bizhawk pour la version Mega Drive.
SuperGrafx
https://drive.google.com/file/d/1ioSzAhsmiE6UoAMvH1DYKV8pQWKY6-Ck/view?usp=drive_link
Megadrive
https://drive.google.com/file/d/1dQCOpiknPnGTrdOvU3bKp7wi5Rd1vntD/view?usp=drive_link
Il est fort probable que ces systèmes de ranking soient très fréquents en arcade. Ça me semble clairement quelque chose inventé par l’arcade pour l’arcade. Ça permet de réduire le temps de jeu des bons joueurs pour qu’ils ne monopolisent pas la borne avec une seule pièce mais sans frustrer ou décourager les nouveaux joueurs afin de leur donner envie de remettre une pièce. L’idée est vraisemblablement de lisser et équilibrer les temps de jeu (et donc le gain par heure) malgré l'écart gigantesque qu’il peut y avoir en termes de maîtrise et de connaissance du jeu entre les différents clients de la borne.
Et comme ça répond à une problématique précise de l’arcade dans un cadre où le crédit est payant, c’est quelque chose qui a dû émerger assez tôt et se généraliser. Ghouls’n Ghosts n’est probablement pas le premier. Mais en dehors de ce contexte, ça a moins de sens. Lorsqu’on veut proposer plus de challenge aux joueurs qui consomment du jeu vidéo à la maison, il est plus logique de le faire au travers de divers modes de difficulté optionnels plutôt qu’un système caché que le joueur subit sans pouvoir l’identifier ou le quantifier.
Dans ce chapitre je vais vous révéler de quelle façon concrète le ranking altère le comportement, et donc l’agressivité, des différents ennemis pour faire varier la difficulté du jeu, en plus de quelques autres informations et bugs pour aider à mieux appréhender le jeu.
Je n’ai pas analysé tous les ennemis ni tous leurs comportements mais une grande partie.
Les ennemis ont beaucoup de paramètres sur lesquels il est possible d’agir. Par exemple, le jeu doit décider à quelle cadence faire spawn l'ennemi? Dans quelle direction il se dirige? A quelle vitesse? Si il s'arrête, combien de temps? Doit-il tirer un projectile? A quelle vitesse? Est ce qu’il doit sauter? etc…
Le ranking va agir seulement sur quelques paramètres, souvent 2 ou 3 max, parfois aucun pour certains ennemis. Pour beaucoup d'autres de ces paramètres, c’est la RNG qui décide. C'est à dire le générateur de nombre aléatoire qui simule le hasard.
Mais dans les 2 cas la mécanique est plus ou moins la même. Pour chacun de ces paramètres qui pilotent le comportement de l’ennemi, il y a une table qui contient différentes valeurs potentielles et c’est le nombre déterminé par la RNG ou par le rank qui va servir à sélectionner l’une de ces valeurs dans la table.
Commençons par l’ennemi le plus emblématique, le squelette, sur lequel je vais prendre le temps d’entrer un peu dans les détails pour que vous compreniez comment ça fonctionne. Chose que je m'abstiendrai de faire pour les suivants.
C’est un ennemi qu’on trouve au stage 1-1 mais aussi au stage 4-1. Dans les 2 cas, le jeu utilise les mêmes tables de données (c’est donc les mêmes squelettes qu’on croise au stage 4-1).
Leur comportement est largement influencé par le ranking du joueur. Ça va conditionner leur vitesse de déplacement, leur fréquence de spawn, le nombre max de squelette à l'écran, et de façon beaucoup plus anecdotique, le temps de marche avant de retourner sous terre (mais quasiment pas exploité).
Si vous connaissez un peu le jeu vous devez savoir qu’il existe 2 types de Squelettes. Les “Slow” (le squelette de base) et les “Fast”, plus rares, qui se déplacent beaucoup plus vite. Le rank du joueur va influencer la vitesse de ces 2 types de squelette.
Le principe est chaque fois le même. Une table de donnée qui contient 16 valeurs car il y a 16 rank possibles. Le rank sert alors de pointeur pour aller piocher la bonne valeur (ici de vitesse) dans cette table. C’est aussi simple que ça.
La vitesse des squelettes utilise donc 2 tables (une pour les “Slow” squelette et une pour les “Fast”). Ce qui nous donne ce gradient de vitesse de déplacement:
Vitesse Slow Squelette >> de 204 à 435 sppf selon le rank
Vitesse Fast Squelette >> de 332 à 537 sppf selon le rank
Ce qui donne respectivement 281 sppf et 409 sppf pour le rank 6, “start” du mode normal.
Ce sont des vitesses en subpixel par frame (1 pixel = 256 subpixel).
Pour comparaison Arthur se déplace à 435 sppf. Ce qui veut dire qu’en mode normal au “start” c’est réglé pour qu’on soit plus rapide que n’importe quel squelette. Et c’est réglé aussi pour qu’aucun “Slow” squelette soit plus rapide qu’Arthur quelque soit le rank. On peut noter aussi que les “Slow” squelettes à haut rank sont plus rapides que les “Fast” squelette a bas rank ^^.
Le nombre maximum de squelettes à l’écran est aussi défini par le ranking. On trouve à nouveau une simple table de 16 valeurs qui ressemble précisément à ca: 2-2-2-2-2-3-3-3-3-3-3-4-4-4-4-4
Donc le nombre de squelettes varie entre 2 et 4 selon le ranking du joueur. Tout en sachant que ça ne concerne pas tous les segments du stage (par exemple la zone du grand arbre aux vautours c’est une autre table qui est utilisée et qui fait varier le nombre de squelette entre 0 et 2 selon le ranking).
Le ranking conditionne aussi la fréquence de spawn des squelettes et utilise pour cela des valeurs de délai en nombre de frames. C’est juste une valeur qui indique le nombre de frames à attendre avant de faire spawn un nouveau squelette. Ce nombre dépend donc du ranking mais aussi du “kill count”. C’est à dire qu’il y a 8 valeurs différentes de délai pour chaque rank et chaque fois qu’on tue un squelette on déplace un pointeur vers la valeur suivante (modulo 8, c’est à dire qu’après 8 ça repasse à 1, c’est une boucle).
C’est simplement pour avoir une certaine variabilité dans les délais de spawn entre les squelettes en donnant l’illusion que c’est aléatoire (alors que c’est lié au kill count) car si les squelette spawnaient tout le temps a la même cadence ca ne serait pas terrible.
Évidemment les valeurs de délai de la table sont plus faibles pour les haut rank que pour les bas rank donc ça spawn plus vite a haut rank. En moyenne c’est 62 frames de délai entre le spawn de deux squelettes (donc à peu près une seconde). Entre le rank 1 et le rank 16 il y a 20 frames d'écart dans ces valeurs de délai.
Tout ça se trouve donc dans une table de 128 valeurs (16 rank x 8 valeurs de délai par rank). Celle qui sert d’illustration dans le chapitre 1 de ce billet.
Je ne le répéterai plus pour les autres exemples mais toutes ces tables de données utilisées ici pour les squelettes on les retrouve à l'identique dans toutes les versions du jeu (sauf la version Arcade World qui a parfois des différences. Je détaillerais dans le chapitre dédié).
Pour les exemples suivants je vais éviter d’entrer autant dans les détails.
Sur le second segment du stage 1 on croise ces Skull-flower. Des fleurs mobiles qui crachent des têtes de mort. Le ranking influence leur fréquence de spawn ainsi que leur fréquence de tir mais aussi leur vitesse de déplacement qui couvre une gamme de vitesse entre 153 et 332 sppf selon le rank.
Puis on croise les racines tentaculaires.
Il n’en spawn jamais plus de 2 simultanément. Le ranking conditionne seulement leur fréquence de spawn ou respawn. A haut rank le jeu nous laisse peu de répit entre chaque destruction de racine.
Pour ce qui concerne les ogre-porcs, le ranking agit sur la vitesse de leur attaque de charge. Ce moment où ils vous foncent dessus pour vous empaler. La vitesse de cette charge varie entre 461 et 716 sppf selon le ranking. Je rappelle que Arthur se déplace à 435 sppf donc dans tous les cas la charge est plus rapide que le joueur, pas la peine de fuir, mais ça signifie qu'à haut rank il sera plus difficile de l'éliminer avant que sa charge vous percute.
On arrive au premier boss. Le Golem sans tête. C’est un cas intéressant car c’est aussi le premier “bug” ou erreur que j’ai trouvé en creusant le système de ranking. Une erreur qu’on va donc retrouver dans toutes les versions du jeu car elle fait partie du code source original à priori.
D’abord il est bon de préciser que le système de ranking n’a jamais d’influence sur le nombre de PV des boss qui reste toujours le même.
Dans le cas de ce premier boss, le ranking va simplement agir sur la cadence de tir des boules de feu (plus élevé à haut rank) et sur sa vitesse de déplacement.
La cadence de tir du boss est défini par un délai en nombre de frame qui est influencée à la fois par la RNG (nombre aléatoire) qui va piocher au “hasard” parmi 3 valeurs (32, 64 ou 96 frames avec une probabilité respective de 3/16, 8/16 et 5/16ème) et par le ranking qui va piocher dans une table de 16 valeurs un nombre de frame à soustraire ou ajouter a ce premier nombre sélectionné par la RNG.
Au final le délai entre 2 boules de feu peut varier de 17 à 104 frames (soit environ ¼ de seconde à 1 seconde ¾ ) selon la RNG et le ranking.
Le bug dont je veux parler concerne les déplacements du boss.
Ses déplacements sont principalement pilotés par la RNG qui décide au “hasard” la direction de son prochain déplacement, la durée de ce déplacement, si c’est un déplacement rapide ou lent (il y a seulement 2 vitesses possibles) et combien de temps il reste à l'arrêt après ce déplacement. A l’exception du premier déplacement qui est prédéfini (toujours un déplacement long et rapide vers la gauche).
Le ranking va simplement ajuster la vitesse sélectionnée par la RNG en la réduisant (bas rank) ou en l’augmentant (haut rank)... enfin ça c'était sans doute l’idée de départ mais ça a été mal exécuté.
Sans entrer trop dans les détails, le système de ranking applique cette modification de la vitesse après que la direction du boss soit déjà choisie, or ajouter une valeur négative ou positive à une vitesse dans ces conditions ne revient pas à réduire ou augmenter la vitesse mais plutot a poussé dans une direction plutôt qu’une autre (vitesse négative pour aller vers la gauche et positive pour aller vers la droite).
Le résultat c’est qu’au lieu d’influencer la vitesse absolu de déplacement du boss, le ranking a plutôt tendance à pousser le boss vers la gauche à bas rank (donc à augmenter le pressing sur le joueur acculer contre la falaise) et à pousser le boss plutôt vers la sortie quand on est à haut rank ce qui laisse beaucoup d’espace au joueur.
Cette erreur de traitement dans le code source a donc un effet inverse à celui qui était voulu. Ça rend les déplacements du boss plus dangereux à bas rank qu’a haut rank. Il est presque préférable d’arriver au boss avec le rank max (attention quand même à la cadence de tir qui est particulièrement élevée au rank 16).
En réalité, on peut difficilement atteindre un boss en étant à bas rank à cause du trajet nécessaire donc les effets de ce bug sont peu perceptibles et pénalisant pour le joueur.
Au final c’est une erreur qui rend juste le boss un peu plus facile qu’il ne devrait l'être mais on verra que c'est loin d'être la dernière erreur. Il y en a particulièrement beaucoup dans le stage 2 qu’on va évoquer pas plus tard que maintenant.
Début du stage 2, on se fait submerger par les Turtle-rock. C’est un segment assez compliqué (et très RNG). Ca s’explique peut être en partie par le fait que le ranking a peu d’influence et donc le joueur n’a pas vraiment de répit même à bas rank. Pire que ça, il y a une autre erreur dans le code source original, proche de celle pour le boss 1, qui rend la séquence plus difficile à bas rank qu'à haut rank donc il est préférable de passer ce segment du premier coup sans mourir.
A priori le ranking agit uniquement sur les bullets que crachent les tortues.
Le bug concerne la vitesse des bullets. Comme pour la vitesse de déplacement du boss 1, le jeu tente de modifier la vitesse des bullets des tortues selon le ranking du joueur. Et cette fois le jeu ne fait pas l’erreur de ne pas prendre en considération la direction… sauf qu’ils ont inversé le traitement ce qui a pour conséquence de réduire la vitesse des bullets à haut rank et l'augmenter à bas rank (l'inverse de ce qui est attendu).
Le ranking agit aussi sur la fréquence de tir des tortues mais pas toutes les tortues. Uniquement les bullets crachés par les tortues qui entrent dans la scène par rebond puis s'arrêtent pour sortir de leur rocher-carapace. Ce type de tortue est rare donc l’effet du ranking est assez négligeable ici.
Le délai entre 2 tirs de ces tortues varie entre 1, 2 ou 3 secondes de façon aléatoire (c'est la RNG qui pioche). Le ranking agit simplement en modifiant la probabilité d’avoir des 1,2 ou 3 secondes de délai en proposant des tables avec des proportions différentes de ces 3 valeurs. Ça veut dire plus de délai “1 seconde” et moins de délai “3 secondes” à haut rank.
En résumé, il est plus facile de passer ce segment des Turtle-rock à haut rank car les bullets de toutes les tortues sont alors plus lentes tandis que la fréquence de tir plus élevée ne concerne qu’un certain type de tortue plus rare.
Ca signifie qu’il est souhaitable de passer ce segment du premier coup lors de votre arrivé au stage 2 car mourir implique de recommencer chaque fois à un rank plus bas qui rend ce segment un peu plus difficile.
Le ranking influence la fréquence de spawn des libellules et leur vitesse de déplacement. Un pattern qui commence à être plutôt classique.
Mais encore une fois, il y a un bug qui concerne la modification des vitesses. La même erreur que pour le boss 1. Le code source ne prend pas en considération la direction. De ce fait, un ranking élevé va simplement augmenter la vitesse des libellules qui arrivent par la gauche et diminuer celles qui arrivent par la droite, et l’inverse a bas rank, donc l’effet du ranking est globalement plutôt nul. De plus, la table de donnée qui contient ces vitesses utilisés par le ranking à 2 valeurs erronées (rank 2 et 3).
Pas grand chose a dire sur le Red Arremer si ce n’est qu’il fait partie des rares ennemis sur lequel le ranking n’a aucun effet. Donc mourir en boucle ne le rendra malheureusement pas plus docile ^^.
On peut aussi indiquer que le tout premier Red Arremer (mid stage 2), le King Arremer, est un peu différent des autres. Il a 4 PV au lieu de 3.
Je pense que c’est un ennemi dont j’irais creuser le code plus tard pour voir si il y a des petits secrets utiles à en tirer.
Je ne l'avais jamais fait attention mais les chauve-souris de feu ont un pattern très identifiable. Elles ont des trajectoires en partie aléatoires mais par contre elles viennent toujours par vague de 4 et toujours avec les mêmes délais entre chacune d’entre elles ce qui donne des vagues qui se ressemblent beaucoup (rythme identique).
Il y a 100 frames de délai entre le spawn de la première chauve-souris de la vague et celui de la deuxième. 60 frames (1 seconde) entre la deuxième et la troisième. 80 frames entre la troisième et la quatrième et 180 frames (3 secondes) entre la dernière de la vague et la première de la vague suivante. C'est donc à ce moment-là qu’il faut agir, entre 2 vagues, laissant au joueur un délai de 3 secondes pour placer un saut ou une action risqué. Une fois qu’on a compris ça, ce segment du stage est sensiblement plus simple.
En réalité, si les délais entre le spawn des chauve-souris sont effectivement fixés et se répètent à l'identique d’une vague à l'autre, ils dépendent aussi du ranking. Les valeurs de délai que je vous ai données sont les valeurs neutre de mid-rank. Pour des rank plus bas le jeu ajoute des frames (+50 frames sur tous les délais pour le rank 1 par exemple) et pour les rank plus haut il en enlève (-30 frames pour les délais du rank 16), mais le principe reste le même. Toujours des vagues de 4 chauves-souris qui ont un rythme identique. Le ranking va juste accélérer la cadence de ces vagues. Mais même au rank max on a toujours 2 secondes et demi de délai entre la fin de la vague et le début de la suivante pour agir.
Un peu plus loin, les chauve-souris de feu prennent une autre forme en apparaissant dans des colonnes de feu verticales. Plus classiquement du haut vers le bas mais aussi parfois du bas vers le haut en surgissant de l’un des 3 trous de lave par dessus lesquels on doit sauter pour rejoindre le boss. Le ranking a une influence dans ce dernier cas. Il agit en augmentant la probabilité d’avoir ces colonnes de flamme qui surgissent des trous.
C’est censé augmenter la difficulté mais je ne suis pas très convaincu car le nombre de chauve-souris simultané est limité à 4 donc en augmentant la probabilité des chauve-souris qui surgissent des trous de lave, on réduit la probabilités des autres et je ne suis pas convaincu que ces chauve-souris là soit vraiment plus dangereuses.
Il y a certains ennemis qui spawn a l’infini et qu’on croise même dans plusieurs stages. A l’inverse, la plante carnivore est un ennemi qui n’existe qu’en 3 exemplaires dans tout le jeu (au stage 2-2). Encore plus rare que les Red Arremer.
C’est un ennemi qui tire des bullets de manière omnidirectionnel. Le délai entre les tirs varient aléatoirement entre 2 valeurs, 120 frames (2 secondes) ou 150 frames (2 secondes et demi). Donc une cadence relativement stable et prévisible sauf qu’elle a aussi une possibilité aléatoire de faire une sorte de double shot en ajoutant un second tir rapide qui suit le précédent de seulement 30 frames (une demi seconde). Ces double shot sont dangereux.
Le ranking agit sur la cadence de tir des plantes et donc sur ces valeurs de délai mais c’est là qu’intervient un nouveau bug. L’idée était de faire varier la cadence de tir en ajoutant ou soustrayant des frames à la valeur de délai selon le ranking. De + 24 frames pour le rank 1 à - 60 frames pour le rank 16. Mais cette table de délai est au format 16 bit alors que jusqu'à maintenant toutes les tables de délai était au format 8 bit, même dans le code source original de la version arcade.
Le code du jeu ne prend pas en considération cette particularité et traite cette table de donnée comme les autres table de délai, c’est à dire comme une table de valeurs 8 bit, ce qui donne des valeurs complètement erronées (principalement nulle). Et bien entendu toutes les autres versions on reprit ce code source erronée avec la même table 16 bit. En conséquence, ce passage est plus facile qu’il aurait dû être. On aurait dû avoir une cadence de tir bien supérieure (quasiment 2 fois plus élevée au rank 16).
Le ranking a pour effet aussi d’augmenter la vitesse des bullets tirée par ces plantes carnivores. Cette fois, pas de bug malgré que ces plantes ont 32 angles de tir différents. La vitesse des bullets varie de 563 sppf au rank 1 à 790 sppf au rank 16.
L’une des attaques du boss du stage 2 consiste à faire un bond horizontal au raz du sol par-dessus le joueur en l'obligeant à se baisser. Le ranking conditionne la longueur de ce saut. Plus le rank est élevé, plus le saut sera court et donc dangereux.
Mais encore une fois il semble y avoir une erreur dans le code. La longueur du saut (qui est en réalité sa durée en nombre de frames) prend la forme d’une table de 16 valeurs, une valeur pour chaque rank, tout ce qu’il y a de plus classique. Mais lors de la conversion du rank en pointeur de table, il y a un décalage de bit de trop. Il en résulte que seule la première moitié de la table est utilisée. Les valeurs de saut les plus dangereuses pour le joueur ne sont donc pas utilisées. Au rank 16 le saut est alors 26% plus long que ce qu’il aurait dû être si les valeurs de cette table avaient été entièrement exploitées.
Mais il est possible aussi que ce soit un ajustement de dernière minute pour simplifier ce passage. Il est plus difficile ici de trancher sur le fait que ce soit une erreur de programmation contrairement aux nombreux cas précédents où c'était plus évident. Mais encore une fois, c'est présent dans toutes les versions.
Le ranking influence aussi la vitesse de déplacement du boss quand il est au sol. De 464 sppf pour le rank le plus bas à 736 sppf pour le rank le plus haut.
Il a aussi un effet sur la phase d’attaque boule de feu mais qui n'est pas claire du tout donc je n’en parlerais pas.
Début du stage 3 on fait face à une vague de gobelins volants façon Galaxian.
Cette fois c’est le nombre maximum de gobelins volants qui dépend du ranking comme pour les squelettes mais dans des proportions sensiblement supérieures. Le nombre de gobelins varient entre 4 et 10 selon le rank (la table de donnée ressemble précisément à ceci: 4, 4, 5, 5, 5, 6, 6, 6, 6, 7, 7, 7, 7, 8, 8, 10).
10 gobelins c’est beaucoup, en plus des rochers qu’ils lâchent (et des chevaliers gluants), mais il faut noter encore une fois que ca sera respecté dans toutes les versions, sans aucun compromis, même sur SuperGrafx et Megadrive (à l’inverse, par exemple, des portages de Final Fight dont le nombre d'ennemis est passé de 10 en arcade à seulement 4 sur Mega-CD ou X68000 pour des raisons techniques).
10 gobelins c’est intense mais comme on peut le constater en observant cette table de donnée, ça ne concerne vraiment que le rank max. Dès le rank précédent (rank 15) ça tombe à 8 gobelins. Et si vous avez bien compris les subtilités de la mécanique de ranking, il est difficile d'être rank max en première partie de stage car quand on termine un stage (et qu’on débute donc le suivant) on baisse d’un rank. Et si on a verrouillé le rank max à la fin du stage précédent alors il ne peut plus remonter.
Donc pour assister à ce phénomène rare des 10 gobelins volants, il faut terminer le stage précédent a un rank plutôt élevé, voir max, mais juste avant qu’il soit verrouillé. Ça demande un certain timing.
L’autre paramètre influencé par le ranking concerne la fréquence de spawn des gobelins. Comme dans les cas précédent similaire, il s'agit à nouveau d’une table de 16 valeurs (une par rank) qui correspond au nombre de frames de délai avant le prochain spawn. Ça varie entre 55 frames de délai et seulement 20 frames pour le rank max (donc un tiers de seconde entre le spawn ou respawn de chaque gobelin).
En ce qui concerne le boss du stage 3, le ranking agit sur la durée des phases de déplacement circulaire. C’est à dire ces phases ou il est relativement inoffensif et se contente simplement de tourner autour du joueur. Plus le ranking est haut plus ces phases là sont courtes.
Le ranking influence aussi les phases d’attaque “électrique” du boss mais comme pour l’attaque boule de feu du boss du stage 2, la mécanique (similaire) n'est pas claire pour moi donc je m'abstiendrais.
Les gros vers du stage 4 sont aussi conditionnés par le ranking de 2 façon:
D’abord leur cadence de tir, à la manière des plantes carnivores du stage 2 par exemple, mais aussi le nombre maximum de gros vers simultanés, qui varie de 2 à 4 selon le rank (comme les squelettes).
A savoir aussi que lorsqu’on esquive un vers sans le tuer, il reste toujours considéré comme actif même assez loin hors champ derrière nous. On peut donc vite bloquer le spawn des prochains vers en forçant la saturation si on évite de tuer les premiers. Surtout a bas rank ou la saturation est atteint à partir de 2 vers.
La vitesse des bullets tirée par les mains géantes dépend du ranking. Comme il s'agit d'un tir omnidirectionnel, cela demande une grosse table pour stocker toutes les valeurs de vitesse (x et y) pour chaque angle de tir et chaque rank comme c’est le cas pour les plantes carnivores du stage 2 par exemple. A la différence près que les mains géantes n’ont que 16 angles de tir contre 32 pour les plantes carnivores.
Le ranking va aussi agir sur les délais et donc la cadence des tirs. Les haut rank vont réduire les délais de tirs. Le mécanisme de délai des tirs est assez complexe. Il fonctionne par duo de bullet et dépend à la fois de la RNG, du ranking et de quelle main il s’agit.
Le ranking agit uniquement sur la cadence de spawn ou respawn des squelettes-dragon comme pour les racines tentaculaires du stage 1-2. A la différence que le nombre de squelettes-dragon à l'écran est limité à 3 contre 2 pour les racines.
Lucifer, le boss final, élément emblématique de Ghouls’n Ghosts, est aussi influencé par le ranking.
La ranking va agir sur la vitesse de déplacement de ses tirs laser qui est plus élevé à haut rank (seulement +25% entre les bas rank et les haut rank). Mais il agit aussi sur le comportement de sa main gauche.
En effet, il faut savoir que, dans un premier temps, Lucifer se bat uniquement avec sa main droite. Il existe un délai entre le début du combat et le moment où Lucifer commence à utiliser sa main gauche simultanément à sa main droite. C’est ce délai qui varie selon le rank du joueur mais on gagne seulement 3 secondes de répit en plus au rank 1 par rapport au rank 16 (le délai varie de 8.73 secondes à 11.73 secondes). Mais ça peut largement faire la différence car c’est un boss très rapide à tuer.
Les informations partagées dans les chapitres précédents sur le système de ranking ont l’avantage d'être valables pour toutes les versions mais il est temps maintenant d'évoquer les spécificités de chacune car il y a évidemment des divergences. Même les versions arcades ont des différences notables entre elles.
Les cas les plus difficiles à traiter étant les versions consoles qui ont des contraintes supplémentaires. Encore plus la version Megadrive qui est celle qui s'éloigne le plus de l’arcade. On va alors en profiter pour parler de la fidélité de ces portages de façon globale.
Mais encore une fois ça ne sera pas exhaustif. La tâche est trop grande. Il reste certainement beaucoup de choses à creuser. Probablement que je mettrai à jour le billet dans le futur.
C’est d’abord la version originale de fin 1988, la première version disponible, celle qui sert de référence. Donc, par définition, je n’ai pas de spécificité à signaler puisque c’est elle qui définit la norme du comparatif. C’est aussi la plus difficile des versions arcade.
Il s’agit seulement du deuxième jeu du système d’arcade CPS de Capcom juste après Forgotten Worlds. Un jeu de 32 Mbit dont 24 Mbit de tuile graphique. Paradoxalement c’est un jeu un peu moins gros que Forgotten Worlds ou que Strider qui va suivre rapidement (et qui font tous les deux 42,5 Mbit) mais plus que Final Fight (26,5 Mbit).
Il existe une seconde version japonaise plus tardive. Une révision souvent nommée “Resale” et qui semble dater de 1991 (mais ce genre de date reste hypothétique).
De tout ce que j’ai pu analyser parmi les multiples paramètres de difficulté et de ranking, je n’ai pas identifié de différence avec la version originale. Même les divers bugs restent présents. On ne retrouve pas non plus les spécificités des versions US et World qui aurait pu influencer cette version pour la rendre plus facile.
Donc la difficulté de cette version me semble similaire à la version originale. Pourtant il y a probablement des différences puisque les ROM le sont à de multiples endroits. Ça m'intéresserait de connaître quelles sont ces différences mais on verra ça une autre fois.
Cette révision semble au moins avoir une justification économique. Elle profite de l'évolution de capacité des chips ROM du marché qui permet de proposer un rafraîchissement de la PCB vers quelque chose de plus compact et moins coûteux. En tout cas c'est mon hypothèse (je n’ai pas vu la PCB) car on passe de 40 chips ROM de 64 Ko ou 128 Ko, pour le CPU et la partie graphique de la version originale, à seulement 10 chips ROM de 512 Ko (dont certains sont seulement à moitié rempli) dans cette révision.
C’est une version qui à été simplifié de façon un peu grossière pour qu’elle soit plus facile que la version japonaise. C’est la version la plus facile de toutes à l'exception du mode “practice” Megadrive qui s'inspire en partie de cette version.
Ils ont modifié certaines mécaniques de base. Notamment ils ont ajouté plein de checkpoint partout dans les stages ainsi que devant le boss ce qui est très maladroit car ça peut bloquer le joueur si il n’a pas la bonne arme (typiquement si on a la sword face au boss du stage 4, on ne peut pas le toucher, on est obligé de reset la partie).
Ils ont aussi modifié le contenu des coffres. Le contenu des coffres est un système cyclique (un cycle de 4) tout à fait prévisible. Dans cette version US, ils ont remplacé l’un des sorciers par une armure quand on est en caleçon. C’est à dire qu’on a 2 fois plus d’armure et 2 fois moins de sorcier dans les coffres que la version originale. Ça change beaucoup la difficulté et augmente énormément les possibilités de comeback. Dans la version originale il est très difficile de retrouver une armure une fois en caleçon car dans cette situation l’armure se trouve dans le tout dernier coffre du cycle ce qui nécessite à la fois de tenir jusque là mais aussi de faire apparaître tous les coffres (et donc connaître leur emplacement) pour faire avancer le cycle des coffres. Les chances sont faibles. Dans cette version US on trouve une armure dès le deuxième coffre du cycle ce qui fait une grosse différence.
Et pour terminer, ils ont aussi modifié les PV des boss et pas qu’un peu. Par exemple, sur le premier boss on passe de 22 PV dans la version originale à seulement 8 PV, même pas la moitié.
Si on ajoute à ça le checkpoint devant le boss, cette version rend les boss fight vraiment très simple comparé à la version originale.
Par contre, le paramétrage et comportement des ennemis durant les stages est similaire à la version originale. En tout cas je n'ai constaté aucune différence dans la centaine de tables que j’ai comparé. Notamment toutes les tables utilisées par le ranking ou pour la gestion des modes de difficultés sont similaires à l'originale.
C’est probablement la version arcade à laquelle vous jouez. C’est un peu devenu la version de référence par défaut, notamment pour la gestion du set de ROM dans Mame. Pourtant c’est aussi une version simplifiée et donc différente de l’originale.
Mais la méthode qu’ils ont appliqué pour réduire la difficulté du jeu est diamétralement opposée à celle de la version US. Cette fois, au lieu de modifier les checkpoint, les coffres ou les PV des boss, ils ont agi directement sur le comportement des ennemis, notamment au travers du système de ranking. Ça demande plus de boulot mais ça permet de réduire la difficulté d’une manière plus subtile qui dénature moins le jeu original. Si on cherche une version “facile” du jeu, je conseille plutôt celle ci qui permet de mieux se préparer pour la version originale je pense.
Pour commencer, ils ont modifié la table de setting des modes de difficulté que j’ai détaillé dans le chapitre 2. C’est à dire la table qui sert à ajuster les rank de “start” et la cadence de progression du ranking durant le jeu en fonction du mode de difficulté qui a été sélectionné.
Ils ont simplement réduit tous les rank de “start” d’un point et ajouté 5 secondes à toutes les valeurs de cadences de progression du ranking. Ca donne cette nouvelle table:
A comparer avec la table originale du chapitre 2 que l’on trouve dans les autres versions:
Mais en plus de cela ils ont donc modifié une partie des tables qui contrôle les ennemis. J’ai pu le constater au moins sur celle que j’ai analysée et exposée dans le chapitre précédent.
Ca concerne notamment la vitesse des squelettes qui a été nerfé sur cette version World:
Vitesse Slow Squelette >> de 128 à 358 sppf selon le rank
Vitesse Fast Squelette >> de 256 à 460 sppf selon le rank
A comparer avec les autres versions:
Vitesse Slow Squelette >> de 204 à 435 sppf selon le rank
Vitesse Fast Squelette >> de 332 à 537 sppf selon le rank
Les squelettes de base des autres versions vont 57% plus vite que dans cette version arcade World quand on débute une partie en mode normal.
Ils ont aussi réduit la fréquence de spawn des racines tentaculaires ainsi que celle des skull-flowers qui les accompagne dans le second segment du stage 1 en plus de la fréquence de tir de ces mêmes skull-flowers.
Le début du stage 2 a été largement nerfé. On constate une nette diminution du nombre de turtle-rock. Il y en a 2 fois moins simultanément ce qui rend bien plus facile ce passage qui est très délicat sur les autres versions.
Dans le second segment, la cadence de spawn des chauve-souris de feu a aussi été réduite ainsi que la vitesse de déplacement du chien de l’enfer, le boss du stage 2.
Au stage 3 c’est la fréquence de spawn des gobelins volants qui a été réduite et au stage 4 c’est la cadence de tir des gros vers.
C’est donc au minimum tous les ennemis présents sur cette image qui ont été nerfés dans cette version arcade World (en plus du setting du système de ranking), et probablement d’autres comportements ou d'autres ennemis. L’effort de réduction de la difficulté semble se concentrer plus particulièrement sur la première moitié du jeu, peut être pour mieux équilibrer et rendre la difficulté plus progressive.
Quoi qu'il en soit, cela en fait une version sensiblement plus facile que la version originale, c’est certain, même si je pense que la version US reste la plus facile des versions arcades.
De plus, ces versions US ou World restent des versions faciles quel que soit le mode de difficulté choisie car, comme je l’ai expliqué dans le chapitre précédent, en agissant simplement sur la cadence de progression du ranking, le mode de difficulté influence peu la difficulté. Surtout pour un joueur qui connaît déjà bien le jeu et qui meurt peu souvent, le mode de difficulté n’a alors quasiment plus d’effet.
La version X68000 est une copie quasi conforme de la version arcade japonaise. En termes de fidélité on est très haut donc il n’y aura pas grand chose à constater comme différence.
En effet, en plus de reprendre le code source, cette version reprend aussi l’intégralité des données graphiques de la version arcade grâce à l’utilisation de 2 disquettes (pour un total de 20 Mbit) couplé à l’utilisation de 2 Mo de RAM (autant qu’une PS1) ce qui permet de compresser intégralement le contenu des disquettes afin d’augmenter virtuellement leur capacité et ainsi ne faire aucun compromis sur les données originales. Mais ça demande évidemment de décompresser en RAM tout le contenu à chaque stage ce qui implique des loading régulier.
Cette version X68000 évite donc la principale contrainte des versions consoles qui est la taille très limitée de leur ROM obligeant à tronquer des éléments. Elle profite aussi de performances graphiques élevées du X68000 qui permettent de mimer la version arcade.
Pour autant ce portage n’est pas une sinécure. Adapter le moteur graphique du jeu d’arcade au X68000 est une tâche complexe car le X68000 a de très bonne capacité graphique mais l'architecture est très différente du CPS. C’est un peu comme comparer un Amiga et une Megadrive. Surtout en ce qui concerne l’affichage du décors, qui, dans cette version X68000, passe par des layers bitmap 8 bpp plutôt que pas la combinaison tilemap + tileset 4 bpp comme sur CPS ou sur Megadrive et SuperGrafx. C’est une autre philosophie que les standard arcade ou console. Sur ce point l’affichage console est plus proche du CPS que ne l’est l’affichage X68000 qui a une approche un peu plus “micro-ordinateur”.
Dans ces conditions, ça implique une mise à jour du scrolling bien plus lourde en ressource CPU sur cette version X68000 que sur CPS ou console, et cela même s'il y a bien un support hardware du scrolling.
Ça nécessite de mettre à jour directement les pixels de ces bitmaps (et des pixels plus lourds en 8 bit, pas 4 bit) plutôt que juste mettre à jour une tilemap comme sur CPS ou console. Et, de surcroît, sans aucun DMA pour accélérer les transferts vers la mémoire graphique. Il faut tout faire au CPU. Résultat, le scrolling consomme presque la moitié des ressources CPU dans cette version X68000 là où sur CPS il doit occuper 1 ou 2% du CPU et pas beaucoup plus sur console.
La conséquence est un risque de drop (baisse de framerate) sur certaines scènes ou l’environnement dynamique nécessitent plus de manipulation qu’un simple scrolling.
La scène la plus symptomatique de cela est probablement celle de la tempête dans le second segment du premier stage car en plus du scrolling, la scène nécessite de mettre à jour les 2 plans pour animer les arbres, l’herbe et l’eau. Tout l’environnement est animé.
Ça ne pose pas vraiment de problème au CPS qui a juste besoin de mettre à jour les tilemap (ou faire du swapping de tilemap) mais sur X68000 c’est beaucoup trop de pixels à mettre à jour avec le CPU. La tâche est impossible.
Ils ont tout de même relevé le défi en mettant en place diverses astuces et bidouille. Par exemple, les 2 frames d’animation du second plan sont superposées dans les mêmes pixels en profitant de leur profondeur 8 bit. Le swapping entre les 2 frames d’animations se fait simplement en modifiant la palette (75 slots de la palette sur les 256 sont réservés à cet effet) ce qui est infiniment plus rapide car aucun pixel n’est déplacé.
Pour l’animation des arbres du premier plan ils ont simplement étaler la charge sur plusieurs frames, donc l’animation se fait seulement partiellement d’une frame à l'autre. Il en résulte une forme de tearing vertical dans les arbres mais qui n’est pas trop visible à vitesse normale, c’est un compromis.
Et pour l’animation de l’herbe et de l’eau, exceptionnellement ils ont choisi de faire appel à l'un des layers tilemap du chip “Cynthia”, la composante “console” de la partie graphique du X68000. La plupart du temps, dans les jeux X68000, Cynthia n’est utilisé que pour les sprites car la quantité de VRAM de Cynthia est beaucoup trop faible (32 Ko) mais sur cette scène il y a peu de sprite (juste un ennemi) ce qui offre la possibilité d’utiliser l’un des layers tilemap de Cynthia en secours pour animer l’herbe et l’eau. C’est donc un autre plan supplémentaire.
Mais malgré tous ces efforts, et des routines de transfert de tuiles bien optimisées, ça n'empêchera pas malheureusement d’avoir une petite chute de framerate sur cette séquence qui tourne plutôt autour de 45-50 fps (avec un frame pacing un peu chaotique). Cela signifie que le framerate de cette séquence est, paradoxalement, plus stable sur les modestes Megadrive ou SuperGrafx.
Pour cette raison, la notice conseille l’usage d’un X68000 un peu booster avec un CPU à au moins 16 Mhz au lieu des 10 Mhz de base, si on veut éviter ces quelques drops (c’est là aussi qu’est indiqué la nécessité d’avoir au minimum 2 Mo de RAM dans son X68000 pour ce jeu).
Je dirais qu’il y a peut être 3 ou 4 séquences avec ce léger problème de framerate, comme le début du segment 2-2, ou le segment 4-2 qui est peut être celui qui pose le plus de problème, sans doute à cause du scrolling vertical rapide (surtout vers la fin avec les possibilités de descente en chute libre).
Ce framerate un peu moins stable que sur CPS quand on utilise un X68000 de base est la principale différence qu’on peut noter avec aussi les loading à chaque début de stage évidemment.
A cela s'ajoutent quelques difficultés à reproduire graphiquement certaines scènes complexes comme on l’a vu pour la tempête et son tearing dans les arbres.
En second exemple, on peut citer la séquence d'ascenseur dans le premier segment du stage 3. Une séquence un peu complexe en termes de nombre de plans et de priorités. Le CPS s’en sort très bien avec ses 3 plans de background combiné à l'utilisation de sprite pour représenter la plateforme de l'ascenseur et ses fonctions avancées de “priority mask” au pixel qui permet de simuler 2 plans avec un seul.
Le X68000 ne peut pas reproduire cette scène à l'identique. Notamment il n’y a pas assez de sprite pour se permettre d’en sacrifier une cinquantaine à la représentation de la plateforme. Ils vont alors à nouveau faire appel au layer tilemap de Cynthia comme pour l’herbe de la scène de la tempête. Ce layer tilemap de Cynthia est une bonne solution pour compenser le manque de sprite du X68000 (un layer tilemap c’est un peu comme un gros sprite).
Par contre, il n'y a pas les mêmes possibilités de gestion des priorités de plans dans ce contexte, ce qui empêche de cacher la plateforme entre les 2 pans de murs. On se retrouve donc avec une plateforme qui traverse toute la largeur de l'écran sur X68000.
Il y a certainement d’autres petites différences de ce type mais ça reste toujours très discret. Globalement c’est quasi pixel perfect grâce à l’usage de l’intégralité des données graphiques originels. C'est peut être le portage CPS > X68000 le plus fidèle.
Il est tout de même étonnant de constater les efforts d’optimisation qui ont été fait par les devs Capcom sur cette version X68000. Souvent des efforts spécifiques à une seule scène. Tout ça pour une version qui n’avait sans doute aucun potentiel commercial.
C’est une version étonnante. Très fidèle à l'arcade malgré les nombreuses contraintes.
La première contrainte est qu’il s’agit cette fois d’un portage externalisé et sous-traitée. Comme pour la version Megadrive, ce n’est pas Capcom qui est chargé de ce portage mais, à priori, Nec Avenue qui sous-traite eux même à Alfa System.
Des éléments qui, en général, ont plutôt tendance à nuire à la fidélité. Mais dans le cas présent, malgré tous ces intermédiaires, on constate que l'équipe a vraisemblablement disposé de tout le code source et des ROM originales ce qui change beaucoup de chose. Capcom semble avoir eu un comportement exemplaire sur ce point, pour l’époque.
A cela on peut ajouter la contrainte du délai. Il semble a priori que ces versions consoles, SuperGrafx ou Megadrive, ont été développées en très peu de temps, quelques mois à peine.
L’autre contrainte concerne le CPU. Contrairement à toutes les autres versions exposées ici (Arcade, X68000 et Megadrive) qui utilisent toutes le même CPU 16 bit Motorola 68000, la SuperGrafx utilise un autre CPU dérivé de la famille MOS 6502.
En plus d'être un CPU 8 bit, c’est un type de CPU très éloigné du 68000 dans son fonctionnement et son jeu d’instruction. On peut donc supposer que la plus grosse part du travail sur le portage de cette version va se situer ici. Il faut convertir tout le code source original pour l'adapter au CPU de la SuperGrafx.
La SuperGrafx a une autre spécificité. C’est une console à double chip graphique en parallèle (deux fois le chip graphique de la PC-Engine) qui ajoute une autre couche de complexité dans le portage. Il faut constamment réfléchir à la répartition de la charge graphique et des données graphiques entre les deux VDC et les deux VRAM. Ça nécessite une certaine gymnastique de haute voltige propre à cette console. C’est moins flexible qu’une configuration à un seul VDC et une seule VRAM.
Et puis vient la contrainte de la taille de la ROM. C’est la contrainte la plus forte pour ces versions consoles.
Cette version SuperGrafx dispose d’une ROM de 8 Mbit, c’est plus que les 5 Mbit de la version Megadrive mais ça reste loin des 32 Mbit de la version arcade. Ça va donc nécessiter aussi un gros travail d’adaptation pour choisir quels éléments tronqués pour faire entrer le jeu sur la cartouche.
J’ai l’impression que l’effort pour optimiser l’espace de la ROM a été relativement important, peut-être un peu plus encore que sur la version Megadrive paradoxalement.
Mais ce n’est pas sans conséquence. Notamment ils ont volontairement dégradé les palettes pour optimiser la compression des tuiles graphiques. Avec ces nombreuses palettes programmables (32 palettes contre 4 sur Megadrive), la SuperGrafx (et la PC-Engine qui est similaire sur ce point) avait le potentiel pour reproduire assez fidèlement les couleurs de la version arcade malgré le nuancier RGB limité (9 bit contre 16 bit en arcade) mais finalement ce n’est pas le cas.
Pour aider à la compression, ils ont réduit la profondeur des pixels. La SuperGrafx manipule des pixels 4 bit comme les autres consoles de l’époque depuis la Master System jusqu'à la NeoGeo. 4 bit ca veut dire localement 15 couleurs potentiel pour une tuile ou un sprite d'où l'usage de palettes programmables de 15 couleurs.
Mais pour ce jeu ils ont volontairement bridé la profondeur des pixels à 3 bit (7 couleurs) voire parfois 2 bit (3 couleurs) selon les tuiles/sprites. Il s’agit juste de contrainte local, le nombre total de couleur affiché reste tout de même un peu supérieur a la version Megadrive (entre 40 et 50 sur SGX contre 30 à 35 sur MD) mais c’est quand même un sérieux downgrade comparé a ce qu’il aurait été possible de proposer sur la consoles sans ces contraintes de compression.
De plus, les couleurs choisies semblent parfois un peu douteuses. Je ne sais pas si c’est à cause de l’usage d’un outil d’automatisation de la conversion des données graphique ou pas, mais il aurait certainement été possible de proposer meilleur choix même avec ces contraintes. On a l'impression d’un manque de soin ou de temps sur ce point là. Notamment le sprite d’Arthur (dans son armure Silver, une fois en Gold ou en slip c’est mieux) est assez discutable dans le choix des couleurs utilisées en plus de n'utiliser que 6 couleurs sur les 7. C’est difficile à justifier et vraiment dommage quand il s’agit du sprite principal mais en tout cas ça laisse une sacré marge de progression pour un color hack et montrer ce qu’il aurait été possible de faire.
Le point positif est que ces efforts de compression ont permis en contrepartie de reprendre directement les sprites de la version arcade et avec toutes les frames d’animations dans la majorité des cas. Les couleurs sont sensiblement altérées mais le pixel art est directement celui de l’arcade contrairement à la version Megadrive dont une grande partie des sprites ont été entièrement refait. De ce fait, ils sont souvent un peu différents, notamment en taille.
Le plus flagrant c’est l’ogre-porcs qui a des couleurs douteuses sur SuperGrafx lié à cette compression mais reprend exactement le sprite arcade quand sur Megadrive il a été entièrement refait et nettement réduit pour l’occasion (en plus d’avoir aussi des couleurs douteuses mais pour d’autre raison lié aux contraintes hardware du faible nombre de palettes programmables sur la Megadrive).
En ce qui concerne le décors, ils n’ont pas pu reprendre directement les données graphiques de la version arcade, trop lourdes, donc il a fallu faire un travail d’adaptation comme pour la Megadrive mais avec un peu plus de données et donc un peu moins de compromis.
La fidélité est quand même plutôt au rendez-vous. Les versions consoles semblent au moins s’appuyer vraiment sur les data originaux qui structurent l’environnement à défaut d’utiliser les patterns graphiques. On a exactement la même physicalité de l’environnement qu’en arcade.
J’ai déjà longuement évoqué la scène de la tempête sur X68000. Mais c’est une scène vraiment intéressante car chaque version a ses astuces qui lui sont propres pour s’adapter au hardware (on peut dire la même chose pour la scène de l'ascenseur du stage 3).
On a vu que la version X68000 utilise plein de bidouille pour réussir à reproduire cette scène. Sur cette version SuperGrafx ils n’ont pas manqué d'ingéniosité non plus. Notamment ils ont simulé l’animation des arbres secoués par les bourrasques par l’intermédiaire d’un raster effect de distorsion plutôt qu’une véritable animation de tuile. Le résultat est assez convaincant et fidèle.
Ces raster effect ont permis d’avoir une animation des arbres en 4 frames comme dans la version arcade tout en économisant beaucoup de tuiles et donc de données en ROM. Ce coût faible a permis d’animer aussi les arbres du second plan de la même façon. Des choses qui n’ont pas pu être préservées sur la version Megadrive mais on reviendra une troisième fois sur cette scène dans le chapitre Megadrive.
Et contrairement à toutes les autres versions, l’averse est ici constituée entièrement de sprites. Ça donne une pluie moins intense mais, en contrepartie, ça permet de ne pas avoir le HUD ou l’arrière plan qui clignote comme c’est le cas dans toutes les autres versions qui utilisent le plan du HUD ou de l'arrière plan pour afficher la pluie en alternance. Le SuperGrafx étant moins flexible sur la gestion de priorité des plans, il a fallu trouver une autre solution.
Mais cette scène nous montre encore une fois à quel point le travail d’ajustement du jeu au spécificité hardware des machines est omniprésent. Ce sont tous des portages qui témoignent d’une certaine volonté de bien faire malgré le manque de temps.
Pour constater les autres différences visuels, il existe plein de comparatif vidéo entre les versions arcade, Megadrive et SuperGrafx comme celle ci:
Tout ce qui concerne les hitbox semble aussi construit sur les données du jeu original. J’en ai parlé dans le premier chapitre, on retrouve même cette gestion particulière des collisions du jeu d’arcade original qui alterne entre une fréquence de test de collision élevée (60 hz) et faible (15 hz) selon le type d’ennemi.
Même la gestion du scrolling et du spawn des ennemis me semble très similaire à l'arcade malgré la différence de résolution comme si cette version était destinée à un affichage en 384 pixels (la résolution horizontale du jeu sur CPS contre 320 pixels sur SGX et MD). La facilité avec laquelle j’ai pu élargir le cadre du jeu SuperGrafx dans un hack pour le faire passer de 320 pixels à 352 pixels sans que ça ne génère de glitch me conforte dans cette idée.
Ça m'avait alors permis d’élargir le champ visuel (FoV, field of view) vers l’avant pour coller à celui de la version arcade.
C’est l’occasion d'évoquer un autre downgrade malvenu de cette version après celui des palettes.
Ghouls’n Ghosts SuperGrafx utilise un mode vidéo alternatif de la PC-Engine qui pousse plus haut la résolution horizontale (au-delà de ce qui était possible sur SNES ou Megadrive). Celui utilisé dans des jeux comme Ninja Spirit ou R-Type, mais ici dans une version dégradée qui a pour but de moins stresser les chips VRAM. NEC a, semble t’il, eu une soudaine panique vis à vis de potentielles défaillances et a donc subitement donné certaines directives sur l’usage de ce mode vidéo par les devs.
Nec Avenue étant en charge de cette version, ils ont appliqué ces directives à la lettre. La version US de R-Type en a subi aussi les conséquences et s’en trouve downgradé par rapport à la version Japonaise qui utilise pleinement ce mode vidéo. Par la suite les choses semblent être revenues à la normale mais le mal était fait pour Ghouls’n Ghosts.
Les conséquences de ce mode dégradé, en plus de ne pas utiliser pleinement la résolution horizontale, c’est de réduire le nombre de sprites affichés par scanline.
Mon hack rétablit l’usage complet de ce mode vidéo et permet donc d'augmenter le nombre de sprites affichés en plus d’élargir l’image. Je vous renvoie à la page du hack pour plus de détails ici.
Entre la correction de ce mode vidéo dégradé et une pleine exploitation des palettes, il y aurait moyen de faire une version SuperGrafx nettement améliorée.
La résolution/FoV plus faible implique aussi une déformation de l’image (étirement horizontal pour remplir l’écran), et donc des éléments graphiques aux proportions un peu altérées sur les versions consoles. Par contre, ce mode vidéo utilisé sur cette version SuperGrafx offre un format de pixel (PAR, pixel aspect ratio) un poil plus proche de l’arcade que la version Megadrive et donc des proportions graphiques un peu plus conformes.
En effet, même si les 2 versions sont affichées en 320 pixels, elles utilisent des dotclock différent: 6,71 Mhz sur Megadrive contre 7,16 Mhz sur SuperGrafx qui est un peu plus proche des 8 Mhz du CPS. Cela signifie que sur SuperGrafx, avec seulement 320 pixels, t’as un peu de bande noire sur les côtés même si caché en partie par l’overscan de la TV. Et ça explique qu’on peut étendre à 352 pixels avec mon patch quand on grignote les bandes noires.
Donc les 320 pixels de la version SuperGrafx ne sont pas tout à fait les mêmes 320 pixels que la version Megadrive. Lorsque affiché sur le même CRT, ça donne ces formats et proportions graphiques:
Les proportions des objets sur SuperGrafx comme le coffre, la tombe, l'échelle ou celles des sprites de Arthur, du squelette, de la skull-flower, sont un peu plus conformes à la version arcade, un peu moins étiré horizontalement, mais c’est très léger.
A l’inverse, sur cette image on peut avoir l’impression que le relief du sol est moins conforme sur SuperGrafx. En réalité toutes les versions ont le même relief du sol, la même physicalité, c’est la représentation visuel de ce relief qui parfois pose problème. La version arcade a beaucoup de tuiles différentes pour représenter le sol selon le relief. Ce n’est pas le cas des versions consoles qui doivent parfois bricoler la représentation du relief avec un set de tuile plutôt limité.
Le résultat sur console varie selon les passages. Parfois c’est mieux réussi sur SuperGrafx ou sur Megadrive, mais globalement la version Megadrive s’en sort mieux pour représenter le relief. Je pense qu’ils ont été plus ingénieux dans la construction du set de tuile. Notamment sur ce premier stage, la version SuperGrafx a tendance à empiler des tuiles d’herbe pour représenter les micro-reliefs, ce qui fonctionne moins bien visuellement. Mais rassurez-vous, du point de vue physique, le relief semble strictement fidèle à la version arcade dans ces versions consoles, de ce que j’ai pu comparer. C’est juste une dérive visuelle liée à la plus grande pauvreté de leur set de tuile.
Toutes les versions du jeu présenté ici ont un très bon framerate en 60 fps et plutôt stable. La version SuperGrafx est peut être celle qui a le plus de drop en situation de jeu “normal” (mais je n’ai pas non plus d’analyse très poussée sur le framerate de la version X68000 qui a aussi ses faiblesses comme indiqué plus haut). C’est environ 1 à 2% de drop frame. C’est peu et plutôt dilué donc on ne le ressent pas vraiment mais la Megadrive semble s’en sortir encore mieux, il n’y a presque aucun drop... enfin sauf dans certaines situations où la tendance s’inverse. Par exemple, si vous utilisez massivement l’eau bénite pendant l'ascension de la colline avant le premier boss, le framerate va être lourdement impacté. On le sent vraiment passer ce qui, au final, peut laisser une impression de meilleure stabilité du framerate sur la version SuperGrafx.
Faire tourner le code source du jeu d’arcade sur le petit CPU 8 bit de la PC-Engine (la SuperGrafx utilise le même CPU) qui doit, en plus, s’occuper du son contrairement aux autres versions, n’est pas un défi facile à relever. De ce fait, le résultat est plutôt impressionnant. Le framerate est clairement plus stable qu’un Super Ghouls’n Ghost par exemple.
Pour terminer sur cet aspect, on peut ajouter que les versions consoles (SuperGrafx et Megadrive) ont l’avantage pour l’input lag. Elles ont une frame de latence de moins que les versions arcades (à l'exception des frames qui drop). C’est dû à la nature du CPS qui construit son image en bufferisant les sprites dans un framebuffer.
Mais on parle d’une époque et un contexte où l'input lag est tellement bas qu’une différence de 16 millisecondes n’a pas d’effet notable. Donc c’est une remarque plutôt symbolique.
En ce qui concerne la difficulté, cette version SuperGrafx est entièrement calibrée sur les données de la version arcade japonaise (donc la version arcade la plus difficile).
Cela signifie que tout le système de ranking ainsi que le comportements des ennemis utilisent strictement les mêmes données et tables de valeurs que la version arcade japonaise. On retrouve aussi exactement les mêmes réglages par défaut que ceux de la version arcade (quand tous les dip switch sont en position off). C'est à dire un mode de difficulté “normal” (niveau 4 sur 8) avec donc le même rank de départ et la même cadence de rankup, seulement 3 vies et un réglage des paliers de 1UP qui correspond précisément au niveau 3 sur 4 de la version arcade japonaise.
Ce sont aussi les réglages par défaut de la version Megadrive mais contrairement à la version Megadrive, il y a aussi une possibilité d’accès à tous les autres réglages de la version arcade japonaise (les autres modes de difficulté, nombre de vie et paliers de 1UP) au travers d’un menu caché qui l’est à peine car il s’agit simplement de presser le bouton 1 avant d’appuyer sur start pour lancer la partie.
La plus grosse différence avec les autres versions vient surtout de l’absence de continu infini. Le jeu n’offre au joueur que 3 continus et rien de plus, même dans le menu caché. Ça pose un peu le ton de cette version.
On est sur la version la moins accueillante. Pas de réglage de difficulté par défaut ni de vrai mode practice (même le mode de difficulté minimum dans le menu caché reste une option qui agit très peu sur la difficulté comme expliqué dans le chapitre 2) et pas de continu infini en plus d’une difficulté à la japonaise clairement supérieur aux versions arcade World ou US. C’est une version qui s’adresse plutôt aux joueurs qui connaissent bien le jeu et se sont déjà précédemment entraînés sur d’autres versions.
D’autant qu’il y a d’autres éléments qui en font une version même plus difficile encore que la version arcade japonaise.
En effet, en plus d'être calibré exactement comme la version arcade japonaise, cette version est pénalisée par un champ de vision moins étendu (comme sur Megadrive) dû à la résolution horizontale plus faible. Je vous en ai déjà parlé plus haut mais ça agit donc aussi sur la difficulté en offrant moins de possibilités d’anticipation.
De plus, utiliser une résolution horizontale plus faible tout en s’appuyant directement sur les données du jeu d’arcade (structure de l’environnement, vitesse de déplacement…) implique que la vitesse horizontale apparente des objets (ennemis, bullets…) ainsi que celle du scrolling, semble un peu plus élevé. Au final ça donne une sorte de dynamique un peu plus intense à l'ensemble du jeu.
Les conséquences de la résolution plus faible des versions SuperGrafx et Megadrive reste acceptable car l'écart est de seulement +20% en faveur du CPS. Il en aurait été autrement avec la SNES. Un portage haute fidélité comme celui là qui consiste à reprendre directement le code source et les données du jeu d’arcade n’aurait pas été viable sur SNES car l'écart de résolution est de +50%. Les conséquences deviendraient trop problématiques. Il faudrait tout modifier.
C’est pour cela aussi par exemple que dans certains portage de jeu sur console portable (qui ont des résolutions très faibles) parfois ils modifient les vitesses (objet, scrolling) pour compenser car c’est souvent problématique. Par exemple, le Wonder Boy Game Gear qui est un copier-coller de la ROM Master System, a tout de même subit une modification de ses valeurs de vitesse pour les réduire mais c’est pas si simple à calibrer. Dans Master of Darkness, qui est un autre portage SMS vers GameGear, ils ont dû refaire tout le level design (mon billet ici).
Dans ces conditions, produire un tout nouvel épisode sur SNES (Super Ghouls’n Ghosts) était une bonne décision. De surcroît, ca leur a permis de modifier le gamedesign pour équilibrer le jeu différemment avec un peu plus de focus sur le plateforming et un peu moins sur le shooting (le double saut qui remplace le shot 4 way, les déplacements plus lents, les projectiles du joueur plus lent et moins nombreux simultanément…) pour mieux correspondre à son publique et peut être aussi aux ressources CPU.
En parlant de FoV (field of view), on peut aussi signaler que la version SuperGrafx offre un petit bonus. En effet, si le jeu d’arcade utilise un affichage en 224 lignes, cette version SuperGrafx est en 239 lignes, la seule version dans ce cas.
Alors il n’ont pas pour autant créer du graphisme qui n’existait pas pour combler les trous. Non, ils se sont contenter d’exploiter ce surplus de lignes uniquement dans les passages du jeu ou il y a de la verticalité pour étendre un peu le FoV vers le haut (dans les autres cas il y a juste une bande noire). L'intérêt est bien moindre que pour le FoV horizontal car on reste quand même dans un jeu où l'action et les déplacements sont principalement horizontaux. Les déplacements verticaux sont plus rares, encore plus vers le haut, et ils sont lents.
De plus, sur une TV il y a toutes les chances que ce surplus de ligne soit overscané et donc non visible à l'écran. C’est d’ailleurs pour cette raison que le format 224 lignes est bien plus souvent privilégié au point d'être un peu le standard de l’époque (que ce soit ici sur CPS ou sur tous les jeux 16 bit en général). Mais en émulation on peut en profiter. C’est un petit bonus.
Si cette version SuperGrafx est très fidèle à la version arcade japonaise, j’ai identifié au moins une séquence dont la difficulté est sensiblement rehaussée par rapport à toutes les autres versions. Il s’agit du stage 3-1.
Dans cette séquence d'ascenseur ou l’on se fait bombarder par des gobelins volants on remarque des différences spécifiques à cette version.
Cela concerne la fréquence à laquelle les gobelins lâchent leur cailloux qui est plus élevé d’environ +50% sur cette version SuperGrafx. Mais ça concerne aussi leurs attaques kamikaze (attaque “Galaxian”). On peut remarquer que sur cette version ils attaquent toujours par 2 (j’ai même déjà vu 3) alors que dans les autres versions c’est seulement un par un à tour de rôle.
Malheureusement ces paramètres (fréquence de bombardement et nombre de kamikaze simultanés) ne sont pas définis dans des tables de valeurs mais dans le code lui-même à priori donc je n’ai pas eu l’occasion de creuser plus loin la comparaison.
Je me demande si cette différence ne vient pas de dommages collatéraux liés à un remaniement du code pour corriger un bug du jeu original car dans toutes les autres versions on constate un petit problème en tout début de stage. Tous les gobelins ont tendance a spawn tous groupé sur la droite de l’écran alors que la RNG est censée les répartir sur la largeur de l’écran. Les choses rentrent dans l’ordre un peu plus loin quand l'action se décale vers la droite. C’est comme si le code originel ne prenait pas en considération qu’en début de stage l’action est décalée sur la gauche.
Sur la version SuperGrafx ce problème semble corrigé, tu n'as pas ce petit bug. Le spawn des gobelins se répartit bien sur toute la largeur dès le début du stage (histoire de compliquer un peu plus les choses ^^).
J’ai identifié aussi un problème dans cette version qui rend l’usage de l’épée plus périlleux que sur les autres versions. L’épée est une arme censée être multi-hit. Elle peut toucher plusieurs ennemis à la fois mais sur la version SuperGrafx, ses capacités multi-hit sont partiellement entravées car les tests de collisions s'arrêtent dès la première collision constatée avec un obstacle indestructible.
Ça donne pour conséquence une épée qui parfois ne fonctionne pas si il y a un obstacle indestructible dans le champ dont la priorité de test de collision est plus haute que celle de l’ennemi.
Heureusement c’est une arme qu’on ne pratique pas trop dans le jeu. Pas qu’elle soit nulle, ses damages x2 sont très efficaces dans beaucoup de situations, mais face aux boss elle condamne très souvent le joueur, c’est donc très risqué de la prendre.
Il existe aussi un autre bug qui cette fois est en faveur du joueur. Ça concerne la charge des ogre-porcs.
Comme je vous l’ai indiqué dans le chapitre 3. La vitesse de charge de l’ogre-porc est influencée par le ranking du joueur. Par défaut, elle est de 563 sppf. Une vitesse qui est ensuite ajustée selon le rank par l’intermédiaire d’une table de 16 valeurs (une par rank).
A l’origine cette table contient des valeurs 16 bit comme toutes les tables de vitesse. Jusqu'à maintenant, la version SuperGrafx utilisait les tables 16 bit du code source original mais pour celle-ci, il semble qu’ils aient voulu optimiser la table en la convertissant en 8 bit (pour économiser 16 octets). Ils ont probablement jugé que c’était suffisant pour couvrir la gamme de valeur de cette table. Sauf que non, ce n’est pas le cas, car les valeurs de cette table s'étendent de -102 à +153 ce qui est un poil trop étendu (en 8 bit on peut couvrir une gamme de -128 à +127).
En conséquence, le calcul pour déterminer la vitesse de charge va être erroné pour les rank 15 et 16. Au lieu de donner une vitesse de charge maximale, ça va donner une vitesse de charge minimale, équivalente aux plus bas rank (celle des rank 1,2 et 3).
Heureusement c’est un bug qui concerne uniquement ces 2 rank les plus extrême donc les conséquences sont assez limitées mais si le joueur se trouve dans ce cas là il appréciera ^^.
Certains éléments de la version Megadrive ont déjà été évoqués dans le chapitre SuperGrafx qu’il est donc préférable de lire avant. Ces versions partagent des choses en commun. D’ailleurs, comme pour la version SuperGrafx, cette version Megadrive est un portage exécuté par un tiers, Sega, et en très peu de temps (5 mois).
La première chose vraiment notable de cette version Megadrive est sa précocité. Environ 9 mois seulement après la version arcade. La Megadrive, première console avec un CPU 68000 (celui du CPS), est arrivée sur le marché avec un timing parfait pour recevoir ce jeu culte. Si en plus le portage était fidèle à la version originale alors le combo serait idéal… Et ça va être le cas malgré une contrainte de capacité ROM vraiment très forte malheureusement.
Yuji Naka, chargé de ce portage par Sega, s’est exprimé sur ce projet (interview). Il avait notamment confirmé avoir eu accès au code source et aux ROMs du jeu d’arcade. Mais entre les traductions qui altèrent souvent les propos et les souvenirs des devs qui parfois se mélangent entre leurs divers projets, le doute pouvait persister. De plus, le fait d’avoir eu accès à tout ça ne dit pas non plus ce qu’ils en avaient fait concrètement dans le jeu.
Donc après avoir creusé la question pour ce billet, je suis bien content de pouvoir confirmer que ces données et ce code source a réellement été exploité directement dans le jeu, comme pour les autres versions, et n’a pas servi juste de documentation.
Pour l’anecdote, Yuji Naka a aussi révélé que c’est sur ce projet qu’il va apprendre à faire un jeu d’action avec un sol qui a du relief, des pentes… ce qui va lui inspirer Sonic en poussant beaucoup plus loin cette idée. Donc en quelque sorte cette inspiration vient en grande partie du code source de Ghouls’n Ghosts.
On comprend alors que partager du code source à un partenaire, qui est aussi un concurrent, ce n’est pas anodin. Il faut féliciter encore une fois Capcom de l’avoir fait pour un jeu aussi ambitieux, fer de lance du CPS et du renouveau de Capcom, et à peine sorti du four a ce moment-là.
Venons en au gros problème, ou défi, de cette version: La très faible capacité de la cartouche (5 Mbit).
On le répète jamais assez mais la qualité visuelle des jeux consoles de l’époque est très très corrélée à la taille de la cartouche. Si on avait eu des versions 32 Mbit de Ghouls’n Ghosts sur Megadrive ou SuperGrafx, croyez moi, il ne ressemblerait pas du tout à ça et serait bien plus proche de l’arcade (c’est l’une des forces de la version X68000 qui a pu reprendre directement les données graphiques de l’arcade).
Il existe d’ailleurs un projet, toujours en cours, d’une édition “Arcade” de Ghouls’n Ghosts sur Megadrive. En réalité un hack qui recrée toutes les données graphiques en s’affranchissant de cette contrainte des 5 Mbit pour s’approcher bien plus de la version arcade. Ça fait 3 ans que aMaru travaille dessus. Il est actuellement sur le stage 3 et partage des comparatif sur sa chaîne youtube ici.
Et même si le projet ne devait pas aller au bout, ça nous montre ce qu’il est possible de faire avec une capacité de cartouche à la hauteur de la version arcade.
Ça donnerait probablement une version encore plus proche de l’arcade que la version SuperGrafx (qui elle-même pourrait s’approcher encore plus de l’arcade sans ces contraintes de ROM).
Mais, nous, on a eu cette version 5 Mbit et tout ce que ça implique. Yuji Naka nous précise même que le projet devait tenir sur 4 Mbit mais qu’il a fait des pieds et des mains pour obtenir 1 Mbit de plus. Il était sans doute bien conscient de la chance de pouvoir faire ce portage à partir du matériau d’origine pour obtenir un haut niveau de fidélité mais que la taille de la cartouche empêchait de profiter de cette opportunité pour atteindre cet objectif. 1 Mbit de plus c’est vraiment pas grand chose (c’est tout de même la moitié de Ghouls’n Ghosts Master system qui fait 2 Mbit) mais étant donné les contraintes extrêmes c’était surement salvateur. On a pas envie de savoir à quoi ressemblerait le jeu en 4 Mbit.
5 Mbit c’est étonnant aussi car ce n’est pas standard. Il n’existe pas de ROM de 5 Mbit donc ça implique de passer par une cartouche composé de deux ROM (4 Mbit + 1 Mbit) ce qui n’est pas très optimal en terme de coût mais le marché des chips ROM (et d’autres chips comme la SRAM) est tellement tendu à cette époque que ce genre de configuration avait probablement du sens malgré tout.
On comprend bien alors que sur cette version l’essentiel de l’effort va consister à trouver des solutions pour tout faire entrer sur la cartouche. Et comme les graphismes (décors, sprites) sont de loin ce qui prend le plus de place, c’est la dessus que les plus gros compromis vont se faire.
Vous connaissez sans doute déjà la quantité de compromis graphiques qu’il a fallu faire sur cette version. Malgré tout le résultat est très respectable et, en 89, faisait vraiment son petit effet (j’ai eu la chance d’y jouer en import JP à l’époque, j’ai trouvé ça sublime).
Ces compromis vont avoir un impact esthétique mais impliquent parfois des conséquences plus structurelles.
Notamment, comme je l’ai évoqué dans le chapitre précédent, cette version Megadrive n’a pas repris directement tous les sprites arcade comme la version SuperGrafx. La plupart ont été redessinés pour être mieux adaptés aux contraintes. Les sprites restent malgré tout très fidèles mais parfois ils sont plus petits. L’exemple le plus flagrant étant l’ogre-porcs.
Ça explique peut-être que les collisions sont parfois différentes si ces changements graphiques les ont poussés à devoir remanier les données des hitbox plutôt que de prendre celle du code source originel. Mais je reviendrais la dessus plus loin.
Cela dit parfois le sprite est strictement celui de la version arcade comme celui de Arthur qui est plutôt réussi.
On remarque aussi, sur cet exemple de l’ogre-porc, les contraintes de palettes qui donnent parfois des situations qui dérivent assez loin de la version originale pour des raisons très différentes de la version SuperGrafx finalement. Dans le cas présent c’est un peu plus subis que choisie. Avec seulement 4 palettes programmables il faut faire beaucoup de compromis pour sélectionner des couleurs qui vont devoir être communes à plusieurs ennemis ou éléments de décors.
Le travail d’adaptation sur les graphismes du décors a aussi des conséquences structurelles.
Dans cet exemple, l'arbre n’a pas tout à fait la même forme.
Ça n'aurait aucune importance si l’arbre en question ne servait pas ici à définir la position des ennemis (vautours). Une branche de gauche trop basse combinée à une erreur de placement du vautour de droite donne une combinaison différente de level design (le vautour de droite se retrouve plus haut que celui de gauche alors que c’est censé être l’inverse) qui change légèrement le flot de cette séquences.
Typiquement, pour ma part, j’aime bien franchir ce passage de cette façon (ci dessous) ce qui fonctionne très bien sur toutes les versions mais impossible à exécuter sur la version Megadrive.
Mais en réalité je n’ai pas vraiment d’autres exemples que celui ci qui me vient. Ce n’est pas très représentatif du jeu car globalement la physicalité de l’environnement et le placement des ennemis suit plutôt strictement la version arcade avec toujours un niveau de fidélité très élevé (la preuve en est les bugs d’environnement de la version arcade que j’ai exposé dans le premier chapitre et que l’on retrouve à l'identique sur ces versions Megadrive et SuperGrafx) même si un peu moins fidèle que sur les autres versions.
Ca ressemble plutôt à des erreurs ponctuelles dues à la précipitation et qui sont des exceptions comme celle ci qui trahit sans doute une corruption involontaire des données utilisées pour la physicalité de l’environnement. Il manque un morceau au bout de cette corniche.
Le HUD de cette version Megadrive est aussi la cause de certaines contraintes et compromis.
Le CPS a la chance d’avoir 3 layers de background en plus de son layer sprite. Ça laisse pas mal de liberté pour la composition de l’image comme utiliser le 3ème layer pour afficher le HUD. De son côté, la version X68000 utilise son layer texte qui est un layer 16 couleurs, suffisant pour le HUD. Sur SuperGrafx ce sont des sprites qui vont composer le HUD grâce au surplus qu’offre le second chip graphique.
Mais sur Megadrive, qui possède seulement 2 layers de background comme la SuperGrafx, ils vont choisir d’utiliser une partie du second plan de background (fonction window) pour le HUD. Cela signifie que le second plan du décor sert aussi à afficher le HUD. Ce choix va empêcher d’avoir un arrière-plan de décors avec scrolling différentiel lorsqu’il y a de la verticalité dans le stage, voire pas d'arrière-plan du tout.
Par exemple le segment 1-2 ou le segment 4-2 dont on perd complètement l'arrière-plan (bien présent sur la version SuperGrafx), remplacé par un simple fond noir.
Ça crée aussi des glitchs visuels dans les autres segments ou il y a un peu de scrolling vertical comme sur ce segment 2-1. On voit une bande noire, prolongement du HUD, couvrir la colline d'arrière-plan, tout comme le toit du moulin, car ce sont les mêmes plans en réalité.
Une autre conséquence de ce HUD est visible dans la séquence de la tempête.
Dans le jeu d’arcade, l’averse de pluie est affichée en utilisant le layer du HUD en alternance. C’est à dire que lorsque le jeu affiche la pluie, le HUD disparaît. Ça crée un petit effet de clignotement sur le HUD.
La version Megadrive reprend exactement la même idée… sauf que le plan du HUD est aussi celui de l'arrière-plan donc c’est tout l'arrière-plan qui clignote avec le HUD. Mais pas si gênant car l’affichage de la pluie est vraiment très brève (une frame toutes les 5 frames).
Mais il y a un élément bien plus amusant dans cette séquence dont personne ne parle jamais. Un élément pourtant très visible et drôle ^^.
C’est la seule version, parmi celles exposées ici, qui n’a pas animé les arbres de l’arrière-plan. Ce serait trop de données graphiques à stocker en ROM. Le compromis qu’ils ont trouvé c’est de changer complètement la représentation des arbres du second plan en les effeuillant intégralement. Les arbres n’ont plus aucun feuillage et sont entièrement élagué pour justifier le fait qu’ils sont statiques malgré qu’il soit balayé par la tempête. C’est du génie! C’est ça aussi le travail d’adaptation.
On peut ajouter aussi que lors de la séquence de l'ascenseur du segment 3-1, le HUD est responsable de la disparition du décors sous la plateforme (et dans la partie supérieure de l’écran). Encore une fois ce sont deux séquences symptomatiques du jeu qui ont chacune leur spécificité selon les versions.
Cette réduction drastique des données graphiques impacte aussi les animations. Il a fallu retirer certaines frames d’animations des ennemis. Surtout pour les boss qui, par leur taille, consomment beaucoup d’espace ROM.
Par exemple, le premier boss a une animation d’introduction qui le fait sortir de son état de statue de pierre puis prendre sa tête dans sa main. On retrouve cette animation sur SuperGrafx mais pas sur Megadrive.
La même chose avec le deuxième boss, le chien de l’enfer, qui perd certaines frames d’animation sur Megadrive (notamment pour son jump) contrairement à la version SuperGrafx.
Les mains géantes du stage 4 est un autre exemple d’ennemi dont les frames d’animation ont été largement sacrifiées sur cette version pour faire de la place dans la ROM.
Dans sa version arcade, ou même SuperGrafx, c’est un ennemi qui compte 10 frames d’animations pour ses différents état (idle, slime, transformation, préhension du joueur), réduit à seulement 3 frames sur la version Megadrive (2 frames d’animation idle + 1 frame statique pour la préhension) notamment parce qu’ils ont retiré toute la phase en slime et donc aussi la transformation.
Les économies de données graphiques pour cette ennemi vont jusqu’aux bullets réduit à une petite bille verte sur Megadrive, en remplacement d’une représentation animée beaucoup plus graphique et imposante sur les autres versions.
En ce qui concerne le boss final il y a quelques compromis aussi. Le pixel art et la taille du boss est strictement celui de l'arcade, ce qui est déjà un très chouette effort, mais certaines frames d’animation ont disparu au niveau du visage, de la main juste avant de tirer, de la position du bras. Malgré tout, le résultat est très fidèle ce qui reste étonnant quand on connait les contraintes d’espace.
La symétrie horizontale de toute la scène combinée à la fragmentation du corps du boss en éléments indépendants aide à optimiser l’espace occupé. Mais il serait intéressant de mesurer le pourcentage de ROM occupée par ce boss final sur la cartouche Megadrive qui ne doit pas être négligeable. Il n'est pas simple de décider quel espace accorder à un élément du jeu qui est à la fois emblématique mais que peu de joueurs verront. Le genre de dilemme complexe auquel les développeurs doivent faire face au quotidien dans ce type de contexte à très hautes contraintes.
On peut signaler tout de même que, dans la version SuperGrafx, ils ont réussi à préserver la scène quasi identique à l'arcade (modulo la palette). Aucun compromis sur les frames d’animations encore une fois.
Voilà donc quelques constats que l’on peut faire sur la fidélité graphique du jeu qui était un défi impossible à cause des capacités ROM et de certaines contraintes techniques mais qui fait tout de même illusion grâce au travail d’adaptation.
J’avais annoncé un peu plus haut qu’on parlerait des hitbox. On constate que sur Megadrive les collisions sont altérées et ne respectent pas la version originale. C’est quelque chose que vous avez probablement déjà entendu avec l’exemple frappant des fireball du premier boss.
Cette image nous montre la toute dernière frame avant que le joueur prenne un hit. Sur la version Megadrive, cette collision semble prématurée ou en tout cas pas très fair play vis à vis des règles tacites de gamedesign qui veulent que les collisions soient toujours à l'avantage du joueur.
Ce genre de collision un peu sévère est un défaut qui est malgré tout relativement classique sauf qu’ici on parle d’un portage basé sur le code source du jeu d’arcade et donc on s’attend à avoir un comportement fidèle à l'original comme on peut le voir ici sur SuperGrafx.
On peut émettre l’hypothèse que les modifications graphiques conséquentes, notamment sur la taille des sprites, a poussé l'équipe à revoir aussi les données de collision telles que les hitbox. C’est ce que je sous-entendais plus haut mais ce qu’on observe pourrait aussi s’expliquer simplement par une sorte de décalage dans le traitement des collisions. Un décalage temporel ou un décalage spatial lié à un problème dans la routine de collision qui produirait cette différence malgré que les données de hitbox soit celle du jeu d’arcade.
Par exemple, sur la version Megadrive on peut retomber plus tôt sur la fireball sans se prendre un hit (le gif nous montre le cas optimal, si Arthur tombe une frame plus tôt il prend un hit).
Dans ce sens là c'est à l'avantage du joueur sur Megadrive. Un peu comme si la hitbox n’était pas plus grosse mais simplement décalée vers la gauche par rapport au feedback visuel.
J’ai d’ailleurs remarqué d’autres situations où la hitbox semble plus favorable au joueur sur la version Megadrive comme la séquence des turtle-rock par exemple.
Cette générosité existe déjà dans les autres versions (la hitbox des turtle-rock couvre seulement leur moitié droite, ça semble volontaire) mais c’est encore plus accentué ici sur la version Megadrive. Et cet exemple contredit l'hypothèse précédente (fireball) d’un décalage vers la gauche de la hitbox.
J’ai noté aussi ce passage classique de début de partie ou l’on se doit d’ouvrir le coffre par la droite pour ne pas ensuite être condamné à prendre l’arme qui se trouve dedans. Sur toutes les versions ça consiste à sauter par dessus la guillotine quand elle descend mais sur Megadrive on peut simplement passer en dessous.
Mais là aussi je ne suis pas certain que ce soit la hitbox de Arthur qui soit plus petite, peut être qu’elle est simplement décalée d’un pixel vers le bas. C’est de l’ordre d’un seul pixel de différence.
Il suffit d’une petite différence de code dans la façon de borner les collisions pour que ça génère une sorte de décalage ou que ça élargisse ou réduise virtuellement les hitbox d’un pixel malgré des données semblables. Il faudrait lire le code de la routine.
Sur le segment 4-2 Arthur passe aussi plus facilement sous les bullets.
Mais il y a plein de causes possibles qui peuvent expliquer que ça touche dans un cas et pas dans l’autre (et pas forcément parce que la bullet est visuellement plus petite).
Ça ne sert a rien de tergiverser plus longuement sur cette question car je compte bien un jour coder un visualiseur de hitbox pour cette version Megadrive comme je l’ai fait sur la version SuperGrafx. Ce sera beaucoup plus pertinent de comparer les hitbox à ce moment-là (ce qui reviendrait à comparer avec la version arcade si on considère que la version SuperGrafx semble bien utiliser les données de l’arcade sur ce point). J’attend juste un émulateur Megadrive avec des outils debug qui approche la qualité de ceux que j’utilise pour les autres consoles.
J’ai aussi parfois constaté que certains ennemis, qui ont des points de spawn fixe dans l’environnement, ne spawn pas. Par exemple, ça m'arrive parfois avec l’ogre-porc et la skull-flower qui se trouve au sommet de la colline juste avant le premier boss (ou le dernier totem du segment 4-1). Dans ces cas là le joueur est plutôt content mais ça laisse penser que la gestion du spawn des ennemis est un peu différente sur cette version Megadrive qui explique peut être que parfois ça s’enraye un peu.
J’ai remarqué aussi des différences sur la gestion de la RNG (le générateur de nombre aléatoire qui permet de simuler le hasard). A priori elle est moins chaotique sur cette version Megadrive. Dans les autres versions, SuperGrafx inclus, la RNG change à chaque frame et est influencée par tous les inputs cumulés que le joueur presse à chaque frame (actuelle et précédente) et donc aussi leur durée. Ça n’est pas le cas sur la version Megadrive. C’est plutôt comme si il y avait une seed choisie en tout début de partie qui pré-détermine ensuite toute la RNG de la partie.
Il y a un test simple à faire pour observer cela. Vous faites une savestate au tout début du combat contre le premier boss sur la version SuperGrafx ou arcade. A chaque fois que vous rechargez la savestate, les patterns du boss seront différentes car vos inputs ne seront jamais exactement les mêmes. La RNG influence la direction dans laquelle le boss se déplace, la vitesse de son déplacement, combien de temps il se déplace dans cette direction, combien de temps il va s'arrêter avant de choisir à nouveau une direction de déplacement, le mouvement de sa tête etc… Le déroulé du boss fight sera donc chaque fois différent sur ces versions. Mais sur Megadrive si vous rechargez la même savestate vous aurez le même déroulé du boss fight, les même comportement au même moment, peu importe vos inputs (et même si vous mourez, la tentative de boss fight suivante sera similaire, ou quasi car le dérank change certains paramètres comme je vous l’ai expliqué).
Globalement la RNG semble moins chaotique sur Megadrive, plus déterminée. J’ai l’impression que dans les stages ou boss fight on a plus de chance de retomber sur des configurations et déroulés qu’on a déjà vu et expérimenté. Sur les autres versions ça se déroule jamais 2 fois exactement pareille. Il y a une infinité de configuration.
Il y a une autre explication possible qui viendrait de l’émulation que j’utilise. Les bons émulateurs sont très fiables aujourd’hui. On peut être très confiant. Mais le cas de la RNG est un peu particulier car certaines routines de RNG peuvent parfois utiliser des trick très tordus pour simuler la RNG en profitant de certains aspects analogiques ou aléatoires du hardware. On peut dire que la RNG est un cas sensible quand il est question de fiabilité de simulation. Mais les indices que j’ai me permettent de plutôt penser que le problème ne vient pas de là. Je pense que c’est juste une simplification de la routine RNG sur la version Megadrive.
Comme pour les collisions, ca nécessiterait d'être creuser plus en profondeur (analyse du code) pour de futur mises à jour du billet (quand y aura un émulateur Megadrive avec de bons outils debug ^^) car dans tous les cas il est certain qu’il y a une nette différence de traitement sur ce point avec les autres versions.
Les contraintes d’espace sur la ROM sont si fortes qu’ils ont certainement dû aussi trouver des moyens de réduire la taille du code, pas seulement les données, ce qui a peut être poussé à simplifier certaines routines (que je devine exagérément grosse dans le code source originel) comme la RNG ou les tests de collision. Ça peut être une explication.
Maintenant abordons la difficulté, le système de ranking, les différents modes et la régionalisation.
Comme pour la version SuperGrafx ou X68000, les versions Megadrive utilisent directement les données de la version arcade japonaise, que ce soit pour configurer le système de ranking ou pour toutes les données utilisées pour le comportement des ennemis. On retrouve les mêmes tables, tout du moins la centaine que j’ai comparé. Ça veut dire aussi les mêmes paramètres par défaut (nombre de vie, palier de 1UP…).
Enfin tout ça concerne le mode “professional” de cette version Megadrive car le jeu propose aussi un mode de difficulté alternatif, le mode “practice” qui a des spécificités qui lui sont propres. En effet, contrairement à toutes les autres versions, sur Megadrive on a aucun accès aux divers réglages fin de la difficulté malgré que les données correspondant à ces réglages existe bien dans la ROM de la version Megadrive (on retrouve par exemple les données de paramétrages des 8 modes de difficultés de l’arcade mais on ne peut pas les sélectionner). En contrepartie, le jeu propose un vrai mode “practice”.
D’un point de vue formel, ce mode “practice” occupe simplement le slot du mode de difficulté 1 de l’arcade (le mode “professional” étant le mode de difficulté 4 de l’arcade) mais en changeant les valeurs et en ajoutant des features.
Les paramétrages du système de ranking selon le mode de difficulté donne ça sur Megadrive:
A comparer avec la table originale des autres versions (sauf arcade world):
Le mode “practice” propose donc une cadence très lente de progression jusqu’au rank max. Plus lente même que le mode 1 de la version arcade world. Le joueur est moins sous pression.
Mais ce n’est pas le seul levier utilisé par ce mode “practice” pour aider le joueur. Ils se sont aussi inspirés de la version arcade US en reprenant le cycle des coffres de cette version qui offre 2 fois plus d’armures et 2 fois moins de sorciers quand on est en caleçon ce qui est une aide majeur pour le joueur. Et ils ont aussi reprit l’idée de baisser le nombre de PV des boss (moins de la moitié des PV originels) mais en l'étendant à tous les ennemis du jeu ce qui est un changement assez majeur aussi pour la difficulté. C’est unique à cette version.
Puis ils ont aussi fait des modifications de level design. En tout cas, j'ai au moins noté l’absence de l’obstacle en haut de la colline du segment 2-1. Un obstacle qui fait toute la difficulté de ce segment et qui a donc disparu dans le mode “practice” pour rendre ce segment moins punitif.
Ce mode “practice” Megadrive est donc un vrai mode easy contrairement aux divers modes de difficulté alternatif de l’arcade qu’on retrouve aussi dans les autres versions et qui consiste juste a modifier la cadence de progression du ranking.
Il y a un autre changement notable qui altère la difficulté de cette version Megadrive, mais qui cette fois concerne aussi bien le mode “practice” que “professional”. Une feature encore inspirée de la version arcade US et qu’on ne retrouve pas dans les autres versions: les checkpoint supplémentaires.
La version Megadrive n’a pas ajouté des checkpoints tous les 10 mètres comme la version arcade US mais ils ont gardé cette idée d’avoir un checkpoint devant chaque boss. C’est un avantage non négligeable car en plus de faire l'économie du trajet jusqu’au boss, ça offre aussi l’opportunité de faire les boss fight à bas rank, voir même au rank 1 si on meurt en boucle. Et avec un ranking verrouillé pendant le combat (grâce au délai offert à chaque début de run). Quelque chose qui n’est pas vraiment possible sans ces checkpoints a cause du trajet qui laisse le temps au rank d’augmenter (et de continuer à augmenter rapidement pendant le fight). Et combiné aux continus infinis, c’est un contexte parfait pour faire du training sur les boss.
Mais c’est aussi à double tranchant car ça implique qu’une fois au boss on ne peut plus changer d’arme. En terme de game design c’est plutôt une mauvaise idée même si, en général, on ne s'engage pas dans ces boss fight avec la mauvaise arme.
C’est le bon moment pour aborder le sujet des différentes versions Megadrive car il existe au moins 3 versions du jeu sur Megadrive. Il y a la version originale japonaise dans sa première édition à laquelle a succédé une version internationale (sans doute pour la sortie US) qui, a priori, fait aussi office de seconde édition pour le japon. Puis il y a une seconde version internationale (probablement pour la sortie européen) qui sert aussi de troisième édition japonaise, semble t’il.
Ces 2 ROMs internationales contiennent la version japonaise. De ce que j'ai pu constater en émulation, lorsque la ROM de ces versions internationales est insérée dans une console japonaise elle se comporte comme l’édition japonaise originale de 1989 (que ce soit l'écran titre, les menus, la difficulté, les checkpoints).
De ce fait, je vais considérer seulement 2 versions. D’un côté la version japonaise (que ce soit celle de l'édition originale ou celles inclus dans les ROMs internationales), et de l’autre, la version internationale (que ce soit la première ou la seconde). Et ce que j’ai décrit jusque là concernait seulement la version internationale qui, en réalité, est une version un peu simplifiée de la version japonaise comme souvent.
La première chose que l’on constate c’est que par défaut, la version japonaise est réglée sur le mode “professional” (et sans le mode “diagonale”) alors que c’est l’inverse sur la version internationale (mode “practice” par défaut + mode “diagonale”).
Ensuite le mode “practice” de cette version japonaise est un peu moins généreux. On retrouve les commodités du mode “practice” internationale mais la baisse des PV ennemis est bien moins significative. Par exemple, le premier boss dans sa version originale possède 22 PV, abaissé à 10 PV dans le "practice" internationale (et seulement 8 PV en arcade US) mais 15 PV pour le "practice" de la version japonaise. L'ogre-porc doté initialement de 6 PV, passe à 3 PV dans le "practice" internationale mais 5 PV dans le "practice" japonais. Les vautours initialement à 2 PV reste à 2 PV dans le "practice" japonais au lieu de tomber à 1 PV (one shot) dans le "practice" internationale ce qui n'est plus la même chose. On ressent beaucoup moins, voir pas, la baisse de PV sur ce "practice" japonais.
Et puis cette version japonaise originale n’a pas ces fameux checkpoint aux boss que ce soit en “practice” ou “professional”. En quelque sorte elle est plus proche de la version arcade japonaise, et donc de la version SuperGrafx et X68000 qui sont aussi des éditions purement japonaises, ce qui a du sens.
Une autre commodité présente dans toutes les versions Megadrive, et spécifique à celles-ci, consiste à proposer en option (ou par défaut sur la version inter) un mode de contrôle alternatif plus souple vis à vis du comportement des diagonales. Les diagonales “gauche-haut” et “droite-haut” sont alors interprétées comme des inputs “gauche” et “droite” plutôt que “haut” ce qui rend les déplacements un peu plus aisés. C’est donc censé simplifier les choses pour le joueur mais ça reste dispensable.
Comme pour la version SuperGrafx, j’ai pu noter aussi la présence de quelques bugs et différences dans le comportement du jeu.
J’ai déjà évoqué précédemment des problèmes plus globaux dans le traitement des collisions, dans le spawn des ennemis ou dans la RNG mais j’en ai observé d'autres plus ponctuels et spécifiques comme cette incapacité des Turtle-rock à tirer. Parfois quand j’arrive au stage 2 je constate que les tortues ont perdu leur capacité à cracher des bullets.
C’est un bug pas simple à tester et déclencher volontairement car il semble lié à la RNG. C’est comme si le bug dépendait d’une seed RNG sélectionnée en tout début de partie. La présence ou pas du bug semble être déterminé au lancement de la partie donc si il n’est pas présent une fois arrivé ici, il faut relancer une partie du tout début. A l’inverse, si il est présent, il le reste tout le temps même si vous mourez en boucle sur ce segment.
Et puis il dépend du type de tortue. Comme j’ai expliqué au chapitre 3 il y a deux types de tortue. Celle qui entre en scène en marchant et celle qui arrive par rebond (beaucoup plus rare). Leurs shots sont gérés différemment donc on peut avoir le bug pour l’un de ces deux types ou pour les deux.
En tout cas c’est un bug qui est à l'avantage du joueur donc pas gênant. Mais si c’est vraiment lié a la RNG, ca demanderait d’être creusé un peu plus. Il y a peut être un truc intéressant à comprendre derrière ça (car pour l’instant la raison m'échappe).
D’autant que j’ai constaté un autre bug qui ressemble un peu à celui ci. Ca concerne la capacité de tirer des mains géantes du segment 4-2. Ce n’est pas aussi binaire que les turtle-rock qui sont totalement incapable de tirer ou alors n’ont aucun problème. Dans le cas présent, ce que je constate c’est plutôt qu’elles vont parfois tirer une fois ou deux puis deviennent ensuite incapable de tirer de nouvelle bullet.
Encore une fois c’est à l’avantage du joueur donc pas gênant.
Il est possible que ce soit lié à l'absence de l’animation de transformation en slime. Comme je l'ai expliqué précédemment, cette version Megadrive a fait l’impasse sur cette animation pour économiser de la ROM. Une animation qui s'enclenche surtout quand le joueur est hors de la zone de trigger mais elle peut aussi s’enclencher n’importe quand, comme ici, sans que ca ne semble interférer avec ses mécaniques de tir.
Je soupçonne que ce changement d'état est toujours partiellement présent dans le code de la version Megadrive mais n’aurait juste pas de représentation visuelle. Peut-être qu’elle se trouve parfois bloquée dans cet état dû à des modifications du code pour retirer l’animation. Ca peut aussi être tout simplement un problème dans la gestion de la zone de trigger.
En tout cas, la version Megadrive utilise bien les même table de données que les autres versions. Notamment les 5 tables liées aux délais des tirs (celle liée au ranking et les 4 liées à la RNG). Donc l’erreur vient certainement du code.
En parlant d’animation manquante, j’ai observé un autre exemple dans cette même scène et qui a un impact direct sur le joueur (cette fois au désavantage de celui-ci).
Il y a une animation au sol qui annonce la sortie d’une chenille. Une courte animation qui permet de prévenir le joueur 40 frames avant et qui est absente de la version Megadrive.
Ça veut dire moins de temps pour réagir sur la version Megadrive (même si la chenille elle-même n’est pas immédiatement létale, il y a un petit délai de 30 frames ou elle est inoffensive). On retrouve d’ailleurs cette différence a l’identique avec les Skull-flower du stage 1 même si c’est moins gênant dans ce cas.
Ce segment 4-2 donne un aperçu de la difficulté pour comparer la version Megadrive avec les autres. On a ici plusieurs petites différences qui se cumulent. On peut ajouter aussi la plus grande facilité à passer sous les bullets dans cette version Megadrive que j’avais évoquée dans le paragraphe sur les hitbox et qui est bien utile sur ce type de passage.
La version Megadrive est extrêmement fidèle à la version arcade japonaise. C’est peut être 100 000 points strictement identiques pour quelques dizaines de différent mais ces quelques différences suffisent à rendre difficile les comparaisons de difficulté. Les comparaisons avec l’arcade sont beaucoup plus simple a faire avec la version SuperGrafx.
Je peux vous résumer brièvement les principaux éléments que j'ai exposé:
En ce qui concerne la difficulté des différentes versions, on peut distinguer deux groupes distinct:
Il y a le groupe Arcade US + Arcade World + Practice Megadrive.
Ce sont les versions qui ont choisi volontairement de s’éloigner de la version originale et sont en quelque sorte les véritables modes “easy” du jeu contrairement aux modes de difficulté alternatif des autres versions qui consiste juste à calibrer différemment le système de ranking sans modifier la difficulté intrinsèque.
La version la plus facile de toute étant le mode practice Megadrive international, parfait pour découvrir le jeu en détente, suivie par l’arcade US puis l’arcade World plus subtile dans ses modifications. Malgré tout, ça reste toujours des jeux qui demandent de la dextérité et de l'apprentissage.
L’autre groupe se compose de l’Arcade Japonais + X68000 + SuperGrafx + Professional Megadrive.
Ces versions partagent les mêmes données, les mêmes mécaniques et sont calibrées exactement de la même façon. On retrouve donc une difficulté très similaire (et élevée telle la version originale) qui rend compliqué et un peu hasardeux un classement plus fin. On peut retenir que toutes ces versions se valent.
Mais si vraiment on voulait faire un classement plus fin alors la version Megadrive serait la plus difficile à situer. Elle possède à la fois certaines contraintes supplémentaires comme le FoV réduit, et en même temps des commodités qui lui sont propre comme un système de contrôle alternatif ou des check point aux boss sur la version inter. Tout ça saupoudré d’un certain nombre de petits bugs ou lacunes (collision, spawn, rng, bullet, animation…) qui sont parfois favorables au joueur et parfois défavorables. Dans cette situation, la solution reste probablement de jouer beaucoup à toutes ces versions pour ensuite se fier à son ressenti même si il est vrai que, dans le cas de Ghouls’n Ghosts, il est délicat de s’y fier tant la RNG a une place importante.
La version SuperGrafx est plus simple à classer car vraiment très similaire à la version arcade japonaise tout en ajoutant des petites difficultés supplémentaires comme le FoV réduit ou le segment 3-1 à la difficulté clairement upgradé. On retrouve aussi l’opportunité, même si cachée, de pouvoir pousser la difficulté du ranking au max (niveau 8) comme en arcade.
Donc on peut au moins dire, sans trop se tromper, que c’est une version un peu plus difficile que la version arcade japonaise et, par ricochet, que la version X68000 (ainsi que les autres versions arcades forcément). En plus d'être la version la moins accueillante de toute en proposant par défaut aucun réglage de difficulté ni commodité et en se présentant comme l’unique version sans continu infini. A réserver aux joueurs qui ont déjà de l'expérience sur le jeu.
Mais cette analyse n’est pas exhaustive. Il est encore possible de découvrir d’autres différences, d’autres spécificités, d’autres bugs.
C’est valable pour le reste. Il y a encore plein de choses à analyser sur ce jeu comme je l’ai promis pour les hitbox et la RNG de la version Megadrive. Je n’ai même pas abordé le sujet de l’audio car je n’ai pas de chose très pertinente à dire et c’était déjà assez long. Je serai certainement amené dans le futur à mettre à jour ce billet car c’est un jeu que j’aime beaucoup. Je n’en ai pas fini ^^.