On a fait grosso modo le tour de tout ce qui était utilisation normale de Mugen : installations de composants et réglages. J’entre donc dans une partie qui devrait prendre beaucoup plus de temps : la création.

Car si Mugen est déjà attrayant par le fait de pouvoir mélanger des éléments issus de jeux et d’univers différents, son véritable but est de permettre à l’utilisateur de créer ses propres éléments, pour obtenir un jeu original.

Toute création se décompose en 2 parties : d’un côté, la partie « média » (images & son) et de l’autre, la partie code. La partie media fait bien sûr appel à des talents d’artiste. Ce n’est donc pas un domaine où on peut véritablement expliquer comment s’y prendre, et en tout cas, ce n’est pas le but de ce site. En outre, la majeure partie des créateurs reprennent des graphismes et des sons pré-existants en les extrayant notamment des jeux consoles/arcade. C’est ce qu’on appelle le rip, et on aura l’occasion d’en développer les grandes lignes ultérieurement.

Ce qui va nous intéresser dans la partie media, c’est la façon de l’intégrer dans Mugen. Aujourd’hui, nous allons notamment nous intéresser aux traitements des images.

Dans Mugen, les images d’un élément, quel qu’il soit, sont regroupées dans un fichier SFF (et ce même s’il n’y a qu’une seule image). Donc une fois qu’on a réuni les images à utiliser (qu’on les ait crées ou ripées), il faut les « compiler » dans un fichier SFF afin que Mugen puisse les exploiter. Pour cela, nos images doivent respecter certaines petites conditions.

Deux conditions incontournables

Tout d’abord, les images doivent être en 256 couleurs indexées (ou 8-bits). C’est une opération que la plupart des logiciels de dessin, même les plus simples, savent faire. Un exemple avec Irfan View (gratuit) :

La seconde condition, c’est que ces images doivent être au format PCX. Là encore, nombre de logiciels permettent de convertir des images JPG ou BMP (par exemple) au format voulu. A nouveau, Irfan View fait cela très bien :

A savoir : Depuis l’arrivée de la version Windows 1.0 de Mugen, Elecbyte a mis à jour son format SFF. L’ancienne version du SFF est maintenant dénommée « SFFv1″, et la nouvelle « SFFv2″, lorsqu’il y a besoin de les distinguer. Pour des raisons de rétro-compatibilité avec les milliers de créations existantes, la version 1.0 lit aussi bien les SFFv1 que les SFFv2. En revanche, les anciennes versions de Mugen ne liront, bien sûr, que les SFFv2. On peut également penser que dans un futur plus ou moins lointain, lorsque le SFFv2 se sera généralisé, le SFFv1 ne sera plus supporté.

Quelles sont les différences entre les SFFv1 et v2 ? Ce sont surtout beaucoup de points de détails qu’on ne va pas présenter ici. Retenez, pour le sujet du jour, que le SFFv2 supporte également le format PNG en plus du PCX.

Histoire de palettes

A partir du moment où vous vous lancez dans la création, vous allez souvent entendre parler de « palettes ». Qu’est-ce donc ? Les palettes sont en fait un tableau listant les couleurs (avec leurs valeurs RVB) utilisées dans l’image (ou pas, d’ailleurs !). Dès que vous passez à 256 couleurs (ou moins), votre image aura une palette. Là encore, la plupart des logiciels de dessin sont en mesure d’afficher la palette d’une image, voire de l’éditer :

Pour expliquer rapidement les palettes : chaque couleur dans la palette possède un numéro d’index (de 0 à 255), et chaque pixel dans l’image est associé à un numéro d’index. En conséquence, si on modifie la couleur d’un index, ça modifie la couleur de tous les pixels qui utilise cet index. En outre, il est possible d’enregistrer et de charger des palettes. Si on charge une palette qui utilise des couleurs différentes de la palette d’origine de l’image, on change les couleurs dans l’image. C’est sur ce principe que fonctionnent les différentes tenues des personnages dans Mugen.

La couleur « transparente »

Les deux conditions ci-dessus sont le B.A.BA de la création Mugen. Si elles sont respectées, vos images pourront être lues dans un SFF. Mais on peut trouver d’autres subtilités dans l’utilisation des images, et l’une d’entre elles est la notion de « couleur transparente ».

A retenir : La notion de « transparence » est assez floue dans Mugen, car elle désigne abusivement deux notions. La première se rapproche du concept « d’opacité partielle », c’est à dire que l’on voit un objet, mais que l’on peut également voir au travers pour distinguer ce qui se trouve dessous (comme par exemple lorsque vous regardez à travers une vitre colorée). La seconde notion, celle que nous allons voir ici, est celle de « l’invisibilité » (c’est à dire qu’une partie de l’image n’est pas affichée à l’écran). Attention de bien les distinguer selon le contexte…

Une image est toujours un rectangle, faisant X pixels de large et Y pixels de haut. Ceci est fondamentalement vrai, et ne souffre aucune exception. Mais alors, comment se fait-il qu’en jeu, nous ayons l’image de gauche, et non pas celle de droite ?

En fait, on utilise la même image, mais à droite, on a l’image « brute », alors qu’à gauche, la couleur de fond n’est pas affichée, ce qui donne l’illusion que l’image n’est pas un simple rectangle.

