La Nintendo Entertainment System et son homologue japonaise, la Famicom, n’ont plus besoin d’être présentées. Si vous lisez ce magazine, vous savez que le matériel 8 bits a catapulté Nintendo à une position de leader mondial dans le secteur des jeux vidéo et a accueilli les premières itérations d’innombrables séries classiques.
Bien que le marketing ait joué un rôle important dans ce succès commercial et culturel, il n’aurait pas été possible sans le matériel. Après tout, la ColecoVision et l’Atari 5200 avaient moins d’un an lorsque la Famicom a été lancée au Japon en 1983, et la 3DO et l’Atari Jaguar étaient déjà sur le marché lorsque les développeurs ont finalement abandonné la NES en 1994. Une machine ne peut tout simplement pas rester pertinente aussi longtemps si elle ne dispose pas d’un matériel suffisamment souple et performant pour suivre l’évolution des goûts des joueurs.
Un nouveau terrain
(Crédit photo : Evan Amos)Abonnez-vous dès aujourd’hui
(Crédit photo : Future)
Cet article a été publié pour la première fois dans le magazine Retro Gamer. Pour des articles plus approfondis sur les jeux et les consoles classiques, livrés directement à votre porte ou sur votre appareil, abonnez-vous à Retro Gamer en version imprimée ou numérique.
Mais la NES n’était pas seulement un titan de son époque : de nombreux développeurs créent de nouveaux jeux pour ce matériel, en le poussant plus loin que jamais avec des outils de développement modernes. Deux processeurs et leurs dérivés ont dominé la scène du matériel domestique dans les années 80 : le Zilog Z80, qui équipait le ZX Spectrum, la ColecoVision et la Master System, et le MOS Technology 6502, qui équipait l’Atari 5200, l’Apple II et le Commodore 64. Masayuki Uemura, ingénieur chez Nintendo, a opté pour le 6502 pour la NES, principalement parce qu’il était suffisamment petit pour qu’une puce puisse également inclure des capacités sonores.
En 2016, l’ingénieur décédé a déclaré à Retro Gamer que ce choix avait causé « un énorme problème au sein de l’entreprise », car le jeu d’arcade à succès Donkey Kong de Nintendo utilisait un Z80 et le code source ne pouvait pas être réutilisé. La prise en compte des programmeurs extérieurs à Nintendo n’était pas une priorité, car la société n’avait pas l’intention, à l’origine, d’intégrer des éditeurs tiers dans son modèle économique. Bien entendu, le succès de la console au Japon et en Amérique du Nord a fini par nécessiter le développement de logiciels tiers pour répondre à la demande de nouveaux jeux.
La console n’a pas eu le même impact au Royaume-Uni, c’est pourquoi le programmeur Paul Machacek n’en a pas rencontré avant 1988, lorsqu’il a rejoint Rare, l’un des rares développeurs britanniques à se concentrer sur la console de Nintendo. Les jeux qu’il avait précédemment publiés avaient été écrits pour des ordinateurs basés sur le Z80, et il a d’abord été chargé d’écrire pour la carte d’arcade RAZZ basée sur le Z80, mais on lui a rapidement demandé de travailler sur un projet NES. Heureusement, Paul connaissait le code assembleur 6502 depuis qu’il était propriétaire d’un Oric-1. « J’ai repris le code assez rapidement », dit-il, « mais j’ai oublié toutes les jongleries de chiffres que l’on y faisait par rapport au Z80, car le 6502 a si peu de registres, mais il a aussi le stockage rapide en zéro page. »
Développez ce que nous avons fait avec les outils dont nous disposions sur les systèmes que nous utilisions et dites-moi que vous ne finirez pas par faire quelque chose de similaire.
Paul Machacek
L’environnement de développement avec lequel Paul travaillait était plutôt basique. « À l’origine, chez Rare, tout le monde utilisait PDS (Programmers Development System), un éditeur de texte et un assembleur de code. Nous avions des cartes d’interface maison qui s’inséraient dans la fente de la cartouche de la NES et qui étaient reliées par un câble plat à nos PC sur lesquels tournait PDS », explique-t-il. « Nous n’avions pas de réseau. Les PC étaient des Amstrads avec des disques durs de 20 Mo (ce n’est pas une faute de frappe). Chaque fois que vous assembliez votre code – cela se faisait en une seule fois, nous n’avions pas encore d’éditeur de liens – le binaire complet était copié sur le câble ruban vers la carte d’interface et vous exécutiez votre code sur la machine cible. En ce qui concerne la documentation, nous avions juste le manuel standard de la NES, qui contenait quelques fautes de frappe qu’il fallait corriger sinon les choses ne fonctionnaient pas, et aussi votre guide pratique du jeu d’instructions 6502 pour une référence occasionnelle, en particulier si vous vouliez écrire un code auto-modifiant ».
Si vous êtes un programmeur et que vous grimacez en entendant cela, il y a pire. « Il n’y avait pas d’outils de débogage tels que vous les connaissez aujourd’hui », poursuit Paul. Il y avait des astuces pour savoir où se trouvait votre code avant que les choses ne tournent mal, comme écrire des valeurs dans un emplacement mémoire et voir laquelle a été écrite en dernier avant le plantage, puis utiliser une recherche par bissectrice pour trouver le code en cause. Pour tester les performances, vous aviez normalement un changement visuel à l’écran (décalage d’un registre de défilement horizontal ou modification d’une palette de couleurs) au début d’une fonction, puis vous le réinitialisiez à la fin pour pouvoir « mesurer » le temps que cela prenait à l’écran en traçant des marques avec des marqueurs autour de cet indicateur visible, et voir si les marques se rapprochaient au fur et à mesure que vous continuiez à optimiser votre code. Oui, mesdames et messieurs, c’était l’époque où l’on mesurait les performances d’un code en pouces ! »
Cette façon de travailler semble assez bizarre, mais Paul la considère comme un produit des circonstances de l’époque. « Revenez 35 ans en arrière, développez ce que nous faisions avec les outils dont nous disposions sur les systèmes que nous utilisions et dites-moi que vous ne finirez pas par faire quelque chose de similaire ! Heureusement, la situation a fini par s’améliorer pour Paul et ses collègues. « Après quelques années, Rare a demandé à Jon Ritman, un de ses proches collaborateurs, d’écrire un nouveau système appelé GLAM [Global Language Assembler Monitor] pour remplacer PDS. GLAM pouvait cibler une plus grande variété de processeurs et disposait d’un linker ainsi que d’un assembleur, de sorte que vous n’aviez pas à assembler toute votre base de code à chaque fois que vous changiez quelque chose, ce qui accélérait le développement. GLAM a très bien fonctionné. »
(Crédit photo : Nintendo)
En fin de compte, la programmation en 6502 n’a pas été un gros problème pour Paul lors de la transition vers une nouvelle plate-forme. « Pour moi, l’ajustement le plus important a été de passer d’ordinateurs domestiques avec des écrans en mode bit-map au système en mode character-map de la NES, avec des désignations de palette de couleurs séparées, des banques de caractères (et leur permutation) et la permutation des banques de mémoire sur les chariots », se souvient-il. L’unité de traitement d’images de Nintendo – PPU en abrégé – a été conçue sur mesure par Ricoh et, selon Nicolas BÉtoux de Morphcat Games, « par rapport à d’autres matériels de l’époque, les graphismes et les capacités de défilement étaient excellents ».
En effet, lorsque la Famicom a été lancée en 1983, son concurrent le plus proche au Japon était le SG-1000 de Sega. Les capacités graphiques de la Famicom étaient nettement supérieures : elle disposait d’une palette de plus de 50 couleurs, contre seulement 16 sur la console de Sega, les sprites pouvaient avoir trois couleurs chacun, contre une seule, et les écrans pouvaient défiler par pixel plutôt que par personnage, ce qui donnait un aspect considérablement plus fluide. Le matériel de Nintendo pouvait également afficher plus de sprites en général et plus de sprites par ligne de balayage. Sega a introduit le matériel Mark III, graphiquement supérieur, en 1985, ce qui signifie que la concurrence était plus équitable au moment où la NES et la Master System sont arrivées sur le marché international.
Les outils du métier
Si le matériel 8 bits de Nintendo possédait des capacités graphiques avancées, les méthodes utilisées pour créer ces graphismes étaient tout sauf perfectionnées. Comme Paul, l’artiste Kevin Bayliss n’avait jamais vu de NES avant de créer des jeux pour la console. Lors de mon premier jour chez Rare, Tim [Stamper] m’a montré le « processus de pixellisation » de base et m’a appris à créer un travail qui pourrait être intégré à un jeu », raconte-t-il.
« Je devais dessiner mon œuvre et la placer sous une grille sur une grande planche à dessin remplie de bandes fluorescentes. J’ai ensuite tracé mon dessin en utilisant la grille pour définir les pixels avec un crayon, puis j’ai utilisé des feutres pour remplir les pixels. Ensuite, le travail devait être organisé et divisé en boîtes (sprites 8×8) et les données du sprite et les données de position devaient être calculées en hexadécimal, dans ma tête. C’était assez facile, mais parfois un peu laborieux, et souvent vous ne vouliez pas faire ce travail parce qu’il n’était pas du tout créatif. Vous vouliez juste voir votre travail dans le jeu. »
Si l’absence d’ordinateur dans ce processus vous laisse perplexe, c’est que vous n’avez rien compris. « Il n’y avait pas d’autres outils que le stylo, le crayon, le papier et un scalpel chirurgical pour gribouiller vos erreurs sur le papier calque lorsque vous mettiez un pixel au mauvais endroit ou que vous vouliez couper des pixels d’un personnage pour lui permettre de tenir dans moins de données », précise Kevin. « Il existait un éditeur de sprites simple écrit par Mark Betteridge, mais il n’était pas vraiment utilisé car il était très limité et ne vous permettait pas de visualiser votre animation (comme ils le font dans toutes les vieilles séquences ‘en coulisses’ de Disney – en retournant votre papier d’avant en arrière pour créer l’illusion de l’animation) ».
Il n’y avait pas d’autres outils que le stylo, le crayon, le papier et le scalpel chirurgical pour gribouiller vos erreurs.
Kevin Bayliss
Comme les outils de développement de la NES n’étaient pas standardisés, différentes sociétés utilisaient une variété d’outils artistiques. Nintendo a utilisé des sprites dessinés à la main à un moment donné, mais a fini par créer un outil de pixellisation piloté par la souris, tandis que Namco disposait d’un outil d’édition de sprites doté de la fonction de prévisualisation de l’animation décrite par Kevin. Cependant, il a apprécié l’approche peu technologique employée par Rare.
« Je veux dire par là que vous n’auriez jamais pu dessiner tous vos graphismes sur papier pour une console 16 bits, car vous n’auriez jamais eu assez de crayons, et il vous aurait fallu toute une journée pour les décoder – et vous auriez fait tellement d’erreurs – que cela aurait été impossible », explique-t-il. Mais en raison de la simplicité de la palette de couleurs, de la faible résolution et du petit nombre de sprites que nous utilisions le plus souvent, créer des graphismes sur papier était en fait assez amusant et semblait beaucoup plus « organique » que de les créer numériquement sur la SNES, donc je suppose qu’il y a quelque chose à dire à ce sujet.
Quelle que soit la manière dont un développeur créait des graphismes pour la NES, les limitations techniques jouaient un rôle dans les résultats finaux. « Les sprites par ligne (plus de 64 pixels remplis sur une ligne de balayage horizontale) posaient problème et il fallait donc essayer de ne pas rendre les personnages très larges », explique Kevin. Par exemple, je me souviens que tous les personnages des jeux WWF que j’ai créés devaient soit « tomber en arrière », soit « s’allonger sur le sol », ce qui signifiait évidemment qu’ils étaient assez larges dans cette position. On essayait donc souvent de les incliner ou d’être astucieux avec la pose, mais on ne pouvait jamais vraiment l’éviter. Vous pouvez voir comment les personnages clignotent souvent, en particulier dans les jeux de type « beat-’em-up », et c’était un problème auquel toutes les sociétés devaient faire face du mieux qu’elles le pouvaient.
Ce scintillement caractéristique est en fait une solution de programmation astucieuse : la NES sautait simplement des pixels si trop de sprites étaient affichés, de sorte que l’allumage et l’extinction rapides des sprites garantissaient au moins qu’ils seraient tous affichés sous une forme ou une autre.
(Crédit photo : Nintendo)
En fait, les développeurs NES ont souvent dû faire preuve de créativité pour concrétiser leurs idées, comme les énormes boss que Kevin a dessinés pour Cobra Triangle. « Avec Cobra Triangle, nous avons eu de la chance car le jeu se déroulait dans un environnement isométrique. Tous les graphismes étaient donc vus sous un angle qui réduisait la largeur que l’on voit normalement dans un jeu à défilement horizontal », explique-t-il.
« Par exemple, le monstre marin (Nessie) que j’ai créé était assez grand, et les bosses derrière lui se déplaçaient indépendamment, et en raison de l’angle, il n’y avait pas beaucoup de scintillement des sprites ».
Les limitations sont devenues plus difficiles à gérer lors du développement de jeux sous licence, comme Rare l’a souvent fait. Pour les jeux de lutte WWF, nous devions nous assurer que les personnages étaient bien ressemblants. Il était donc difficile de « numériser » les photos à la main et de reproduire les caractéristiques de chacun avec précision lorsque vous ne disposiez que d’environ 16×16 pixels pour la photo d’un personnage sur la page de sélection », explique Kevin. « Je me souviens avoir reçu des fax d’une qualité épouvantable sur lesquels figuraient les photos des catcheurs et je devais essayer de les recréer en utilisant une résolution aussi faible et trois couleurs.
Cela a tout de même donné lieu à quelques expériences amusantes. « Souvent, je recevais des fax d’Amérique me disant que le graphisme avait besoin d’un peu d’attention, parce que la ressemblance n’était pas assez forte », poursuit Kevin. « Je changeais alors un pixel et je recevais un fax le lendemain me disant que l’image était bien meilleure. Cela me faisait vraiment rire. De même, lorsque j’ai travaillé sur le jeu Beetlejuice, j’ai eu le problème inverse : ma page de titre ressemblait trop à Michael Keaton, apparemment, et j’ai dû la refaire pour qu’elle ressemble davantage à Beetlejuice – ce qui n’est pas évident lorsqu’il s’agit de la même personne.
Des nuances entre les deux
Parfois, il était possible de pousser le système au-delà de ses limites théoriques. « Si vous regardez Super Off Road, vous remarquerez qu’il y a parfois plus de couleurs à l’écran que ce que le matériel peut gérer en standard », explique Paul. « Il y avait quatre palettes de quatre couleurs chacune, mais la première couleur de chaque palette était la même couleur d’arrière-plan pour tous. Le nombre total de couleurs que vous pouviez afficher pour les personnages d’arrière-plan était donc de 13. Il y en a plus sur Super Off Road parce que j’ai changé les palettes en accédant à la VRAM de manière soigneusement chronométrée pendant le blanking horizontal. Cela a bien fonctionné », explique Paul, avant de se corriger. « Eh bien, c’était le cas sur la version américaine de la NES.
Lorsque le jeu a été terminé, on m’a informé qu’il sortirait au Japon sur la Famicom, qui était légèrement différente en termes de matériel et, malheureusement, ma commutation de couleurs ne fonctionnait pas sur cette console, donc je crois qu’il n’est pas sorti là-bas. »L’audio était géré par la même puce Ricoh 2A03 que l’unité centrale : « Sur le NES, vous disposez de quatre canaux audio. Nous ne comptons pas le canal DPCM (échantillon), nous ne l’utilisons pas car il présente certains inconvénients », explique Nicolas, un développeur de jeux NES modernes.
« Quoi qu’il en soit, cela représente deux générateurs d’ondes carrées, une onde triangulaire souvent utilisée pour les lignes de basse et un canal de bruitage utilisé pour les sons percussifs. Comme vous le voyez, les options de polyphonie et de timbre sont limitées, ce qui rend difficile la création d’une bande sonore plus atmosphérique comme celle que l’on peut entendre dans les jeux modernes. C’est probablement l’une des raisons pour lesquelles de nombreuses bandes sonores de jeux de l’époque compensaient ce manque par des compositions dynamiques et des mélodies entraînantes. »
(Crédit photo : Nintendo)
Le son de la NES présente des caractéristiques particulières, notamment les ondes triangulaires qui sont en escalier plutôt que lisses, en raison du traitement du son 4 bits de la console. « En raison du nombre limité de canaux, vous devez également être conscient que les effets sonores peuvent interrompre la musique », ajoute Nicolas. « Idéalement, les effets sonores ne doivent être joués que sur les canaux utilisés pour l’accompagnement, afin qu’ils n’étouffent pas la mélodie.
Le son est également l’un des points de différenciation entre la Famicom et la NES, car la Famicom prend en charge l’audio étendu via le port de la cartouche, ce dont profitent le Famicom Disk System et certaines puces de cartouche spéciales. Comme la NES ne dispose pas de cette capacité, les versions japonaises de jeux tels que The Legend Of Zelda et Castlevania III : Dracula’s Curse ont une musique nettement meilleure que leurs équivalents internationaux. En effet, ce sont les puces spéciales qui ont été l’un des facteurs clés de la longévité de la NES. En plus de prendre en charge à la fois la mémoire morte et la mémoire vive sur les circuits imprimés des cartouches, la NES pouvait utiliser des puces que Nintendo appelait « contrôleurs de gestion de la mémoire ».
Ces puces permettaient non seulement de changer de banque en dépassant les limites de stockage de la spécification originale des cartouches, mais aussi de fournir des fonctions supplémentaires pour aider au développement des jeux, et même des extensions audio pour la Famicom. C’est ainsi que le système a pu passer de jeux comme Donkey Kong à des titres beaucoup plus complexes comme Kirby’s Adventure en l’espace d’une décennie. Bien entendu, même si la capacité de la mémoire morte dépassait largement le total initial de 40 Ko, les développeurs se battaient souvent pour chaque octet. « À l’époque, l’un des problèmes les plus courants était d’essayer de faire tenir les jeux sur les minuscules cartouches que l’on nous donnait », explique Paul. « Sur les NES/Game Boy (deux systèmes 8 bits avec des cartes mémoire de 64 Ko), cela s’est compliqué avec la commutation de banques, la région pouvant être divisée en quatre blocs de 16 Ko, dans lesquels vous pouviez faire entrer et sortir différentes banques de ROM.
Vous deviez donc organiser avec soin l’emplacement du code et des données et la manière de passer d’une banque de ROM à une autre dans le même espace d’adressage, en utilisant des tables de saut superposées standard au début de l’espace. Nous avons également dû développer des routines de compression de données, souvent différentes pour différents types de données – données de caractères, données de cartes, données de texte, données musicales. La compression Huffman était très utilisée, mais j’ai passé du temps à regarder des impressions d’autres types de données, à la recherche de modèles que je pourrais utiliser pour développer des logiciels de compression. »
8-bitten
James ne tarit pas non plus d’éloges sur le logiciel : « La communauté est formidable et les ressources pour utiliser les applications de tracker sont accessibles à tous, que vous soyez un compositeur expérimenté ou un simple amateur de chiptunes. » Avec ces outils modernes à leur disposition, les développeurs NES d’aujourd’hui ont tendance à tenter des projets très ambitieux. Les jeux d’action à quatre joueurs sont rares sur la NES, mais Morphcat Games en a créé un excellent avec Micro Mages. Cela a nécessité une utilisation très économique du matériel.
« Le NES permet d’avoir un maximum de 64 sprites matériels à l’écran à tout moment », commence Nicolas. « Ces sprites ont une taille de 8×8 pixels (il existe un mode 8×16, mais il présente des inconvénients) et peuvent être assemblés pour former des sprites plus grands. Ainsi, pour obtenir un sprite 16×16 dans le premier mode, vous devrez utiliser quatre sprites matériels. Si les quatre joueurs utilisent des sprites 16×16, cela représente un quart de tous les sprites matériels disponibles pour les joueurs ! De plus, il existe une limitation matérielle qui fait que si plus de huit sprites se trouvent sur la même ligne horizontale, ils commencent à disparaître », poursuit-il, « Pour remédier à ce problème tout en permettant l’utilisation de nombreux autres objets et effets graphiques à l’écran, les personnages-joueurs de Micro Mages utilisent un seul sprite 8×8 chacun ». »
Le processeur 8 bits s’avère également être un facteur limitant, selon Nicolas. « Si un jeu a un ennemi qui ne se déplace que latéralement et se retourne lorsqu’il rencontre un mur, le nombre de vérifications à effectuer est limité. Les joueurs humains, en revanche, sont des jokers, ils interagissent avec tout ce qui les entoure d’une manière que le développeur ne peut pas entièrement prévoir.
(Crédit photo : Nintendo)
J’ai adoré coder la NES, c’était une architecture complètement différente des ordinateurs domestiques sur lesquels j’avais travaillé auparavant.
Paul Machacek
De plus, si les joueurs ont la possibilité de tirer, le nombre d’objets à l’écran augmente rapidement », explique-t-il, « ce n’est pas un problème dans un jeu à un joueur et on peut généralement s’en sortir dans un jeu à deux joueurs. Mais dans un jeu à quatre joueurs ? Ouch. Dans Micro Mages, nous avons consacré beaucoup de temps à l’optimisation pour éviter les décalages. Cependant, en mode quatre joueurs, il arrive que le jeu ralentisse lorsqu’il y a trop de choses à faire. »
L’un des avantages dont disposent les développeurs modernes est la possibilité de choisir parmi un large éventail de solutions de gestion de la mémoire, plus communément appelées « mappers » de nos jours. « Elles sont tellement intéressantes à décortiquer et à développer », explique James. Bien qu’ils soient les plus puissants disponibles, ils ne sont pas toujours le choix par défaut. « Lorsqu’un jeu est planifié pour le développement chez Mega Cat, nous commençons à travailler à rebours à partir de ce qui est nécessaire pour que le gameplay de base soit amusant », explique James. « Dans certains cas, nous finissons par choisir par défaut quelque chose de puissant comme le mappeur MMC3. Dans d’autres, nous pouvons rester simples et utiliser un mappeur discret, comme un NROM. » En effet, le récent jeu NES Blazing Rangers du développeur japonais Karu_gamo a spécifiquement utilisé le mappeur le plus simple, le NROM, pour évoquer la nostalgie des premiers jours de la Famicom. C’est vraiment le cœur de la fascination permanente des développeurs pour la NES – il s’agit non seulement d’un système techniquement intéressant, mais aussi d’un système qui exerce une forte attraction nostalgique.
Même ceux qui l’ont rencontrée pour la première fois dans le cadre de leur travail, comme Kevin, ressentent cette nostalgie. « Qu’il s’agisse de créer des arrière-plans, des sprites animés, des pages de titre ou des graphiques frontaux (tableau d’affichage), vous disposiez d’un système que vous aviez utilisé pour un jeu précédent et, à l’occasion, vous trouviez quelque chose de nouveau pour le pousser un peu plus loin et en tirer un peu plus sur le plan visuel. C’était une époque simple, mais amusante !
Bien que Paul déplore la jonglerie de chiffres inhérente à la programmation pour le 6502, il se souvient également du système avec affection. J’ai adoré coder pour la NES, c’était une architecture complètement différente des ordinateurs domestiques sur lesquels j’avais travaillé auparavant, il y avait des astuces intéressantes à jouer avec l’écran à mappage de caractères que vous pouviez exploiter pour donner de la profondeur – allez voir nos jeux Battletoads sur NES/Game Boy – et je considérais tout cela comme un défi technique intéressant pour « résoudre » de nouveaux problèmes autour de cette architecture matérielle alternative ».
L’avenir du passé
Malgré tout le plaisir qu’il y a eu à programmer le système, Paul considère à juste titre les résultats de ce travail comme la raison du succès de la NES. « Il ne faut pas oublier que Nintendo disposait d’un incroyable catalogue de jeux sur ces consoles, notamment Super Mario et Zelda. Super Mario Bros 3 a constitué un énorme pas en avant et un sommet absolu à l’époque », déclare-t-il.
Si vous êtes un créateur de jeux rétro en herbe, la NES pourrait bien être la plate-forme idéale pour vous. « Le code, les graphismes et le son de la NES sont faciles à gérer par une seule personne dans l’équipe », explique Nicolas. « Par rapport à aujourd’hui, le langage de programmation semble plus obscur et plus complexe que les langages modernes. Toutes les limitations vous poussent à passer plus de temps pour tout », admet-il. « Mais cela vous oblige également à réfléchir à deux fois à chaque idée. Au final, vous pouvez vous concentrer sur les plus importantes pour le gameplay.
Ces limitations permettent de contrôler l’étendue de votre jeu – il y a des limites à ce que vous pouvez faire. »Si vous vous sentez attiré par l’idée de relever ce défi technique, montrez-nous les résultats un jour – nous serons toujours intéressés de les voir.
Cet article a été publié à l’origine dans le magazine Retro Gamer. Pour découvrir d’autres articles et interviews fantastiques, vous pouvez vous abonner à Retro Gamer en version imprimée ou numérique ici.