MUGEN - Créer des Stages sans animation.
_________________________________
Werewolf.

Sommaire :
Généralités
Création d'un décor statique
    Mon premier stage
    Création d'un stage statique tiré d'un vrai jeu avec mouvements latéraux de caméra
    Création d'un stage statique avec mouvements latéraux et verticaux de caméra
Création d'un décor sur plusieurs plans
A propos de l'éthique de Mugen

Créer ses propres stages dans Mugen n’est pas très compliqué. Nous allons voir ici comment créer des décors statiques (pas de mouvement de caméra), puis comment créer des décors fixes (un seul plan) avec mouvements de caméra, et enfin, créer des décors avec des scrollings différentiels (plusieurs plans fixes bougeant à des vitesses différentes, donnant ainsi une impression de profondeur).

Généralités

Un décor ne requiert que deux fichiers : un fichier DEF, et un fichier SFF. Le fichier DEF contient les données propres à la gestion du décor : distance des combattants par rapport au sol, mouvement de caméra, etc. Le fichier SFF, lui, contient tous les éléments graphiques du décor. Par mesure de simplicité, les deux fichiers portent le même nom (truc.sff et truc.def).

Pour travailler, nous allons avoir besoin de quelques programmes : un éditeur de textes (je vous conseille EditPad, très complet et très simple), un éditeur d’images (je travaille avec Paint Shop Pro 5.0 pour créer véritablement les images, avec Corel PhotoPaint pour des assemblages et des découpages, et avec Irfan View pour de simples « mises aux normes MUGEN ». Ce dernier programme présente le double avantage d’être extrêmement léger puisqu’à la base, c’est un viewer, et d’être gratuit puisque c’est un freeware). Il nous faudra également un émulateur pour récupérer des décors sur consoles (pour la SNES, Zsnes est vraiment très bien). Enfin, il nous sera indispensable de posséder MCM – Mugen Character Maker, afin de créer le fichier SFF.

Création d’un décor statique.

Mon premier stage.

Nous allons créer un premier stage, qui ne sera certainement pas très joli, mais peu importe. Le but est de voir comment ça marche. Nous allons commencer par créer notre fichier graphique. Utilisons donc notre logiciel de dessin favori, et créons une image qui fera 320 pixels de large sur 240 de haut. Notre image devra avoir un maximum de 256 couleurs, et être enregistrée au forma PCX, le seul reconnu par MCM.

Ouvrons maintenant MCM :

Nous allons simplement ajouter notre image. Pour cela nous allons cliquer sur le bouton « Add Sprite » (ou menu SFF>Add Sprite). Dans la fenêtre suivante, on va sélectionner l’image que l’on a créé auparavant, puis, sans rien changer, cliquer sur Load :

Notre image ne semble pas centrée, mais ce n’est pas très grave. Ce qu’il faut noter, ce sont les coordonnées X et Y qui sont à zéro, de même que les valeurs « Group » et « Image ». Il ne nous reste plus qu’à sauvegarder notre création (menu SFF>Save), en lui donnant un nom (essai.sff, par exemple). Nous pouvons ensuite fermer MCM.

Ouvrons maintenant un éditeur de textes, afin de créer le fichier DEF. Voici globalement son contenu :

Il ne reste plus qu’à remplir les valeurs.

Le fichier commence par un point-virgule. Dans ce fichier, tout ce qui suit ce caractère est considéré comme un commentaire et est donc ignoré par MUGEN. Vous pouvez donc mettre un texte de présentation, par exemple. NB : Cette remarque est valable pour tous les fichiers Mugen qui peuvent être édités avec un traitement de texte.

Ensuite, on entre dans la section [Info] qui ne contient qu’un paramètre : name. C’est ici qu’on nomme le stage (c’est le nom qui apparaîtra dans Mugen pour le choix du stage). Ce nom doit forcément être entre guillemets. Mettons donc name = "stage".

