[Fanboy Inside n°122] ChoRenSha68k, interview Shmuplation traduite en Français !

Tranches de passions surtout rétro et surtout gaming, mais pas que. Alias "FBI" - si les fédéraux débarquent, c'est Yace qui a fait le coup.
Répondre
Avatar de l’utilisateur
psychogore
1 crédit c'est déjà trop
Messages : 2365
Inscription : 23 mai 2003, 08:04

ChoRenSha68k est mon Doujin préféré. J'ai aimé ce jeu dès que j'y ai joué. Pourquoi ? Je ne saurais dire, si c'est le gameplay, simple et efficace, la bande son parfaite, la sensation que je peux toujours esquiver, même quand je remarque une boulette au dernier moment, les clin d’œils à tous les classiques du genre à l’écran des scores... C'est un tout.

Il y a quelques temps, j'ai vu une interview de Yoshin, l'auteur du jeu, traduite en anglais sur le site de Shmuplation. Elle contenait tellement d'infos précieuses sur la démarche du développeur que je me suis mis en tête de la traduire en Français pour la partager avec un maximum de monde ici.

Apres relecture et correction par Cormano, la voici enfin :

____________________________________________________________________________________________________________________________


Notes de développement de ChoRenSha68k

Publiées à l'origine par Yoshin sur sa page perso.

Image

1993
Création d'une bibliothèque basique de code pour le X68000

1995
Diffusion de ChoRenSha68k v.010, vendu comme doujin au Comiket

1998
Sortie de ChoRenSha68k v1.00

2001
Portage Windows terminé, diffusé au public comme freeware


Contexte du développement


La vente de doujins au Comiket
ChoRenSha68k fut d'abord vendu comme doujin au Comiket. À l'époque, le Comiket se tenait sur la jetée d'Harumi. On y voyait peu de systèmes Windows ; à la place, on trouvait tout un tas d'ordinateurs japonais des générations précédentes. Le X68000 avait commencé à prendre d'assaut le Comiket à la fin des années 90. Pour distribuer nos jeux, nous utilisions toujours des disquettes d'1 Mo au lieu de CD.

Obtenir des retours de développement de la part des utilisateurs BBS de Kusa no Ne
À cette époque, Internet n'était pas encore très répandu. Sur le système BBS Kusa no Ne, chaque forum était régi par des volontaires. Vous deviez vous connecter directement à la ligne personnelle d'un administrateur avec un modem pour écrire ou lire un message là-bas. C'était un système très primitif. Il y avait une communauté très active qui échangeait des informations sur le développement de jeux. J'ai pu recevoir beaucoup de retours sur le développement de ChoRenSha68k.

La série Sharp 68k
ChoRenSha68k fut d'abord développé pour les Sharp X68000. Cet ordinateur japonais sorti en 1986 était, grossièrement, un hardware Capcom CPS-1 avec un clavier, ce qui explique qu'il ait reçu de nombreux portages directs de jeux d'arcade. Il était adoré par les joueurs arcade de l'époque.
Lorsque le X68000 arriva en fin d'exploitation, de plus en plus de guides sur ses spécifications internes furent publiés, ce qui galvanisa la scène doujin et freeware x68k.

Dans les salles d'arcade
Alors que le boom des shmups horizontaux initié par Gradius et R-Type s'épuisait, il y a eu une nouvelle vague de shmups verticaux qui étaient les précurseurs de ce que nous appelons aujourd'hui "Danmaku".
Toutefois, à cause de la mode des jeux de baston, et parce que les shmups se tournaient de plus en plus vers les puristes et les experts, le genre était en train de mourir à petit feu. Le studio phare Toaplan avait fait faillite, IREM avait suspendu sa production de shmups et Konami prenait ses distances avec le genre pour mieux rediriger son activité dans le fan-service moe après l'énorme succès de Tokimeki Memorial.


Réflexions sur le Game design


