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…

Comments Aucun commentaire »

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.

Comments Aucun commentaire »

Elecbyte vient de sortir la RC6 de Mugen 1.0. Majoritairement, la mise à jour concerne des corrections de bugs, mais on notera un nouveau trigger Cond (équivalent de IfElse, mais avec un fonctionnement subtilement différent) et de nouveaux paramètres pour les stages, qui les rapprochent du DEF des persos. Et aussi, de façon assez ironique, l’implémentation de bugs, afin d’assurer la rétro-compatibilité avec la version 2002 de Mugen (Linux).

Comments Aucun commentaire »

Je suis en train de travailler (à un rythme d’escargot, soyons honnêtes ; j’y touche peut-être une fois tous les 10 jours…) à rendre Link pleinement compatible avec la nouvelle version de Mugen. Concrètement, il sera possible de jouer avec Link quelque soit le format d’écran (4/3 ou 16/9ème — à l’heure actuelle, il y a des problèmes d’affichage quand on joue en 16/9ème).

Il s’agit néanmoins bel et bien d’une nouvelle version de Link, qui inclura une petite nouveauté, à savoir la possibilité de gérer non plus un seul système d’objets prédéfinis, mais deux. Ceci permettra notamment à 2 joueurs de s’affronter avec Link en ayant des équipements différents.

Si ce sera à peu près la seule différence visible par rapport à la version 0.95, d’autres apports seront faits. Notamment, Link sera refait en SFFv2. J’entends déjà les reproches disant que ce SFFv2 n’est pas supporté par les anciennes versions de Mugen. Ma réponse : oui, mais pour permettre la compatibilité 16/9 et 4/3, j’utilise aussi des nouveaux triggers (GameHeight, notamment) qui de toute façon ne sont pas reconnus par les anciennes versions de Mugen.

Ce nouveau Link sera donc de toute façon uniquement compatible avec la version 1.0 de Mugen.

Le magasin en 16/9

Linventaire en 16/9

J’ai pour l’instant réglé les problèmes concernant l’inventaire et le magasin. Il en reste d’autres à corriger (notamment le Biggoron Scombo) et le readme à mettre à jour.

Comments 1 commentaire »

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 !

Comments 1 commentaire »

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.).

Comments Aucun commentaire »

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.

Comments Aucun commentaire »

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).

Comments Aucun commentaire »

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.

Comments Aucun commentaire »

Comme on le voit dans l’article précédent, installer un personnage n’est pas forcément très compliqué, mais requiert quelques précautions, et parfois quelques petites manipulations.

Pour simplifier un peu les choses, les dernières versions de Mugen supportent désormais les personnages compressés, ce qui tombe bien puisque c’est souvent, pour ne pas dire tout le temps, sous cette forme que sont distribués les personnages.

Voyons un peu comment ça marche.

Si la procédure d’installation est simplifiée, elle est aussi plus « rigide ». En effet, ce système ne fonctionnera pas dans les cas suivants :

  • L’archive n’est pas au format ZIP : c’est, au moins pour le moment, le seul format de compression supporté par Mugen. Si vous avez une archive RAR, il faudrait donc la décompresser pour recompresser les fichiers au format ZIP, mais puisqu’on doit décompresser les fichiers, autant passer dans ce cas par la méthode classique.
  • Les fichiers n’ont été compressés directement (c’est le dossier contenant les fichiers qui a été compressé) : dans ce cas, Mugen ne trouvera pas le fichier DEF car Mugen va le chercher à la « racine » de l’archive, en quelque sorte, et qu’il ne s’y trouve pas.

Si votre personnage ZIP n’est pas reconnu dans Mugen, c’est probablement que vous êtes dans le second cas ; là encore, la seule solution est de passer par la méthode classique.

1. Emplacement du fichier

Par défaut, quand on lui donne un nom comme « KFM », Mugen sait qu’il doit chercher dans chars/ un dossier « KFM » puis, dedans, un fichier KFM.def. Bref, le point de départ, c’est le dossier chars/. Si on considère que l’archive ZIP « remplace » le dossier du personnage, c’est logiquement que l’on va mettre le fichier ZIP là où on aurait mis le dossier du personnage : directement dans le dossier chars/.

Les personnages compressés sont placés dans le dossier chars/.

C’est tout pour cette étape !

2. Vérification du nom de fichier

Une étape assez courte, là encore : vous devez vérifier le nom du fichier DEF contenu dans l’archive. Pas besoin d’extraire pour cela : il suffit d’ouvrir l’archive pour voir son contenu, et refermer :

Le contenu d’un fichier ZIP de personnage : trouvez le fichier DEF.

Il y a 2 possibilités :

  • Le nom du fichier ZIP et le nom du fichier DEF sont identiques : c’est le cas dans la capture ci-dessus (le nom du fichier ZIP apparaît dans la barre de titre tout en haut) : sasquatch.zip et sasquatch.def,
  • Le nom du fichier ZIP est différent du nom du fichier DEF (exemple, si on avait eu sasquatch.zip et ssquatch.def)

Selon le cas, la suite de l’installation va légèrement changer.

3. Insertion dans Mugen

C’est une étape qui ressemble un peu à celle décrite dans la méthode classique (je vous renvoie à l’article en question pour plus de détails), à savoir qu’il faut ajouter votre personnage dans le groupe [Characters] du fichier data/select.def, sauf que cette fois, au lieu d’inscrire le nom du dossier du personnage, on va inscrire le nom du fichier ZIP :

sasquatch.zip

Et c’est là que la vérification du point 2. va servir : si vous êtes dans le premier cas (nom du ZIP = nom du DEF), vous avez fini, votre personnage est normalement jouable dans Mugen.

En revanche, dans le deuxième cas, vous allez devoir rajouter le nom du fichier DEF à la suite du fichier ZIP, en séparant les deux par un deux points « : », comme ceci :

sasquatch.zip:ssquatch.def    ; pour reprendre l’exemple donné.

Sauvegardez votre fichier select.def.

4. Limitations

Ce type d’installation présente certains avantages, comme le fait que le personnage prenne moins de place (vu qu’il est compressé), que vous n’avez pas des fichiers plein partout, et que la manipulation pour l’installer est plus simple.

Néanmoins, gardez à l’esprit qu’elle n’est pas applicable à tous les personnages (cf. ce qui a été dit au début). En outre, les « storyboards » (scènes cinématographiques) liées au personnages (intro et fin) ne peuvent pas être jouées à partir d’un personnage compressé. Enfin, si vous avez dans l’optique d’apprendre à programmer des personnages, il vous faudra bien travailler sur les fichiers de code et non sur des fichiers zippés ; idem si vous souhaitez simplement étudier le code d’un personnage pour comprendre son fonctionnement.

Tout ça pour dire qu’un Mugen ne comportant que des personnages compressés est encore un peu utopique…

Comments Aucun commentaire »