On arrive ensuite à la section [Camera]. Les paramètres startx et starty seront toujours à 0. Ensuite, on a les limites du champ de caméra, en dehors de la fenêtre de base. Cette fenêtre de base fait 320 par 240, soit exactement la taille de notre image. La caméra n'aura donc pas à bouger, c'est pourquoi les paramètres boundleft, boundright, boundhigh et boundlow resteront à zéro. Nous avons ensuite le Vertical follow, qui indique à la caméra de quelle façon elle doit suivre les personnages lorsqu'ils sautent. La valeur doit être comprise entre 0 et 1. A zéro, la caméra ne bouge pas. Cette variable est donc sans incidence sur notre décor puisqu'il est statique. Par défaut, cette valeur est de 0.2. Le Floortension est lié au Vertical Follow. Il indique à quelle distance du sol doit se trouver le combattant pour que la caméra commence à se déplacer vers le haut. Là encore, sur un décor statique, cette variable n'influe pas. La valeur par défaut est de 0. Le paramètre suivant, tension, fonctionne de la même façon, mais horizontalement, et par rapport aux bords de l'écran. Ca ne fonctionne qu'avec les décors dont la largeur est supérieure à 320 bien sûr. La valeur par défaut est de 50.

On arrive ensuite dans la section [Player Info]. En général, il n'y a pas à modifier cette section. Les valeurs données ici sont valables pour n'importe quel stage. La première partie concerne le positionnement des joueurs au départ. Tout ce qui commence par "p1" s'applique au joueur de gauche, et par "p2", au joueur de droite. Sachant qu'ici l'origine (0,0) est le milieu de l'écran, au sol, les valeurs par défaut sont : p1startx = -70, et p2startx = 70, ce qui répartit les deux joueurs de part et d'autres de l'axe central, à une distance raisonnable l'un de l'autre. P1starty et p2starty sont tous les deux à 0. C'est une autre valeur qui va définir à quelle hauteur ils se situent dans l'écran. P1startz et p2startz sont censés définir la profondeur à laquelle se situent les personnages, mais en fait, ça n'a pas de réelle incidence. La valeur par défaut est de 0. Enfin, le facing indique de quel côté doivent être tourné les joueurs : p1facing = 1, et p2facing = -1.

Ensuite, on trouve leftbound et rightbound. Ces deux valeurs indiquent sur quelle distance peuvent évoluer les personnages. Les valeurs par défaut sont de -1000 pour leftbound, et 1000 pour rightbound. Essayez d'inverser ces valeurs, et vous aurez les personnages qui seront collés l'un à l'autre, sans pouvoir avancer ni reculer. Quant à topbound et lowbound, il n'y a pas d'indications sur ces valeurs. Il vaut mieux laisser les valeurs par défaut, à savoir 0 pour les deux. Il semblerait que ces valeurs correspondent à des limites sur l'axe z (ce qui est assez bizarre étant donné qu'il s'agit d'un jeu en 2D, n'utilisant normalement que les axes x et y – une future évolution de Mugen proposerait-elle un jeu en 3D ?)

La partie [Scaling] semble elle aussi dédié à ce mystérieux axe z. Il n'est donc pas utile de modifier les paramètres par défaut, à savoir : topz = 0, bottomz = 50, topscale = 1, bottomscale = 1.2.

On arrive ensuite dans la partie [Bound] qui définit la distance minimale qui doit séparer le personnage du bord de l'écran. La valeur typique est de 15 : screenleft = 15, screenright = 15.

On arrive ensuite à la partie [StageInfo]. Le zoffset définit la ligne de sol, c'est-à-dire la position du sol où doivent se trouver les personnages. La position de cette ligne de sol est mesurée à partir du haut de l'écran. Cette valeur est usuellement de 190, mais est à définir au cas par cas, selon les décors. Plusieurs essais seront peut-être nécessaires pour obtenir le bon positionnement des joueurs. Autoturn définit si le personnage doit se tourner automatiquement ou non (1 = oui, 0 = non). La valeur par défaut est bien sûr de 1. Enfin la valeur ResetBG sert à réinitialiser le stage en début de round (1 = oui, 0 = non). Il vaut mieux laisser ce paramètre à 1.