Influences pour ChoRenSha68k
ChoRenSha68k fut grandement influencé par les shmups installés dans les salles d'arcade de l'époque. Batsugun (Toaplan 1993), Tatsujin Oh (Toaplan 1992) et Battle Garegga (Raizing 1996) eurent la plus grosse influence.
Ici, je vais revenir sur les idées particulières que j'ai eues (et leur implémentation) au sujet de ChoRenSha68k, ainsi que sur les idées générales de design que j'ai eues à l'époque.

Équilibrer la puissance du tir du joueur
Au niveau de puissance max, le tir du joueur apparaît 4 fois plus puissant qu'au départ. Cependant, les véritables dégâts sont seulement multipliés par 1,375.
Si j'avais quadruplé les dégâts réels pour correspondre à l'apparence du tir à puissance max, ça aurait complètement cassé le jeu. La débauche visuelle et l'équilibrage du jeu sont deux choses différentes. Ce genre de réglage minutieux est quelque chose que j'ai appris des vieux jeux Toaplan.

La largeur du tir du joueur
Beaucoup de shmups utilisés en salle d'arcade à l'époque avaient un tir qui s'élargissait à chaque montée en puissance. Ce genre de système rend l'équilibrage du jeu très dur à ajuster. Des jeux avec un tir fixé comme Star Force (Tecmo 1984), Vulgus (Capcom 1984), et 1942 (Capcom 1984) avaient un équilibre que l'on ne voit plus dans les jeux plus récents qui disposent d'un tir à largeur variable.

Image
Star Force, une influence majeure.

Pour ChoRenSha68k, j'ai tiré une leçon de Star Force et fait un tir à largeur fixe. Mais comme je voulais aussi un tir moderne et attrayant visuellement, je lui ai donné un effet de dispersion sympa. Le problème que j'ai ensuite rencontré fut quelle largeur exacte donner à ce tir. Si vous faites un tir trop large, alors il n'y a même plus besoin de bouger le vaisseau ; s'il est trop lent, le jeu semble mort. La largeur qu'on trouve dans le jeu est le résultat d'une longue recherche d'un bon compromis. En plus de tout ça, j'ai augmenté la densité du tir au milieu et je l'ai baissée sur les côtés, ce qui fait que le joueur doit attaquer les ennemis de face. Je suivais le modèle de Star Force.


Le tir à bout portant
Les vieux shmups utilisaient fréquemment la technique du tir à bout portant, où vous vous rapprochiez beaucoup d'un ennemi pour faire plus de dégâts. Cela donnait à ces jeux un certain tempo et une certaine allure que je voulais absolument recréer dans ChoRenSha68k.
Dans les vieux shmups, les principales incitations au tir à bout portant sont les suivantes :

Les limitations logicielles du nombre de boulettes
Les processeurs à l'époque n'étaient pas très puissants, la RAM très limitée et il y avait une limite au nombre de tirs qui pouvaient être affichés à l'écran. À cause de ça, il arrivait dans certains jeux que, si vous tiriez trop de tirs trop vite, vous atteigniez cette limite et étiez incapable de tirer avant qu'un de vos tirs précédents n'ait quitté l'écran. Ce phénomène courant était appelé "dan kire" (traduisible par "interruption du tir").
En tirant à bout portant sur un ennemi, le nombre de tirs affichés est réduit, ce qui permet de tirer rapidement. L'exemple classique est le début de la série Gradius, qui limitait systématiquement le joueur à seulement deux tirs à l'écran.

Le tir large
Quand le tir du joueur est élargi, vous pouvez faire des dégâts monstrueux si vous arrivez à concentrer tous les projectiles sur un seul ennemi. Cela amène à un style de jeu qui nécessite de tirer à bout portant. Le tir bleu de Same! Same! Same! est un exemple parmi tant d'autres.

La portée réduite
Avoir un tir à courte portée vous oblige à vous rapprocher des ennemis pour les toucher. Des exemples seraient Tiger Heli, Omega Fighter, le tir de base de Slap Fight, le napalm de Tatsujin Oh.

