Thread by @upsilandre

Quelques constats en vrac sur Metroid après y avoir joué longuement. Ca va parler de problème d'input, de timer chaotique, de nuancier de PV et de duplicité du jump... THREAD ⬇️
#Retrogaming #NES #Metroid #Nintendo

Je commence directement par le truc qui fâche car je suis assez sensible aux problèmes d'input dans les jeux et Metroid n'y échappe pas malheureusement. Il a le droit à son petit bug d'input comme trop de jeux NES. Dommage.

Ça concerne le shot. Chaque fois qu’on presse ou relâche n'importe quel bouton (même les boutons de direction) pendant qu'on presse le bouton de tir alors ça enclenche un autre shot non voulu.

Par exemple ici je presse une seule fois le bouton de tir mais ça donne 3 shots successif car j'ai pressé "haut" (2ème shot) puis relâcher "haut" (3ème shot) avant de relâcher le bouton de tir.

Pour n'importe quel autre jeu ca serait un bug sans conséquence sauf que, pas de chance, l'un des éléments au cœur du gameplay de ce Metroid est la capacité à geler les ennemis mais pour ça il faut pouvoir faire des shots isolés. Un double shot va immédiatement dégeler l'ennemi.

Résultat on rate souvent nos freeze shot, c'est frustrant.
C'est d'autant plus étonnant d'avoir laissé passer ce bug car l'auto-fire du jeu a lui même été calibré pour permettre justement des shots isolés (il s'enclenche seulement si on maintient le tir plus de 32 frames).

Ça montre bien qu'ils avaient pourtant conscience de l'importance de pouvoir faire des shots isolés.
Mais ce bug offre à Metroid le firerate théorique le plus élevé que j'ai jamais observé (60 hz au lieu du max 30 hz habituel). Regardez ce triple shot en seulement 3 frames 😄.

Quand j'ai fait mon one life je voulais aussi la best ending (il y a 5 fins différentes dans Metroid) et pour cette raison je me suis intéressé au timer interne (et donc caché) du jeu car c'est lui qui décide quelle fin on obtient selon le temps que l'on met pour finir le jeu.

En regardant dans le code du jeu j'ai donc pu constater qu'il fallait le terminer en moins de 59mn04 pour avoir la meilleure fin. J'ai pu constaté aussi que le timer ne s'arrête pas lors des longues transitions de porte et d'ascenseur (j'avais espéré que... mais non 🤓).

Il s'arrête seulement pendant le freeze de quelques secondes lorsqu'on ramasse un item et quand on utilise la pause évidemment.
Mais j'ai surtout constaté un comportement chaotique du timer à cause d'une implémentation assez bancale. Je vous épargne les détails techniques.

Le timer va ralentir quand le jeu rame mais, en compensation, si il a le malheur de s'incrémenter sur une frame qui drop alors le timer va prendre 4 secondes d'un coup en une seule frame.
Quand on visualise le timer, ça donne ce comportement un peu aléatoire.

Ce chaos on le retrouve aussi chaque fois qu'on sort de la pause ou qu'on sort du freeze de récolte d'un item. A cet instant le timer peut gagner ou perdre entre 0 et 4 secondes d'un coup de façon aléatoire. une sorte de bonus/malus aléatoire.

Mais ce chaos dans le timer, de par sa nature aléatoire, se compense et s'annule statistiquement sur la durée de la partie. Au final on a bien environ 1 heure temps réel pour la best ending à 10 ou 20 secondes prêt.
Mon script pour afficher le countdown:
drive.google.com/file/d/16qFcba…

Une autre curiosité qui m'a interpellé concerne les PV. L'affichage des PV dans le HUD de Metroid est déjà plus précis que dans la plupart des jeux. Un affichage à 2 chiffres (0 à 99) plutôt que par segment. Mais en réalité en interne les PV sont stockés sur 4 chiffres (base 10).

Car il y a aussi les centaines, représenté dans le HUD par les E-Tank, mais aussi une partie décimale (non affichée) pour une précision au 1/10ème de PV.
Les PV ont donc un range qui s'étend sur 7000 valeurs entre 0 et 699,9. Une amplitude et précision rare pour un jeu d'action.

A ma connaissance cette précision décimale est utilisée seulement quand on marche dans la lave ou que l'on se fait pomper par les Metroids. Par exemple, dans la lave on perd 1,4 PV toutes les 8 frames mais seulement 0,3 quand on a la Varia Suit (qui est donc vraiment très utile).

D'ailleurs pour récupérer la Varia Suit rapidement sans devoir récupérer le Super Jump il y a ce trick sympa avec le freeze beam. Il faut juste avoir la bonne pattern ennemi quand on entre dans la room (il faut qu'il soit orienté vers la gauche).

J'en profite aussi pour détailler le fonctionnement des barrières qui protègent Mother Brain. Pour les détruire il faut les toucher 8 fois avec les missiles. Mais attention si on attend plus de 64 frames (~1 seconde) entre 2 hits alors elles se régénèrent et regagnent 1 hit.

Pour terminer j'ai envie de pointer un élément singulier du gameplay dont on parle peu.
La duplicité du saut de Samus. Selon que l'on presse une direction juste avant ou juste après avoir pressé le jump, ça enclenche un saut aux caractéristiques sensiblement différentes.

Suffit d'une seule frame de différence pour enclencher l'un ou l'autre.
Quand on presse la direction après le saut on obtient un saut avec une vélocité horizontale plus faible (1 ppf) mais surtout un air-contrôle total sans aucune inertie horizontale. Parfait pour le platforming.

A l'inverse, quand on presse la direction juste avant le jump alors Samus enclenche son spin (et la Screw attaque si on la possède). La vélocité horizontale est plus élevée (1.3 ppf) et donc le saut plus long. Mais on perd beaucoup en air-contrôle horizontal.

On ne peut plus stopper ni ralentir le mouvement horizontal (Vmax), on peut seulement l'inverser comme dans Contra ou TMNT.
C'est donc 2 sauts vraiment différents. Il est nécessaire de comprendre et maîtriser cette subtilité dans Metroid (qu'on retrouve aussi dans Super Metroid).

Il y a aussi des différences sur la gestion du tir vers le haut selon le type de saut.
Mais dans tous les cas, le saut de Samus n'a aucune inertie verticale. Elle retombe instantanément quand on relâche le bouton. Ça aussi c'est pas si courant.

Tous les autres threads sur le compte d'archive:
twitter.com/UpsilandreA