La section suivante, [Shadow], définit l'ombre des personnages. Color définit la couleur de l'ombre, selon le système RGB (Rouge, Vert, Bleu). Selon ce système, chaque couleur peut avoir une valeur allant de 0 à 255. Trois valeurs identiques donnent un niveau de gris, trois zéros donnent du blanc, et trois 255 donnent du noir. On utilise souvent les valeurs 128,128,128. Mais rien ne vous empêche d'essayer autre chose. Yscale est l'échelle utilisée pour dessiner l'ombre par rapport à la taille du personnage. La valeur 0.3 signifie que la taille de l'ombre sera de 30% par rapport à la taille du combattant (100%). Il est possible de définir une valeur négative afin de renverser l'ombre (tombante au lieu de montante). Enfin, reflect permet de dessiner un reflet du personnage (1 = oui, 0= non), pour simuler un sol en verre, ou en parquet poli, par exemple. Dans ce cas, il vaut mieux mettre un yscale à 0, afin d'éviter d'avoir une ombre plus un reflet (pas vraiment joli).

Section [Music] : elle permet d'attribuer une musique à un stage. Le paramètre bgmusic donne le chemin de la musique (au format MID, MOD, MP3, ou CDA (musique de CD – dans ce cas, utilisez juste le n° de la piste, avec l'extension DA : bgmusic = 1.da jouera la première piste du lecteur CD). Il est conseillé de mettre les fichiers sons dans le répertoire "sounds". Le chemin sera alors : bgmusic = sounds/nom_du_fichier_son.extension. Exemple : bgmusic = sounds/Iwillsurvive.mp3. Le bgvolume indique le volume auquel sera joué la musique : 0 pour un son normal, valeur négative pour un son plus faible, valeur positive pour un volume plus élevé (ne marche pas avec les midi).

On arrive ensuite au [BG Def]. Dans cette section, on va simplement indiquer où se trouve le fichier graphique SFF associé au décor. Peu importe en fait où se trouve actuellement le fichier essai.sff que vous avez créé car une fois le fichier DEF terminé, nous les mettrons dans le dossier STAGES. Dès lors, le paramètre spr sera : spr = stages/essai.sff.

Nous allons ensuite créer une nouvelle section nommée [BG 0]. En fait, on peut mettre ce que l'on veut à la place du 0. C'est même conseillé lorsque l'on a plusieurs plans : cela permet de les repérer plus facilement (ex : [BG 1erplan], [BG Arrièreplan], etc.). Ces sections sont des définitions de plans.