Pour pouvoir utiliser cette fonctionnalité dans Mugen, la couleur de fond doit être celle en index 0 (ou pour reprendre l’explication donnée avant, les pixels que l’on veut rendre invisibles doivent être associés à l’index n°0). Si vous regardez l’image précédente de Link, vous verrez que la couleur de fond (rose bonbon) correspond à l’index 0 dans la palette, et donc tous ces pixels roses ne seront pas affichés dans le jeu.

Le rognage : un gain de place, une manipulation plus facile

Le rognage consiste à découper l’image sur l’un de ses côtés. Lorsqu’on travaille sur les images (rip ou création), on part souvent d’une image large, et on enlève en fin d’opération les éléments superflus. Il se peut alors que votre image soit complètement entourée de fond. Dans ce cas, il faut rogner l’image sur les côtés de façon à ce qu’il y ait au moins un pixel « utile » sur chaque bord. L’intérêt, c’est que vos images seront plus petites et prendront moins de place, et qu’en outre, sprmaker rognera de toute façon vos images, ce qui risque alors de vous poser des problèmes pour placer votre image dans le SFF (on verra ça une prochaine fois).

Le ton est donné, je ne vais pas être forcément très tendre avec cette méthode. Déjà parce qu’elle ne correspond pas au standard de Mugen, ensuite parce qu’à force de manipulations, ça peut devenir un grand n’importe quoi dans votre Mugen.

Le principe de la « méthode officielle » consiste donc à installer séparément les screenpacks, de sorte qu’ils peuvent co-exister sans se « parasiter ». On peut donc les activer et les désactiver très facilement, sans faire de manipulations complexes. Le « petit » défaut, c’est qu’on peut se retrouver avec plusieurs screenpacks installés, mais un seul activé, donc tous les autres prennent de la place pour rien. Mais bon, à l’heure où les disques durs de base comptent plusieurs centaines de Go, c’est assez relatif, comme problème…

La méthode « bourrin », elle, consiste à « Ã©craser » le screenpack existant avec le nouveau.

0. Faire une sauvegarde de secours !

Comme on l’a dit, le principe de la méthode « bourrin » consiste à écraser les anciens fichiers par des nouveaux. Le hic, c’est que comme on le verra plus loin (avec le pourquoi), il arrive que ces manipulations ne donnent pas le résultat escompté (le screenpack ne fonctionne qu’à moitié, voire Mugen refuse de se lancer, ou ne fonctionne plus comme vous l’aviez configuré, etc.).

Comme on aura écrasé les anciens fichiers, le seul moyen de faire marche arrière sera de posséder un backup, un copie de sauvegarde.

Que faut-il sauvegarder ? Pour être sûr, les dossiers data/ et font/. Une fois que votre screenpack est installé et fonctionne convenablement et que vous ne souhaitez pas revenir en arrière, n’oubliez pas de détruire votre copie. Bah oui, le principal intérêt de la méthode étant de consommer moins de place, ce serait paradoxal de conserver votre sauvegarde, dans la mesure où l’effet obtenu serait de consommer en fait plus d’espace disque…

1. L’emplacement des fichiers… c’est de l’aléatoire…

L’idée de base, c’est que les fichiers utilisés (system.def, fight.def, etc.) vont se retrouver non plus dans un sous-dossier de data/, mais directement DANS data/, les nouveaux fichiers venant remplacer les anciens.

Seulement voilà, dans Mugen, on peut avoir différent niveaux de complexité dans les screenpacks. Vous pouvez avoir un screenpack basique (comme c’est un peu le cas de celui fourni par défaut). Mais vous pouvez également avoir plus de polices, une intro, une ending, un logo, des crédits, des musiques, etc. qui feront plus de fichiers. Dans le screenpack Castlevania, j’ai même inclus des stages !

Et là, on a deux écoles : certains vont mettre tous les fichiers dans le même dossier (en l’occurrence, data/), alors que d’autres vont juste garder les fichiers essentiels (system.def, et fight.def) à la racine de data/ et placer les autres dans des sous-dossiers (style SFF/ pour les SFF, Music/ pour les musiques, etc.). Du coup, l’architecture d’un SP « bourrin » varie selon le cas.

Ca commence à devenir chaotique lors de l’extraction des fichiers : si certains vont prendre la peine de vous laisser des instructions (on en revient à l’importance des readme), et d’organiser convenablement les fichiers, d’autres vous laisseront vous débrouiller par vous-mêmes : les fichiers seront extraits pêle-mêle, et à vous de deviner dans quel dossier ils vont ! Si pour certains fichiers, c’est assez évident (le system.def va dans le dossier data/), pour d’autres, c’est un peu au hasard (les polices vont-elles dans le dossier fonts/ ou dans le dossier data/ ?).

Comme on parle de remplacement de fichier, vous allez être confrontés inévitablement aux écrans de ce type :

Avec ce que cela implique implicitement : l’impossibilité de revenir en arrière (à moins de faire un backup préalable, ce dont la plupart des utilisateurs se passent même s’ils en reconnaissent l’utilité, et malgré l’avertissement que j’ai mis au point 0…).

2. Activer le screenpack… avec un peu de chance !

Une fois que vous avez placé correctement les fichiers (ou en tout cas, quand vous supposez que c’est le cas), il n’y a rien d’autre à faire. Le fichier système ayant été remplacé, le chemin spécifié dans le mugen.cfg est correctement paramétré (à moins que le nom du fichier système soit différent, mais je n’ai jamais vu le cas jusqu’ici).