Cependant, les 3 mécaniques citées allaient toutes à l'encontre de ce que j'avais en tête pour ChoRenSha68k. En premier lieu, je ne souhaitais pas reproduire l'effet "dan kire". Je voulais également un équilibrage du jeu à la Star Force, avec un tir joueur très étroit. Et il y avait toujours le risque que, du point de vue du joueur, diminuer la portée du tir semble complètement absurde.
A la place, pour encourager les joueurs à tirer à bout portant dans ChoRenSha68k, j'ai décidé de réduire la taille des zones de collisions ennemies. Résultat : je faisais constamment des ajustements et des corrections de hitboxes. Les cuirassés ennemis du niveau 4 (ceux qui ne tirent que dans 8 directions) ont nécessité un nombre particulier d'ajustements, et j'ai dû les redessiner 4 fois.


Image
Des ennemis comme ces cuirassés du niveau 4
ont nécessité de nombreux réglages de la hitbox.



Avantages et inconvénients de l'autofire
Les jeux avec un tir manuel ont une sensation très tactile qui n'existe pas dans les jeux avec autofire. En fait, le tir manuel était un des plaisirs premiers du shmup. Toutefois, à un moment, certaines salles d'arcade commencèrent à installer des circuits d'autofire sur leurs bornes (en partie comme stratégie pour attirer de nouveaux clients), et en réponse les développeurs commencèrent à prendre en compte la présence d'autofire pour équilibrer leurs jeux. (NB : Gun Frontier est un bon exemple. Le rank augmente très vite si on utilise l'autofire.) L'autofire devint finalement une fonction standard des jeux.
Le tir manuel est une faculté distincte de la mémorisation de schéma et de la perception de mouvement. C'est une des techniques les plus difficiles à acquérir, or en tant que développeur, j'avais peur de rendre certains ennemis trop résistants et de créer une barrière infranchissable pour les joueurs qui ne pourraient pas marteler le bouton assez vite. C'est un autre élément en faveur de l'autofire, du point de vue de l'équilibrage.
Les mécaniques de tir manuel étaient sur le point de disparaître, je voulais donc les implémenter dans ChoRenSha68k. Après mûre réflexion, j'ai décidé d'utiliser une fonction semi-auto. J'ai imaginé que la vitesse d'autofire la plus basse serait comme exploser du papier bulle avec le pouce, et je l'ai réglé pour qu'il nécessite environ 4 appuis par seconde. Marteler plus vite que ça n'augmenterait pas la vitesse de tir.

Priorité des effets sonores
A cause des limitations matérielles, le x68k ne pouvait pas jouer plusieurs effets sonores simultanément.
Dans mon concept initial pour ChoRenSha68k, mon but premier était de rendre la destruction amusante. Le second était de rendre l'action de tir excitante. Les patterns de tir des boss dépendaient aussi de certains bruitages, donc du point de vue stratégique, il était très important et nécessaire qu'ils soient audibles par-dessus les bruitages d'impact. J'ai donc priorisé les bruitages selon cet ordre :
Explosions > Bruitages de patterns des boss > Bruitages d'impact > Tir du joueur

Précision des tirs ennemis
Si vous programmez tout correctement, vous pouvez faire viser les ennemis avec une précision de 100 %. Bien que ce soit correct d'un point de vue programmation, si on y réfléchit du point de vue gameplay, une meilleure précision des tirs ennemis n'est pas forcement un mieux.
J'attire ici votre attention sur quelques jeux qui utilisaient une faible précision pour les tirs ennemis :
Hishouzame (Toaplan 1987) - À partir de Hishouzame, les jeux Toaplan de cette époque utilisaient un système qui calculait les angles de tir des ennemis à partir d'une table d'arc-tangente doté d'une variable aléatoire unique (probablement un arrondi fractionnaire), de façon que les tirs vraiment orientés à 45 degrés n'arrivent pas souvent. Résultat : la stratégie de jeu a évolué pour arriver au point où on se faufile entre des vagues de tirs vaguement orientées à 45 degrés. J'ai entendu dire que l'équipe de développement de Raiden avait suivi Hishouzame et adopté délibérément le même système.
Parodius Da! (Konami 1990) - Dans ce jeu, la visée des ennemis est limitée à 16 directions. Cela permettait plusieurs stratégies basées sur des alignements précis qui lui conféraient un gameplay unique.
V.V (Toaplan 1993) - Après le second loop, l'écran se remplit d'un grand nombre de boulettes suicides avec un léger retardement. Comme l'angle de déviation de ces tirs est très faible (quasiment droit sur le joueur), des amas très denses de boulettes se forment qui peuvent devenir étonnamment difficiles à esquiver. Il y a beaucoup d'opportunités pour utiliser des esquives par à-coups (NDT : le genre d'esquive où vous décidez de vous déplacer d'un coup sur une grosse distance pour créer une ouverture afin d'y revenir pour orienter le flux de boulettes).
En étudiant ces exemples, j'ai décidé pour ChoRenSha68k d'ajuster manuellement la précision des tirs en fonction des circonstances. Les derniers niveaux, par exemple, contiennent beaucoup de réglages manuels.

Le système d'items
J'ai passé plusieurs années à réfléchir à comment structurer un système d'items qui permette au joueur de choisir librement son bonus. Dans Kyuukyoku Tiger et Raiden, où l'item change en fonction d'un timer, c'est stressant de collecter un bonus qu'on ne voulait pas. Dans des jeux comme Twinbee et 1943, vous devez arrêter de tirer pour collecter le power-up, ce qui est aussi une source de stress.
Après avoir gambergé sur un moyen de passer outre ces lacunes, je suis arrivé au système que vous connaissez actuellement pour ChoRenSha68k.
Malheureusement, quand j'ai ajouté la mécanique d'obtention simultanée des 3 bonus en se positionnant au centre, elle est devenue une part fondamentale du système de jeu et de scoring : je ne pouvais plus la retirer, elle est donc restée tout au long du développement. Elle a annulé mon concept original de choisir parmi 3 bonus et j'ai regretté de l'avoir ajoutée, mais je savais que les joueurs n'admettraient pas que je la retire dans une version future, je l'ai donc laissée en l'état.

De la nécessité d'un scoring system
Dans beaucoup de grands shmups d'arcade de l'époque, plus vous jouiez pour le score, moins vous étiez en phase avec le style de jeu original du genre. Beaucoup commençaient à s'interroger sur le bien-fondé du scoring en tant que mécanique sensée. Lorsque j'ai commencé à développer ChoRenSha68k, j'étais absolument contre le fait de jouer pour le score, mais à la sortie de la version 1.01, j'avais inclus quelques éléments de scoring.
Quand je me suis décidé à ajouter un système de score, j'étais partagé entre deux choix. Devait-il s'agir d'un système tout-ou-rien, où la perte d'une vie rend toute récupération du score impossible ? Ou fallait-il laisser une marge d'erreur, permettre au joueur de planifier un retour ? Je voulais utiliser le second choix dans ChoRenSha68k, mais si je devais honnêtement décrire le jeu, je crois qu'au final c'est plutôt du tout-ou-rien.
Battle Garegga a eu une influence majeure sur moi lorsque je réfléchissais à des systèmes de score. L'aspect aléatoire du premier niveau, la possibilité de détruire les ennemis par petits bouts pour scorer, etc. J'ai vraiment pompé dessus.


Le développement sur x68k


Langage de développement
Il existait un compilateur C pour le X68000 et le compilateur gcc a aussi été porté (c'était la version 1.42 à l'époque, je crois). À l'époque, les programmeurs prenaient la programmation en assembleur comme une question de fierté, mais j'ai codé 90 % de ChoRenSha68k en C et j'ai uniquement utilisé l'assembleur pour des cas précis où j'avais besoin d'une plus grande rapidité d'exécution.

Étendre la limite d'affichage des sprites
Le X68000 est pourvu de fonctions matérielles d'affichage des sprites, mais si vous travaillez avec des sprites de 16x16, il ne peut en afficher que 128 simultanément. Le PCG qui affiche les sprites ne peut définir que 256 motifs. Je savais que je n'arriverais tout simplement pas à développer un bon jeu avec ces limitations, donc j'ai décidé de développer un pilote qui rehausserait ces limites.



ChoRenSha68k 2-ALL.

Le système matériel d'affichage des sprites du X68000 est un système de Raster. Cela signifie qu'un sprite déjà affiché sur une ligne peut être ré-affiché sur une des lignes en dessous. En utilisant cette technique, j'ai pu quadrupler la limite d'affichage de sprites, de 128 à 512. J'ai aussi inventé une astuce où j'utilise ça de façon dynamique comme un cache, en utilisant une solution logicielle pour contourner la limitation du PCG matériel.

J'ai baptisé ce pilote XSP et je l'ai diffusé au public en tant que bibliothèque de fonctions sur le forum de Kusa no Ne. Je ne sais pas si quelqu'un en a besoin, mais on peut le télécharger à cette adresse.

Vérification de collisions
La détection simultanée de collisions multiples était très gourmande pour les CPU de l'époque. Afin d'accélérer les choses, j'ai développé un système spécial de détection de collisions : je divisais l'écran en bandes et détectais les collisions sur chaque zone. Aujourd'hui on appellerait ça un algorithme de VRAM virtuelle.
Avec ces méthodes, j'ai pu passer outre les limitations matérielles du système de sprites et afficher plus de sprites à l'écran en temps réel, ce qui m'a permis de terminer ChoRenSha68k pour de bon.


Le portage Windows

L'année suivant l'achèvement de la version X68000, j'ai résolu de porter ChoRenSha68k sous Windows pour m'initier à la programmation sur cet OS.

Portage Windows – Version préliminaire
J'ai commencé à développer le portage Windows durant la génération DirectX 3. Pour être honnête, DirectX à l'époque était assez balbutiant. Étant donné qu'il n'y avait pas de support pour des fonctionnalités hardware de gestion des sprites, j'ai décidé d'utiliser un rendu logiciel par CPU pour les graphismes. Afin d'accélérer le rendu, j'ai recouru à toutes sortes d'astuces comme l'Occlusion Culling, et j'ai tant bien que mal réussi à obtenir un affichage à 60 images/s.
Refaire la musique, c'était une autre paire de manches. Il faut des connaissances très spécialisées pour recréer de la musique synthétique ; pour moi, c'était l'enfer. Des formats comme mp3 et ogg vorbis faisaient leur apparition, mais je voulais que ChoRenSha68k tienne sur une disquette d'1 Mo. Afin de garder une taille de données musicales faible, j'ai créé un pilote son MOD/XM et j'ai essayé de porter la musique sous ce format, mais je ne peux pas dire que c'était une réussite.
Heureusement pour moi, quelqu'un avait sorti des dll pour un émulateur de musique FM sous x68k qu'il avait créé, j'ai donc pu utiliser ça et porter la bande-son.

Différences entre les versions X68000 et Windows
Malheureusement, il existe des différences subtiles entre les deux versions. En premier lieu, du fait qu'un bug de la version x68k est absent de la version Windows, les replays de l'une ne fonctionnent pas correctement sur l'autre. Le frame rate est différent entre les deux versions, l'original tournant à 55 images/s et la version Windows à 60. En outre, la version Windows n'a pas de ralentissements, ce qui la rend beaucoup plus difficile.



Bande-son de ChoRenSha68k, niveau 1.


La musique

La musique a été composée par Ruzarin. À l'époque, il travaillait rapidement, en produisant une BO complète de qualité comme celle-ci en quelques jours. C'était aussi l'époque où le son des synthés commençait à disparaître des salles d'arcades, et on pouvait entendre la complainte des amoureux de ce son : "Encore !"


En rétrospective sur ChoRenSha68k

Quand je fais le point sur les heures que j'ai passées, je m'aperçois que j'ai consacré plus de temps à développer les outils pour faire le jeu, que le jeu en lui-même. Tout ce temps passé à coder les bibliothèques de base nécessaires pour pallier les insuffisances du X68000, le travail abattu pour dompter DirectX et le temps consacré à mettre à jour l'architecture sonore...
Certains points comme la lenteur des CPU, le manque de mémoire, la faible bande passante (rapport au temps nécessaire pour télécharger le jeu pour les utilisateurs) se sont résolus d'eux-mêmes en quelques années, alors que j'étais là à coder pour les résoudre en avance. Avec du recul, j'ai vraiment gâché beaucoup de mon temps. Quand vous développez un jeu, vous devez réfléchir au temps que vous allez investir pour surmonter ces difficultés techniques. Aujourd'hui, je pense que ChoRenSha68k est un bel exemple d'échec en ce qui concerne la recherche de cet équilibre.
À l'heure où j'écris ceci, en 2009, j'ai le sentiment que ces soucis d'environnement de développement sont un lointain souvenir pour les développeurs. Maintenant qu'on n'est plus tributaire d'un OS ou d'une architecture donné, je pense que j'aimerais essayer de refaire un jeu, en dilettante ("Je commence dès que j'ai un peu de temps libre"... Depuis combien d'années je dis ça ?)
___________________________________________________________________________________________________________________________________________

On voit ici l'amour du genre et le soucis du details qui ont amené à la création de cette pépite. Personnellement, depuis que j'ai lu ça, j'aime encore plus le jeu :)
Avatar de l’utilisateur
GameOver
Ampoule aux Pouces
Messages : 422
Inscription : 03 juin 2018, 21:46
Localisation : Toulouse

Merci beaucoup pour la traduction et le partage, c'est passionnant. Ce qui est amusant c'est que j'ai découvert ChoRenSha par hasard la semaine dernière en émulation X68000, donc ça tombe à point ! J'avoue être resté scotché devant l'écran, ce jeu est une vraie réussite. Les patterns, le maniement du vaisseau... etc etc. Un doujin qui enterre nombre de productions "professionnelles" de l'époque !
Avatar de l’utilisateur
MossieuxK
Brute du bouton A
Messages : 255
Inscription : 14 mars 2018, 21:00
Page Facebook : https://twitter.com/Kyesos
Localisation : au 1er, porte de gauche
Contact :

WOAOOOW ! Quel boulot ! Félicitations et merci pour le partage <3.
The Big Gameovski - le canal MidLife Gamer : https://www.youtube.com/c/MôssieuxK
TBG Touitteur : https://twitter.com/TheBigGameovski
Mon petit chez moi : https://www.kyesos.com/
Image
Avatar de l’utilisateur
sisi
1 crédit c'est déjà trop
Messages : 2294
Inscription : 26 juin 2003, 18:10
Localisation : Villepreux (78)

Merci psychogore, je suis content qu'un "fanboy inside" naisse en 2020, surtout quand il s'agit d'un jeu dont je suis fan aussi (j'avais écrit il y a bien longtemps le test sur le site), c'est top ce que tu as fait, vraiment :aaah:
Il y a un shoot sorti récemment qui m'a fait énormément pensé à lui, c'est Graze Counter (https://store.steampowered.com/app/6294 ... e_Counter/) à essayer de toute urgence si vous êtes fan de ChoRenSha68k !
Shmupland, shmupland über alles!
Avatar de l’utilisateur
Guts
Modérateur
Messages : 8963
Inscription : 22 mai 2003, 18:02
Localisation : 28
Contact :

Qu'elle excellente interview. C'est passionnant à lire.
Toaplan Legendary Series
** Image **
Image
Répondre