Ici, comme il s'agit d'un décor simple, nous n'aurons qu'une seule section de ce type.
            Type peut être soit normal (fixe), parallax (applique une déformation au plan en fonction du déplacement de la caméra, donnant une illusion de 3D - les exemples les plus parlants sont les sols des Street Fighters 2 - on ne verra pas leur utilisation dans ce tutorial), et anim (décrivant un décor animé - que nous n'utiliserons pas non plus). Notre décor étant statique, nous allons lui donner la valeur type = normal.
            Le spriteno définit l'image de base du plan, qui correspond aux numéros de group et d'image donné par MCM lors de la création du fichier SFF. On n'a vu que notre image avait un group à 0 et une image à 0 également. Le spriteno sera donc : spriteno = 0,0.
            Layerno indique si le plan doit être affiché devant (1) ou derrière (0) les personnages. Il s'agit ici d'une image de fond, et nous mettrons donc la valeur layerno = 0.
            Ensuite, la valeur start est censé donné les coordonnées (x,y) de départ du décor. La valeur de x est négative et doit être égale à la moitié de la largeur du décor. Y reste toujours à 0. On aura donc : start = -160,0.
            Le Delta indique la vitesse de déplacement en x et en y du plan, lorsque la caméra est amené à bouger. Pour un 1^er plan, il devra bouger à la même vitesse que les personnages, donc ici delta = 1,1. Notez quand même qu'ici, notre écran ne bougeant pas, ce paramètre n'a pas d'incidence.
            Le paramètre trans permet d'ajouter (add) ou d'ôter (sub) de la couleur. Cependant, les résultats sont souvent extrêmes (essayez si le cœur vous en dit !), et il vaut mieux laisser trans = none, pour laisser le décor tel quel.
            Mask permet de masquer ou non la couleur de valeur 0 (c'est-à-dire le noir). Cette option sert lorsque l'on utilise plusieurs plans. Dans ce cas, on mettra la valeur à 1. Sinon, on la laissera à 0 : mask = 0.
            Tile permet de faire une mosaïque à partir d'une image, en la répétant. C'est cette technique qui a été utilisée pour créer le décor "stage0" fourni avec Mugen. Cependant, c'est une technique qui reste assez rare, puisque les décors ainsi créés sont assez pauvres graphiquement. Le Tile peut se faire horizontalement et/ou verticalement (d'où les deux chiffres – 1 pour activer le tiling, 0 pour ne pas l'activer). Nous aurons donc : tile = 0,0.
            Directement lié au Tile, le Tilespacing indique juste l'espace à laisser en x et en y entre les images constituant la mosaïque. N'utilisant pas le tiling, nous laisserons ces valeurs à 0 : tilespacing = 0,0.
            Enfin, Window définit la fenêtre d'affichage. Les valeurs par défaut sont 0,0,319,239, qui correspondent à un affichage 320x240. Les 4 valeurs définissent une fenêtre d'affichage grâce à deux points (x1,y1 et x2,y2). Même pour un décor plus grand, ces valeurs peuvent rester telles quelles puisqu'elles définissent l'affichage. On aura donc : Window = 0,0,319,239.

Ca y est ! Notre décor est terminé ! Nous pouvons l'enregistrer sous le nom "Essai.def". Ensuite, nous allons placer une copie des deux fichiers essai.def et essai.sff dans le répertoire stages. Ensuite, nous allons ouvrir le fichier data/selec.def, et allez à la fin de la section [ExtraStages], et entrez la ligne : stages/essai.def. Sauvegarder le fichier, et lancer Mugen. Il va s'agir maintenant de tester notre décor. Pour cela, il suffit de choisir le mode "Training" ou "Watch", de sélectionner deux personnages, puis lors de la sélection du stage, d'appuyer sur la flèche gauche pour afficher notre nouveau stage. Lancez ensuite le combat, dans lequel devraient s'afficher les personnages :

Et voici notre premier stage qui marche ! Y a rien de transcendant pour l'instant, mais ça va venir avec la prochaine étape, où l'on va réaliser un vrai décor digne de ce nom, en ajoutant une petite difficulté : ne pas se limiter à 320 en largeur…

Création d'un stage statique tiré d'un vrai jeu, avec mouvements latéraux de caméra.

A partir de là, il y a juste quelques subtilités qui vont changer par rapport à ce qu'on vient de voir. Si vous avez bien assimilé ce premier stage, la suite ne devrait pas poser de problème.

On va réaliser un décor tiré d'un jeu Super Nintendo. Pour cela, il vous faut un bon émulateur (Zsnes, par exemple) et la rom du jeu que vous souhaitez ripper. Tout cela se trouve sans difficulté sur Internet. Voici le procédé avec Zsnes : il va s'agir de ripper le décor à partir du jeu. Zsnes présente le grand avantage de pouvoir éliminer les plans inutiles et les sprites avec les touches 1-5 situées au-dessus des touches alphabétiques. On peut faire des captures en appuyant sur F1 – Snapshot. Un conseil : prenez un décor fixe pour le moment.

Une fois les images récupérées, assemblez-les de façon à n'en avoir plus qu'une représentant l'intégralité du décor. Ensuite, on va la retravailler avec Irfan View (disponible gratuitement sur Internet). Ouvrez votre image. On a maintenant trois opérations à faire : 1) donner une taille suffisante à l'image 2) mettre le bon nombre de couleurs, et 3) mettre l'image au format PCX. IrfanView va nous permettre de faire tout cela très facilement.

1)      Donner de bonnes dimensions à l'image : Selon l'émulateur que vous utilisez et la résolution adoptée, vous allez avoir une image plus ou moins grande. Je vous rappelle que pour faire un décor, il nous faut au minimum une taille de 320 sur 240. Mais comme on souhaite avoir une image plus large, on va devoir redimensionner cette image, en conservant une hauteur de 240. Pour cela, on va utiliser la fonction Resize/Resample (Ctrl+R) :

Quelle que soit la taille de votre image, il faut cocher "Preserve aspect ratio" afin de garder le rapport hauteur/largeur. Ensuite, peu importe la largeur de notre décor, il faut simplement que la hauteur soit égale à 240. Dans la case "Height" du cadre "Set a new size", on inscrira donc 240. La largeur sera automatiquement calculée, et s'affichera dans "Width". Si ce Width est impair, rajoutez 1 dans cette case de façon à avoir un nombre pair.