Donc, il ne reste plus qu’à lancer Mugen pour vérifier le résultat… et éventuellement constater l’étendue des dégâts !

Là, avec un peu de chance, tout devrait aller à peu près correctement. Dans le pire des cas, vous aurez des éléments qui ne sont pas complémentaires graphiquement (imaginez une interface Mortal Kombat avec des lifebars Street Fighter Alpha, par exemple…), mais qui n’empêche pas Mugen de fonctionner.

Pourquoi ces différences ? On l’a dit avant : les screenpacks sont plus ou moins complexes et comprennent plus ou moins de fichiers. La forme de screenpack la plus basique est la simple interface (les menus, les différents écrans), sans lifebars. Et donc, imaginons que vous ayez installé un screenpack complet « Street Fighter Alpha » (interface & lifebars), et que par-dessus, vous installiez un screenpack Mortal Kombat avec juste l’interface : vos fichiers de lifebars ne sont pas remplacées, et sont donc utilisées avec la nouvelle interface. Maintenant, imaginez ce que ça peut donner après des dizaines d’installations successives : avec tous ces screenpacks « empilés », on se retrouve avec l’interface d’un screenpack, les sons d’un autre, les lifebars d’un troisième, les « FX » (effets lumineux) d’un quatrième, les polices d’un cinquième… Bref, ça devient du beau n’importe quoi.

Mais ce n’est pas le pire qui puisse vous arriver. J’ai vu il y a quelques années un screenpack livré avec un fichier common1.cns. A la base, ce n’est pas très gênant puisque c’est un fichier qu’on modifie rarement. Sauf dans des cas très particuliers. Le premier, c’est quand vous installez un jeu complet. Dans ce cas, le common1.cns peut être modifié (en gros, ce fichier contient le code des actions « courantes » des personnages : marcher, reculer, sauter, etc. : comme ces actions seraient codées de la même façon pour pratiquement tous les personnages, Elecbyte les a codées dans ce fichier, ce qui évite au créateur de personnage de le faire). Pour un Mugen « classique », pas de souci, mais pour un jeu complet, le(s) créateur(s) vont plutôt adapter le common1.cns à leurs besoins plutôt que de réécrire pour chaque personnage toutes les parties de ce fichier qu’ils veulent adapter pour leur jeu. Un autre cas, assez similaire, est celui où l’utilisateur est assez expérimenté et souhaite modifier les actions de base pour tous ses personnages, afin de les adapter à ses désirs. Dans ce cas, il modifiera directement le common1.cns. Et donc, si on installe notre « screenpack de bourrin » sur ces configurations, on perd le common1.cns, avec des conséquences plus ou moins grandes selon les modifications qui avaient été effectuées…

Terminons quand même par le top du top, sur lequel je suis tombé une fois : un inconscient a cru bon d’inclure dans son screenpack le fichier mugen.cfg ! Avec évidemment la ligne « motif » modifiée pour que l’utilisateur puisse « profiter » de son screenpack déjà installé… Seulement, vous devez vous rappeler qu’on a déjà évoqué ici toute l’utilité de ce fichier : il vous permet de configurer Mugen (niveau de vie, vitesse de jeu, résolution, sons…), et notamment les boutons de jeu ! Donc avec un tel fichier, vous perdez tous vos réglages !

Pas bien méchant, me direz-vous, il suffit de tout reconfigurer ! Oui, mais ça, c’est le scénario idéal, ma bonne dame ! Parce que dans les faits, il y a aujourd’hui 90% de chances que vous utilisiez le nouveau Mugen 1.0, et 90% de chances que notre screenpack soit prévu pour une autre version. Et d’une version de Mugen à l’autre, le fichier mugen.cfg a connu de subtiles modifications, si bien qu’au final, vous avez perdu votre fichier avec vos réglages, vous n’avez plus le fichier d’origine, et vous n’avez qu’un fichier mugen.cfg prévu pour une autre version, et qui fera donc planter Mugen lorsque que vous le lancerez !

4. Conclusion

Au départ, ce système d’installation se veut plus simple (on remplace juste les anciens fichiers par les nouveaux), mais à l’arrivée, les failles de cette méthode sont nombreuses, et même dangereuses pour certaines !

Récapitulons la comparaison entre les deux méthodes :

Avantages de la méthode « bourrin » :

• Mugen prend moins de place (à condition de ne pas faire de sauvegarde de secours)

Avantages de la méthode « classique » :

• Plusieurs screenpacks peuvent co-exister de façon indépendante,
• Les fichiers de chaque screenpack sont dans des dossiers séparés ce qui évite les mélanges hasardeux,
• Ce système de sous-dossiers facilite l’extraction des fichiers,
• Avec ce système, on sait où trouver tous les fichiers d’un même screenpack (pratique pour la suppression),
• Si un screenpack pose problème, il est possible (et très simple) de revenir en arrière,
• On peut désactiver un screenpack sans le désinstaller,
• La méthode d’installation est toujours la même,
• On ne touche pas aux fichiers « système » de Mugen comme le common1.cns ou le mugen.cfg, et on ne risque donc pas de perdre ses réglages.

Si vous avez le choix entre un screenpack « bourrin » et un screenpack classique, vous savez désormais lequel choisir, et si vous décidez de créer des screenpacks, vous savez également quelle méthode d’installation choisir…