Si en mettant 240 en hauteur, votre image fait moins de 320 en largeur, il faut retravailler votre image pour la rendre plus large.

Cliquons sur OK, et l'image est retravaillée.

2)      Mettre le bon nombre de couleurs. MCM n'accepte que des images en 256 couleurs. Oubliez donc les images 24 bits ! Toutefois, comme la plupart des images sont enregistrées en 16 millions de couleurs, il va falloir les réduire à 256 couleurs. Rien de plus simple : dans le menu "Image", choisissez "Decrease color depth" (si vous êtes en moins de 256 couleurs, choisissez "Increase color Depth"). Une nouvelle fenêtre va s'afficher. Choisissez 256 couleurs, et faites OK. Il ne nous reste plus qu'à convertir notre image en PCX.

3)      Là encore, c'est très simple : faites un Ctrl+S pour enregistrer votre image. Dans la fenêtre "Save…", tapez le nom que vous souhaitez donner à votre fichier, et dans Type, choisissez "PCX – Zsoft Paintbrush", et cliquez enfin sur "Save".

La suite est assez basique : Ouvre MCM et créer votre fichier SFF comme décrit avant, sans rien toucher, et enregistrez-le (nommons-le essai2.sff). Faites ensuite une copie de votre fichier essai.def, appelez-le "essai2.def", et ouvrez-le.

On ne va pas reprendre tous les paramètres ici, d'autant que la plupart ne changent pas. Voici les valeurs à changer :

Dans [Info], changer le nom, pour identifier votre nouveau décor.

Dans [Camera], Boundleft et Boundright vont changer. Leur valeur sera égale, sauf que Boundleft sera négatif, et Boundright, positif. Comment calcule-t-on cette valeur ? C'est simple : on fait (largeur du décor-320)/2. Par exemple, si vous avez un décor qui fait 500 de large, ça donnera : (500-320)/2 = 90. Dans ce cas, Boundleft = -90 et Boundright = 90.

Ensuite, rien ne change jusqu'à [BG Def], où il ne faut pas oublier de changer le nom du fichier SFF (spr = stages/essai2.sff).

Enfin, dans [BG 0], le "start" va changer. Comme on l'a dit avant, il faut mettre en négatif la moitié de la largeur du décor. Donc pour un décor de 500 de large, on aura start = -250,0.

Tout le reste ne change pas. Simple, non ?

Création d'un stage statique, avec mouvements latéraux et verticaux de caméra.

Bon, à partir d'ici, on va commencer à corser un tout petit peu la chose, puisque non seulement notre caméra pourra suivre nos déplacements de gauche et de droite, mais aussi vers le haut lors des sauts.

Récupérons une image (ou recréons une image à partir d'un décor tiré d'un vrai jeu, si vous voulez) pour notre stage. Si votre image fait moins de 260 en hauteur, retouchez-la comme on l'a vu avant pour lui donner une hauteur de 260.

Reprenons maintenant notre fichier DEF, que l'on renommera 'Essai3.def', et voici les paramètres que l'on va mettre pour une image qui fait 500 de large sur 260 de haut

On ne revient pas sur la partie [Info], où vous mettrez le nom que vous voulez. Pour les valeurs boundleft et boundright, je vous rappelle le calcul : (500-320)/2 = 90. Le boundleft est négatif, et le boundright positif.

On en arrive au boundhigh, maintenant, qui cette fois, n'est plus à zéro. Le boundhigh est la limite haute du décor. Pour déterminer cette valeur, il faut savoir que la ligne en haut de l'écran à une valeur y=0, tandis que la ligne tout en bas à une valeur y=240. En conséquence, si votre décor fait 240, la limite haute se situe bien à boundhigh=0, mais s'il fait plus de 240, alors on cale la dernière ligne sur 240, et on opère par différence pour trouver le boundhigh :

Sachant que la ligne du bas vaut 240, et que les décors seront forcément calés sur cette ligne pour avoir le même sol, on en déduit que si un décor a une hauteur supérieure à 240, le boundhigh devient négatif. En pratique : boundhigh = 240-hauteur du décor. D'où ici boundhigh = 240-260 = -20.

Le boundlow est la limite basse de l'écran, et reste normalement toujours à 0 (sauf décor mouvant style ascenseur qui descend…).

Tous les paramètres qui suivent ne bougent pas, vous vous en doutiez peut-être. NB : le zoffset ne change pas non plus, car un zoffset à 230 placera toujours le sol au même endroit, quelque soit la hauteur du décor, selon le même principe qui veut que la dernière ligne en bas ait une valeur y=240, quelque soit le décor.

Pourtant, si vous créez normalement le fichier SFF, et que vous lancez votre stage, vous allez avoir une surprise de taille : le haut du décor sera calé sur le haut de l'écran de départ, si bien que vous ne voyez pas les lignes du bas (elles sont hors écran), et si vous sautez, vous avez effectivement un mouvement de caméra, mais pas de décor au-delà, et du coup, les sprites ne s'effacent pas.

L'astuce vient de la création du fichier SFF. En effet, si vous ouvrez votre SFF avec MCM, vous verrez que votre image est à 0 en x et en y. Soyons logiques !! Si on a mis dans le fichier DEF que la limite haute était à y=-20, on ne peut pas la mettre à y=0 dans le SFF. Attention quand même, il y a une petite subtilité : alors que Mugen fait croître les y en allant vers le bas, MCM, selon notre géométrie classique, les fait croître en allant vers le haut. En conséquence, il faut inverser le boundhigh, et mettre la valeur 20 dans la case y. Vous devriez voir votre image remonter dans la partie graphique de MCM. Sauvegardez et relancez : cette fois, ça marche !

Entraînez-vous un petit peu à créer des stages de stages différents avant de passer à l'étape suivante.

Un petit mot sur le boundhigh, encore : en fait, il ne définit pas à proprement parler la limite haute du décor, mais la limite jusqu'à laquelle la caméra peut monter en hauteur. Cette nuance peut être essentielle. Par exemple, si vous laissez boundhigh à -20 dans le DEF, mais que vous ayez un fichiez qui fait 280 de hauteur, et que vous mettiez bien 40 dans le SFF (=–(240-280)), lorsque vous sauterez, vous ne verrez pas les 20 dernières lignes en hauteur, car le DEF empêche la caméra de monter.

Vous me direz que la solution est de toujours accorder le DEF avec 240-hauteur de fichier. En fait, oui et non. Ce n'est plus un problème technique, mais une question de confort de jeu : si vous avez un décor qui fait 500 de hauteur, vous allez mettre dans le DEF boundhigh=260. Mais en jouant sur votre décor, avec Evil Ken, par exemple, si vous sortez le Shoryureppa qui ne touche pas l'adversaire, vous allez monter très très haut, et la caméra va suivre. Conséquence, quand vous redescendez, vous ne voyez plus votre adversaire, et vous ne savez pas s'il prépare une contre-attaque. Inversement, si c'est l'ordinateur qui a Evil Ken et qu'il sort un Shoryureppa dans le vide, vous ne voyez plus votre personnage, et du coup, vous ne savez pas exactement où vous êtes pour pouvoir contre-attaquer. En revanche, pour l'ordinateur, ceci ne pose aucun problème puisqu'il ne gère pas une situation en visuel comme vous, mais des données en fonction desquelles il agit.

C'est pourquoi je vous encourage à 1) brider le boudhigh à un maximum de 60-70 et 2) ne pas choisir des images ayant une trop grande hauteur (car si vous respectez le 1), on ne verra pas le décor en entier…).

Bien, finis les décors statiques, nous passons maintenant l'étape supérieure avec les décors sur plusieurs plans.

Création d'un décor sur plusieurs plans.

On va commencer par la création des fichiers PCX qui vont être mis dans le SFF. On va partir d'un exemple simple, avec deux plans. Notre exemple sera un stage que j'ai déjà réalisé : "Castlevania Scrolling", adapté de "Castlevania IV – Entrance of Dracula's Mansion", un autre de mes stages. Pour les captures, il s'agit du jeu Castlevania IV, le tout premier niveau (peut-on appeler ça un niveau ?) qui mène au pont-levis.

Je ne reviens pas sur la récupération des images, ni sur la manière de les assembler pour créer une image cohérente. Normalement, à ce stade, vous devez savoir le faire les doigts dans le nez. Donc, sachez que ce niveau comporte deux plans, qui une fois reconstitués nous donneront les images suivantes :