Tout d’abord, qu’est-ce qu’un readme ? En français, ça se traduit littéralement par « lis-moi » (ou « lisez-moi », comme vous voulez). Les readme, on en trouve un peu partout, et pas seulement dans Mugen, loin s’en faut. Ce sont des espèces de notices, qui contiennent des informations plus ou moins importantes sur les fichiers qu’ils accompagnent.

Pour l’utilisateur de PC lambda, les readme sont un peu comme des notices classiques : on ne les lit jamais, ou juste pour y trouver une information précise.

Aussi, quand on débute dans Mugen, on fait souvent de même : on ignore les readme, et on se concentre uniquement sur les fichiers. Sauf qu’au moindre problème, on s’empresse d’aller demander sur un forum Mugen, où l’on se fait méchamment envoyer balader avec des « t’as qu’à lire le readme ! ». Retour à la case départ donc.

Dans Mugen, il se trouve que les readme ne sont pas de simples fichiers figuratifs où l’auteur assène une licence de 2000 lignes, ou un historique de tous les changements apportés, ou encore un roman sur ce qui l’a poussé à faire cette création. Bien sûr, on peut y trouver ces éléments qui n’auront que peu d’intérêt pour la plupart des joueurs, mais pas seulement.

Les readme contiennent également des données importantes concernant l’installation de l’élément concerné, et leur utilisation. Par exemple, pour un personnage, le readme pourra vous donner la liste des mouvements, mais aussi expliquer comment activer une version alternative, comment utiliser un mode de jeu, comment fonctionne tel système de jeu inclus dans le personnage, etc.

Bref, pour profiter au mieux d’une création, la lecture du readme est pratiquement indispensable, ne serait-ce que partiellement.

Les readme se présentent sous bien des aspects ; pour les créations basiques (stages, screenpacks…), les readme sont le plus souvent de simples fichiers TXT. En revanche, pour les persos, on peut aller du fichier TXT sobre (comme pour KFM) au fichier HTML détaillé et illustré (ex. avec Link ou Gouki, ici).

La partie suivante est plutôt destinée aux créateurs (ou à ceux qui ambitionnent de le devenir) :

Créer des readme lisibles pour les personnages est certes une contrainte pour les créateurs, mais il est évident que si le readme de KFM, court et réduit au minimum, peut se contenter du format TXT, celui de Link ne le peut pas : la lecture serait très fastidieuse pour le joueur, qui abandonnerait très vite, n’y reviendrait pas, et passerait ainsi à côté de certains aspects intéressants du personnage. La présentation par menu, avec illustrations sert à aider le lecteur à trouver ce qu’il cherche (rares sont les joueurs qui liront le TXT de A à Z d’une seule traite…), et à mieux comprendre ce qu’il lit.

De même, on doit garder à l’esprit que Mugen est international. Pour que le readme soit utile à tous, il faut donc le rédiger en une langue accessible à tous, et là, on en revient à l’article précédent : l’anglais est incontournable. Donc, créateurs, si vous souhaitez rédiger votre readme en français, pensez également à faire une traduction en anglais. Et en tant que simple lecteur, la plupart des readme que vous verrez seront en anglais, d’où la nécessité, là encore, de maîtriser un minimum l’anglais, que vous soyez joueur ou créateur.

On va faire une pause nécessaire dans l’explication de l’installation des composants de Mugen.

Sous le titre de cet article, librement emprunté à un certain humoriste, on va parler de la maîtrise de l’anglais. Dans Mugen, et plus généralement dans l’informatique, l’anglais est partout, et le maîtriser est presque indispensable.

Par chance, les outils de traduction sont aujourd’hui plus performants qu’ils ne l’étaient il y a encore quelques années, même si tout n’est pas parfait.

Pourquoi l’anglais ? Parce qu’il est omniprésent, à tout niveau :

• Dans la documentation Mugen, source à privilégier lorsque vous tenter de résoudre un problème avec Mugen,
• Dans les sites & forums (Elecbyte, Mugen Guild, RandomSelect, etc., les sites et forums francophones étant assez peu vivants ces derniers temps),
• Dans le code Mugen (ex : en sachant que « Not » exprime une négation, que « Hit » signifie « touché » et « By » signifie « par », on peut déjà avoir une bonne idée de ce que fait un « NotHitBy » avant même de lire la doc sur cette fonction…),
• Dans les « readme » (on y reviendra prochainement).

Bref, l’anglais est un peu partout. Il se trouve que Mugen a une portée mondiale, et que tout le monde ne parle pas le français (ou le japonais ou le portugais ou l’espagnol, etc.), et que l’anglais reste la langue la plus universelle. Vous n’y couperez donc pas.

Au-delà du vocabulaire « traditionnel », scolaire que vous pourrez retrouver çà et là, vous verrez que les anglophones utilisent des termes parfois obscurs, équivalents à nos « diminutifs » francophone (ex : « aprem » pour « après-midi »). Si ceux qui ont l’anglais pour langue maternelle s’en débrouillent assez bien, il faut reconnaître que ce n’est pas toujours évident pour ceux qui ont appris l’anglais à l’école, et qui ne maîtrisent donc qu’un anglais très « basique ». On vous enseignera en effet davantage une phrase comme « Come on, what are you doing ? » plutôt que « c’mon, whad’ya doin’ ?».

Et je ne vous parle même pas des sigles comme AFAIK (As Far As I Know), IIRC (If I Recall Correctly), IINM (If I’m Not Mistaken), etc. Bref, les équivalents anglais de nos « OSEF » et compagnie.