Ceci est le décor qui sera au premier plan. Ce sera le sol sur lequel se battront les personnages. Vous aurez certainement besoin de retravailler l'image, de façon à mettre en noir tout ce qui n'appartient pas au plan, sans quoi, vous aurez des parasites lors de la superposition des plans.

L'image de fond, qui bougera à une vitesse différente, donnant une impression de profondeur au décor. Vous noterez tout de suite que ce plan est beaucoup plus petit que le premier.

A titre indicatif, voici les tailles de ces images :
—    Premier plan (que nous appellerons 1P.pcx) : 825x220
—    Arrière plan (que nous appellerons AP.pcx) : 350x216

Vous noterez tout de suite qu'aucune de ces deux images n'a les 240 pixels de haut requis pour un décor normal. En fait, les deux images seront légèrement décalées en hauteur, si bien qu'on aura quand même tout notre écran rempli en hauteur, selon ce schéma grossier :

Toutefois, pour faire simple, notre décor ne dépassera pas les 240 de hauteur, ce qui fait qu'il n'y aura pas de mouvements verticaux de caméra. Nous allons ensuite mettre nos images dans notre fichier SFF.

La première image que nous mettre sera AP.pcx, avec les coordonnées 0,0. Nous lui mettront également des valeurs de groupe et d'image à 1,0 afin de réserver les valeurs 0,0 au premier plan. Toujours en cliquant sur Add Sprite, nous allons insérer la seconde image, qui elle, ne pourra pas avoir les coordonnées 0,0. En effet, selon le schéma, notre image commence à y=20, soit y=-20 sur MCM. Il y a alors une petite subtilité, étant donné qu'on ne peut pas taper dans les cases x et y un nombre négatif. Il faut donc, lors de l'insertion, laisser y à 0, puis, faire un cliquer-glisser pour descendre l'image à la valeur y=-20. Sauver votre SFF sous 'scrollings.sff'.

Ensuite, il ne reste plus qu'à créer le DEF, ce qui, pour le début au moins, ne devrait plus vous poser de problèmes. Si vous hésitez du fait que les deux graphismes n'ont pas la même taille, sachez qu'il faut raisonner avec les valeurs maximales. Donc on règlera tous les paramètres comme si notre décor avait 825 en largeur et 240 en hauteur (c'est la hauteur que nous donne la superposition des deux images, du fait qu'elles sont décalées, alors qu'en largeur, AP est toujours compris dans la largeur de 1P, et n'en sort pas). Petite précision sur les valeurs boundleft et boundright : notre fichier ayant une longueur impair, on ne peut pas mettre boundleft = -(825-320)/2 = -252.5. On va donc répartir le demi-pixel en trop sur les deux valeurs : boundleft= -252 et boundright= 253.

Là où ça va un peu changer, c'est sur la dernière partie, les sections [BG], que nous allons reprendre ici :

Ici, nous abordons quelques subtilités. Si le BGdef ne présente aucune particularité, on note qu'il n'y a plus [BG 0], mais deux sections [BG truc]. Comme on l'a dit au début du tutorial, on peut mettre ce qu'on veut derrière BG. En fait, ce sont les noms que l'on va donner aux plans, d'où ici "horizon" pour l'arrière-plan, et "sol" pour le premier plan.

Les deux plans sont définis de la même façon. On retrouve le type "Normal", puis le spriteno, qui correspond au numéro de groupe et d'image du plan dans le fichier SFF (à vous de les noter). C'est ainsi qu'on reprend le 1,0 qu'on avait attribué à l'arrière-plan pour le BG Horizon, et 0,0 pour le BG sol. Le Start permet toujours de repartir du milieu de l'image en x. Cette fois, il faut considérer les images séparément. On a donc start = -(350/2 = 175),0 pour le BG Horizon, et start = -(825/2 = 412.5 arrondi à 412),0 pour le BG sol.

Ensuite on aborde le Delta. On l'a dit, c'est la vitesse de déplacement du plan par rapport à la vitesse de déplacement du personnage, avec 1 = même vitesse pour le décor que pour le personnage. C'est cette valeur qu'on avait mise jusqu'ici puisqu'en fait, on a fait que des décors avec des premiers plans. On constate ainsi logiquement que le BG sol, qui fait office de premier plan, a un delta en x et en y (bien que là, il ne soit pas indispensable) à 1.

En revanche, pour notre BG Horizon, ce n'est pas du tout le cas ! En fait, cette image va se déplacer beaucoup moins vite, car faisant 350, il ne doit presque pas défiler. Ce delta va dépendre non pas de la vitesse de déplacement du personnage, mais de la longueur sur laquelle l'arrière-plan va se déplacer, c'est-à-dire concrètement, de la longueur du premier plan. Par ailleurs, comme pour les boundleft et boundhigh, on ne va pas tenir compte de l'écran affiché.

Tout cela se résume ainsi :

Légende :

Il y a une formule qui permet de calculer assez précisément la valeur du delta en x :

Ici, cela nous donne :

On n'arrondit pas le delta car Mugen reconnaît jusqu'à 6 chiffres après la virgules (même si ce sont les 3 premiers qui sont essentiellement significatifs).

On en déduit que la formule pour trouver le delta en y, s'il y avait besoin serait :

Il faut aussi bien voir qu'ici, on ne doit pas calculer de delta en hauteur du fait que la hauteur de chacun des plans est inférieure à 240. Cela ne serait valable que si on avait un arrière plan dont la hauteur dépasse 240.

On comprend également que le delta d'un plan qui fait 320 de large ou 240 de haut sera fatalement de 0.

Enfin, il y a le mask. Mask est utilisé sur le BG sol afin de cacher la couleur noire (couleur 0), ce qui nous permet de voir l'arrière-plan derrière les escaliers du premier plan. Sans ce paramètre, on ne verrait l'arrière-plan que sur les 20 dernières lignes du haut.

Voilà ! Notre stage est prêt à fonctionner !

L'ETHIQUE DE MUGEN, QUELQUES MOTS...

Le problème est que pas mal de personne passe outre cette éthique morale et prenne leurs aises en "hostant" (rendant téléchargeables directement depuis leur site) des personnages sans demander l'autorisation à l'auteur, en les incluant dans des jeux de la même façon, en les modifiant, ou encore pire, en vendant des jeux mugen, qui est et doit rester dans tous les cas gratuit.

Bafouer cette éthique engendre énormément de problèmes que les "pirates" (appelons-les ainsi...) n'imaginent pas toujours, ou dont ils se foutent des conséquences. Pourtant, elles existent, et se traduisent pour l'instant par le départ de créateurs de persos et de stages. Ces auteurs, qui voient leur travail (bénévole, rappelons-le) galvaudé par des profiteurs, préfèrent arrêter de créer pour la communauté Mugen, la privant ainsi de ses créations. C'est assez grave en soi puisqu'ils n'existent pas tant de créateur de personnages que cela, puisque la réalisation d'un perso demande souvent beaucoup de travail, de temps, d'énergie. Seuls les passionnés s'y risquent, et il est dommage de leur faire perdre la foi.

L'autre risque est, d'une certaine manière, plus grand encore, même s'il ne s'est pas réalisé pour l'instant : il s'agit des réactions des éditeurs. La plupart des personnages créés, sont en fait "mugenisés", c'est à dire adaptés d'un jeu vidéo pour Mugen. Ces personnages appartiennent aux firmes qui les créent (Capcom, SNK, Akklaim, etc.), et leur utilisation pour Mugen est simplement tolérée, du fait que ce concept est entièrement gratuit, et constitue une sorte "d'hommage" aux personnages. Mais si certains s'amusent à vendre Mugen, ces sociétés pourraient voir d'un mauvais oeil que des petits malins se fassent du fric sur leur travail. Elles pourraient ainsi décider d'user de leur droit de propriété pour se faire verser des royalties sur leurs créations. Le problème est qu'il y a peu de chance que ce soit les pirates qui paient, mais plutôt les créateurs : pour créer un personnage censé être distribué gratuitement, il faudrait alors payer. Mais les sociétés pourraient également envisager d'interdire purement et simplement l'utilisation de leurs créations pour Mugen. Ce serait alors la fin de ce concept.

C'est pourquoi vous êtes invités à respecter l'éthique morale de Mugen, pour lui permettre de continuer de vivre, tout simplement.