Bref, si vous voulez pratiquer Mugen, il vous faudra apprendre/réviser un minimum d’anglais courant…

La seule consolation pour ceux qui sont fâchés avec la langue de Shakespeare, c’est que les anglophones sont quand même moins « kikoo lol » que les francophones : quand ils écrivent des messages, ça reste assez compréhensible dans l’ensemble, et on n’a pas besoin de décrypter mot à mot comme c’est parfois le cas avec le style SMS de certains (prétendus) francophones. On ne trouve donc pas de version anglaise de « komen on fé pr avoir + de perso? ». C’est toujours ça de pris…

Elecbyte a sorti un nouveau trigger Cond dans sa RC6, qui semble un peu surprenant à première vue. En effet, il se présente et fonctionne globalement à l’identique du trigger IfElse, et semble donc redondant.

Pour rappel, le IfElse fonctionne ainsi : IfElse(exp_cond, exp_vrai, exp_faux) = exp_vrai si exp_cond est vrai, ou exp_faux sinon (ça ressemble donc assez à un « SI() » dans Excel ou Calc). Donc Cond fonctionne de la même façon. Par exemple :

value = IfElse(var(0)=1,4,-4)

et

value = Cond(var(0)=1,4,-4)

sont rigoureusement équivalent (si var(0) = 1, alors value prendra la valeur 4, et sinon, value prendra la valeur -4.

Il y a pourtant une subtile différence entre IfElse et Cond : avec un IfElse, quelque soit le résultat, toutes les expressions qui composent le IfElse sont lues et évaluées, même si elles ne sont pas utilisées (par exemple, si exp_cond est vrai, on n’a pas besoin de exp_faux, mais exp_faux sera quand même lu). En revanche, avec Cond, seules les expressions nécessaires sont lues et évaluées (donc dans le même cas, cette fois, exp_faux ne sera pas lu).

Quelle différence ? Dans un cas comme celui donné en exemple plus haut, aucun, c’est certain. Mais il existe certains cas où la différence peut être assez flagrante, notamment avec l’assignation de variable.

L’assignation de variable consiste à évaluer une expression ou une partie d’expression tout en attribuant la valeur de cette expression à une variable. Par exemple :

value = var(0):=5+RoundNo

Si RoundNo vaut 1, value vaudra 6, et var(0) aussi. Le signe « := » indique que l’expression située à droite du signe doit être attribuée à var(0) (comme le ferait un VarSet). En fait, si on décompose l’expression, on dit à Mugen que value doit prendre la valeur de var(0), qui doit elle-même prendre la valeur de 5+RoundNo.

Revenons à nos triggers Cond et IfElse, et imaginons le cas suivant :

value = IfElse(RoundNo>1,var(1):=RoundNo,var(1):=-RoundNo)

Ici, var(1) est censé prendre la valeur de value, à nouveau : si RoundNo>1, alors value retourne RoundNo, qui est attribué à var(1), et si RounNo n’est pas >1, alors value retourne -RoundNo, qui est attribué à var(1). Bref, var(1) est censé prendre la même valeur que value.

Du moins, en théorie. En pratique, comme toutes les expressions de IfElse sont lues et évaluées, var(1) vaudra toujours -RoundNo, quelle que soit la valeur de value. Pourquoi ? Parce que Mugen lit la chaîne dans son intégralité, et la dernière expression qu’il lit (de droite à gauche) est l’assignation de -RoundNo à var(1), et ce même si value vaut RoundNo, au final.

C’est là qu’intervient Cond. En remplaçant simplement IfElse par Cond, on change le comportement de Mugen :

value = IfElse(RoundNo>1,var(1):=RoundNo,var(1):=-RoundNo)

Ici, l’expression inutile n’étant pas lue, on est certain que var(1) correspondra bien à value (si value vaut RoundNo, alors var(1) = RoundNo, et si value vaut -RoundNo, alors var(1) = -RoundNo).

Une différence subtile, certes, mais qui peut avoir son importance dans certains cas.

Mais dans ce cas, pourquoi ne pas avoir simplement modifié le fonctionnement de IfElse ? Très probablement parce que certains créateurs ont du exploiter le comportement initial du IfElse, et donc si le IfElse venait à se comporter comme le Cond, les personnages de ces créateurs ne fonctionneraient plus comme prévus. C’est donc à des fins de rétro-compatibilité qu’Elecbyte a choisi d’ajouter un trigger légèrement différent du IfElse plutôt que de le modifier.

L’interface de base de Mugen peut rapidement apparaître comme limitée ; en effet, au regard des milliers de personnages disponibles sur le Net, la grille de sélection de 10 personnages peut rapidement sembler frustrante. En outre, les graphismes de cette interface n’étant pas extraordinaire, on peut être tenté de se tourner vers quelque chose de plus « luxueux ».

Comme on l’a vu précédemment, les apparences graphiques de Mugen sont appelées « screenpacks », et ce sont ces éléments que l’on va voir aujourd’hui.

Sachez d’ores et déjà qu’il y a 2 méthodes pour installer un screenpack, et qu’elle ne dépend pas toujours de l’utilisateur. La première méthode est la méthode « officielle », celle que je vous présente dans cet article. Sachez toutefois que cette méthode n’est malheureusement pas la plus répandue. La seconde est la méthode « bourrin », que je vous présenterai ensuite.

La méthode officielle consiste à placer les screenpacks dans des sous-dossiers du dossier data/. Ensuite, il suffit de modifier le chemin pointant sur le fichier principal du screenpack. Cette méthode a de loin ma préférence.

1. Placement des fichiers

Pour les screenpacks utilisant cette méthode, lorsque vous extrayez les fichiers, vous vous retrouvez normalement avec un unique dossier au sein duquel sont regroupés les fichiers et les éventuels sous-dossiers.

Il ne vous reste alors plus qu’à placer ce dossier dans le dossier data/ de Mugen :

Exemple avec mon screenpack Heroic Fantasy : vous avez un unique dossier nommé Heroic, à placer dans le dossier data.

2. Trouver le nom du DEF

Comme on l’a vu dans le précédent article, chaque élément est articulé autour d’un fichier DEF. Pour les screenpacks, il s’agit du fichier system.def.

Notez que le nom « réel » de ce fichier peut varier d’un screenpack à l’autre. C’est rarement le cas, mais cela arrive (je l’ai notamment fait avec mes premiers screenpacks…). Donc, quand je parle de « system.def », j’utilise un terme « générique » pour désigner le fichier DEF autour duquel s’articule le screenpack. Néanmoins, le nom est souvent assez explicite pour être retrouvé (ex : pour mon screenpack Zelda, j’ai utilisé le nom « sysZelda.def »).

Un coup d’oeil dans le dossier du screenpack vous renseignera rapidement sur le nom du fichier à utiliser :

Le fichier system à repérer dans le dossier du screenpack

Ici, on constate que le fichier system est appelé « sys.def ».

3. Activer le nouveau screenpack

Vous allez devoir ouvrir le fichier mugen.cfg qui se trouve dans le dossier data/. Dans le premier groupe [Options], vous verrez que le dernier paramètre ressemble à ceci :

; Set the motif to use.
; Motifs are themes that define the look and feel of MUGEN.
; This is not accessible in options screen.
motif = data/system.def

Ce paramètre désigne le fichier DEF du screenpack à utiliser. Il suffit de le modifier pour le faire pointer sur le fichier system du nouveau screenpack. Ici, puisque notre screenpack est dans un dossier Heroic, et que le fichier system s’appelle sys.def, on devra mettre ceci pour utiliser le nouveau screenpack :

; Set the motif to use.
; Motifs are themes that define the look and feel of MUGEN.
; This is not accessible in options screen.
motif = data/Heroic/sys.def

Et voilà !

Le nouveau screenpack est activé !

NB : Oui, j’ai triché, j’ai repris une capture d’un vieux Mugen, mais le résultat est le même…

4. Conclusion

Cette méthode, comme je l’ai dit, présente de très nombreux avantages par rapport à l’autre. Néanmoins, il serait prématuré de les lister ici étant donné que je n’ai pas encore présenté l’autre méthode.

On regrettera simplement que cette méthode ne soit pas plus répandue.

Si vous fouillez un peu le dossier data/, vous découvrirez que Mugen est en fait livré avec 4 screenpacks !

1. Celui de base, en nuance de gris/argent, qui se trouve dans le dossier « mugen1/ »,
2. Celui d’origine, tout bleu, qui était présent dans les anciennes versions de Mugen, et qui se trouve dans le dossier data/ directement.
3. Une version « 60 slots » (1 slot est un emplacement pour un personnage dans la grille de sélection, donc 60 slots = qui peut contenir 60 personnages) du thème de base gris/argent, qui se trouve dans le dossier « big/ »
4. Une version « spéciale KFM » avec un menu en bambou, un logo et une intro de jeu. Les autres écrans (options, sélection, versus) sont identiques à la version de base.

Pour ces 4 screenpacks, les lifebars sont les mêmes. A vous de faire les manips nécessaires pour tester ces différents screenpacks !

Jusqu’ici, nous avons vu des éléments assez simples à installer dans Mugen. Néanmoins, pour la suite, il est préférable de comprendre globalement l’architecture des fichiers dans Mugen.

Une image étant parfois plus parlante que de longs discours, voici globalement, et de façon très simplifiée, comment cela se présente :

(Cliquez pour agrandir)

Les flèches représentent « l’appel » des fichiers. Ainsi quand vous lancez mugen.exe, celui fait appel au mugen.cfg pour connaître les paramètres généraux à appliquer. Le fichier mugen.cfg fait lui-même appel au fichier system.def pour charger le screenpack, qui lui même appelle le fight.def pour charger les lifebars, et au select.def pour charger les personnages et les stages.

Comme vous le remarquez peut-être, le point de départ d’un élément (personnage, stage, screenpack, etc.) est à chaque fois un fichier DEF. Ce fichier contient le plus souvent du code (sauf pour les personnages), mais aussi un certain nombre de paramètres, et notamment les « sous-fichiers » utilisés par l’élément associé (ex : les sous-fichiers inclus dans le DEF d’un stage sont le SFF (fichier contenant les images du stage) et l’éventuel MP3 (le fichier musique ; j’ai mis MP3 car c’est le format le plus commun, mais Mugen supporte d’autres formats…).

Vous n’avez pas spécialement besoin de connaître ce schéma par coeur, heureusement. Mais ce qu’il faut en retenir, c’est que chaque élément est caractérisé par un fichier DEF, qui est le fichier central de cet élément (pour le screenpack, il s’agit du « system.def », pour les lifebars, du « fight.def », etc.).

L’installation des stages dans Mugen n’est pas très compliquée. Un décor ne se compose que de 2 fichiers : un fichier DEF et un fichier SFF, les deux portant théoriquement le même nom. Il peut parfois y avoir d’autres fichiers (un readme, et/ou un fichier musique) lorsque vous décompressez un stage, mais nous verrons cela après.

1. Placer les fichiers

Par défaut, tous les fichiers d’un stage se mettent dans le dossier stages/ de Mugen.

C’est tout ? Oui, c’est tout !

2. Déclarer le stage dans Mugen

Pour déclarer un stage dans Mugen, de façon à ce qu’il soit utilisable, vous avez 2 possibilités :

• L’affecter à un personnage en particulier : dans ce cas, lorsque vous affronterez le personnage en question, ce sera forcément dans ce stage,
• Le déclarer en « stage libre » ( »Extra stage »).

Les deux solutions sont légèrement différentes, mais dans tous les cas, comme pour les personnages, tout se passe dans le select.def du dossier data/.

2.1 Affecter un stage à un personnage

Pour affecter un stage à un personnage, vous devez d’abord trouver ce personnage dans la liste. En théorie, votre liste de personnage doit un peu se présenter comme ceci :

Personnage 1
Personnage 2
Personnage 3

Pour affecter un stage à l’un de ces personnages, vous devez simplement ajouter une virgule suivie du nom du fichier DEF, en spécifiant le dossier « stages/ ». Par exemple, pour affecter le stage « mon_stage.def » à Personnage 2, mon select.def devra ressembler à ceci :

Personnage 1
Personnage 2, stages/mon_stage.def
Personnage 3

A partir de là, lorsque j’affronterai Personnage 2 en mode Arcade, ce sera forcément dans le stage « mon_stage.def ».

Notez que KFM a déjà un stage déjà attribué, puisque par défaut, le select.def contient ces lignes :

kfm, stages/kfm.def
kfm720, stages/kfm.def

Vous pouvez bien entendu changer sans souci un stage déjà affecté (il suffit de changer le nom du DEF).

2.2 Ajouter un stage libre

Si vous souhaitez ajouter un décor dans Mugen sans l’affecter spécialement à un personnage, voici la marche à suivre. Dans ce cas, les stages s’ajoutent un peu comme les personnages : il faut les ajouter dans le groupe [ExtraStages] du select.def (juste après les personnages).

Donc si je veux ajouter le stage « mon_stage.def », mon select.def ressemblera à ceci :

[ExtraStages]
;Put extra stages here. They will be available in VS and Watch modes.
;For example, you can insert « stages/mybg.def ».
stages/stage0-720.def
stages/mon_stage.def

Attention ! Vous ne devez pas à la fois attribuer un stage à un personnage et l’ajouter en [ExtraStages], sinon, le stage apparaîtra 2 fois dans la liste des stages (en mode Training ou Watch, par exemple).

3. Je ne retrouve pas mon stage !

Eh oui, c’est le gros problème posé par les décors : le nom que l’on entre dans le select.def correspond rarement au nom « réel » du stage. Par exemple, vous aurez peut-être remarqué que le stage assigné à KFM s’appelle sobrement « kfm.def ». Or dans votre liste de stages, il s’appelle « Mountainside Temple » !

Comment retrouver vos stages dans ce cas ? Il y a 2 grandes solutions : la première consiste à repérer la position du stage dans le select, et à retrouver sa correspondance dans Mugen (puisque les stages sont numérotés). Seul problème, ça devient compliqué lorsqu’on attribue des stages à des persos, et qu’on a en plus des Extra Stages.

Deuxième solution : retrouver le nom « réel » du stage. Pour cela, il suffit d’ouvrir le DEF du stage (avec un éditeur de textes quelconque, comme pour le select.def), et de regarder la valeur du paramètre « name » dans le groupe [Info] (le premier, en tête de fichier). Par exemple, dans le stage kfm.def, on trouve ceci :

; Definition of KFM’s stage
; *** denotes values you should change/check for each stage.
; The term « background » is used to mean both backgrounds and foregrounds.

;——————————————————–
[Info]
;Name of the stage.
name = « Mountainside Temple »

;——————————————————–

Qui nous indique donc que le stage sera nommé « Mountainsisde Temple » dans Mugen.

Avant d’aller plus loin dans les installations de composants, et maintenant que vous savez utiliser l’essentiel, à savoir, les personnages, on va pouvoir s’arrêter un court instant sur les différents éléments que l’on peut inclure dans Mugen.

• Personnages : Pas besoin de s’étendre, j’imagine… Appelés « chars » ou « characters » en anglais.
• Stages : C’est le « nom » officiel qu’on donne aux décors (on utilise parfois le terme « background » (abrégé BG), mais ça peut prêter à confusion dans certains cas). Ce sont les décors dans lesquels les personnages combattent.
• Lifebar : Ce sont, littéralement, les « barres de vies ». Concrètement, ça inclut tout les éléments « système » à l’écran lors d’un combat : les barres matérialisant la vie des personnage, celles représentant leur « power », les animations de « KO », de « Round X, Fight ! », l’apparence du compteur de combo, etc. Abrégé parfois en LB.
• Screenpack : C’est un peu la même chose, mais cette fois hors combat. Concrètement, ça revient à dire qu’un screenpack (pack d’écran, en français) est l’interface graphique du jeu : apparence du menu principal, du menu option, de l’écran de sélection des personnages et de l’écran « versus ». Par extension, un screenpack se voulant une interface graphique, ce terme englobe souvent les lifebars associés à ces écrans. Notez aussi que le screenpack règle aussi un certain nombre de paramètres de jeu, tout comme les lifebars, d’ailleurs. Abrégé en SP.
• Motif : C’est le terme officiel pour le sens « Ã©tendu » du mot screenpack. Donc Motif = screenpack au sens strict + lifebar. Néanmoins, ce terme est très peu utilisé
• Storyboard : Les storyboards sont des scènes cinématographiques qui sont jouées à certains moment précis du jeu. On en distingue 7 :
  • Logo : jouée au lancement du jeu,
  • Intro de jeu : jouée juste après le logo, avant d’arriver au menu principal
  • Fin de jeu : jouée après que le joueur a terminé un mode Arcade, s’il n’y a pas de Fin de personnage,
  • Crédits : jouée après le storyboard Fin de jeu,
  • Game Over : jouée lorsque le joueur a perdu un combat en mode Arcade et ne continue pas,
  • Intro de personnage : jouée au début du mode Arcade, avant le premier combat,
  • Fin de personnage : jouée après que le joueur a terminé un mode Arcade,

  Tous les storyboards sont facultatifs dans Mugen. On les abrège en « SB ».

Chacun de ces éléments se décompose parfois en « sous-composants ». Par exemple, les personnages peuvent avoir (pour ceux créés pour des anciennes versions de Mugen) des palettes proposées séparément, les lifebars peuvent avoir des jeux de « sparks » alternatifs, etc. (pour information, les « sparks » sont des éclats de lumière qui surviennent par exemple lors d’un coup, et matérialisent ainsi l’impact).

Cet article est un peu un « addendum » des 2 précédents. A ce stade, vous savez installer 99.99% des personnages dans Mugen, et ceci ne vous servira donc pas énormément. Néanmoins, c’est toujours intéressant de savoir que ça existe.

Il arrive parfois que des créateurs créent plusieurs versions d’un même personnage, où seul un ou deux fichiers va changer (code, sprites, anims…). Dans ce cas, le créateur prend généralement soin d’inclure non pas un unique fichier DEF, mais plusieurs : un pour chaque version.

Dans cette situation, il y a un fichier DEF « par défaut », et les autres sont des versions alternatives (d’où le titre de l’article). Attention ! Tout fichier DEF dans un dossier de personnage n’est pas forcément une version alternative du personnage ! En effet, les intros et fins de personnage, évoqués dans le précédent article, sont aussi notamment composés d’un fichier DEF. Comment les distinguer ? En général, les DEF se rapportant à une intro ou à une fin portent des noms assez clairs : « intro.def » ou « ending.def », ou dérivés.

Et comment distinguer le fichier DEF « principal » des DEF « alternatifs » ? Là encore, le nom de fichier devrait vous mettre sur la piste : les versions alternatives auront le plus souvent un « -alt » dans leur nom. A l’inverse, le DEF principal correspondra souvent directement au nom du personnage. Par exemple, pour KFM, on pourrait imaginer que la version principale s’appelle « kfm.def » et une éventuelle version alternative s’appellerait « kfm-alt.def« .

Attention, ce n’est pas une règle incontournable ! On peut ainsi imaginer des versions alternatives basées sur le mode de jeu, qui s’appelleraient « kfm-6b.def » (pour un KFM en 6 boutons) ou « kfm-maxpow.def » (pour un KFM qui aurait toujours son power au maximum). En revanche, la règle du nom pour le DEF principal est assez nettement respectée.

Revenons à notre sujet : comment installer ces versions alternatives ? On a 2 possibilités, selon le type d’installation (classique ou compressée). On va prendre un exemple imaginaire : le personnage est KFM, avec une version principale « kfm.def » et une version alternative nommée « kfm-alt.def »

1. Pour un personnage compressé

En fait, on a déjà vu comment faire : on tombe dans le cas où le nom du fichier DEF (kfm-alt.def) est différent du nom du fichier zip (qu’il soit nommé kfm.zip ou « kungfuman.zip », peu importe d’ailleurs). La solution est donc simple, il suffit de modifier l’entrée dans le select.def pour le faire pointer sur le DEF alternatif :

kfm.zip:kfm-alt.def

A adapter en fonction du nom du fichier zip, bien sûr.

2. Pour un personnage installé selon la méthode classique

Là aussi, il suffit de faire une petite modification dans l’entrée du select.def, mais elle est un chouïa plus compliquée : alors qu’on avait simplement entré le nom du dossier, il va falloir donner le chemin complet du def à partir du dossier chars. Donc si notre fichier kfm-alt.def se trouve dans chars/kfm, ça donnera :

kfm/kfm-alt.def

Outre la mention du nom du fichier DEF, il faut penser à rajouter l’extension DEF (qu’on ne met pas en méthode classique), et le répertoire où se trouve ce fichier DEF dans chars (puisque Mugen ne peut plus le deviner simplement à partir du nom du DEF — quand on entre « kfm« , Mugen sait qu’il doit chercher un fichier kfm.def dans un dossier chars/kfm/, mais si on entre « kfm-alt« , Mugen va chercher un dossier « chars/kfm-alt/ qu’il ne trouvera évidemment pas).

Ce n’est donc pas bien compliqué si vous avez compris comment installer un personnage.