Archive for the “Utilisation” Category

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…

Comments Aucun commentaire »

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.

Comments Aucun commentaire »

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 »

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 »

Voilà, Mugen est installé, configuré ! Bon, mais avec juste 2 versions de KFM, y a pas de quoi s’extasier… Il est temps d’enrichir le moteur avec des éléments. Le plus évident, ce sont les personnages.

Vous les trouverez par centaines sur le net, à commencer par ce site. N’oubliez jamais l’adage de base : « Google est votre ami », c’est une règle d’or dans la recherche d’éléments !

1. L’extraction des fichiers

Les éléments, et donc les personnages pour le sujet qui nous intéresse aujourd’hui, se présentent sous forme d’archives compressées, le plus souvent aux formats ZIP ou RAR (on trouve également des formats parfois « exotiques » comme le DCG, mais ça reste assez rare). Vous devez donc disposer d’un logiciel de compression vous permettant de décompresser ces formats. Outre les ténors du genre que sont WinZip et WinRar, il en existe d’autres, comme 7-zip ou Izarc, tout à fait satisfaisants pour l’utilisation que nous en ferons.

La plupart de ces logiciels permettent d’ajouter des options au menu contextuel (le menu qui apparaît lorsque vous faites un clic droit). L’une de ces options sera assez pratique : elle permet d’extraire les fichiers dans un dossier portant le nom de l’archive.

Options d'extractionOptions d’extraction du menu contextuel pour 7-zip, WinRar et WinZip

A partir de là, il faut savoir qu’il y a 2 « écoles » de compressions des éléments :

  1. Les fichiers sont compressés directement dans l’archive : l’option « Extraire ici » décompresse donc les fichiers directement dans le dossier où vous vous trouvez,
  2. C’est le dossier contenant les fichiers qui est compressé : l’option « Extraire ici » décompresse donc les fichiers dans un sous-dossier.

Ceci a une assez grande importance dans Mugen, car les fichiers des personnages doivent se trouver à des emplacements bien précis pour que Mugen puisse les trouver.

En gros, les fichiers d’un personnage doivent être placés dans un dossier portant le nom du personnage, et ce dossier doit lui-même se trouver dans le dossier chars/ de Mugen. Exemple : les fichiers de Kung-Fu Man (abrégé KFM) se trouvent dans chars/KFM/.

Il faut donc commencer par placer l’archive dans le dossier chars/ puis extraire.

Si le créateur a utilisé la première méthode de compression, dans ce cas, le plus simple est donc de décompresser dans un sous-dossier portant le nom de l’archive. En revanche, s’il a utilisé la seconde méthode, c’est « Extraire ici » qui est recommandé. Le problème, c’est qu’on ne peut jamais savoir à l’avance quelle méthode a été choisie, et donc quelle est la méthode idéale pour décompresser.

Personnellement, je vous recommande de toujours considérer que c’est la première méthode qui a été utilisée, et donc de décompresser dans un sous-dossier, car si vous faites « Extraire ici » alors que c’est la première méthode qui a été utilisée, vous allez vous retrouver avec plein de fichiers qui se baladent dans le dossier « chars/ », et vous risquez d’en oublier lorsque vous les déplacerez.

Notez en outre que certains personnages utilisent une structure « interne », c’est-à-dire qu’ils possèdent des sous-dossiers contenant d’autres fichiers. Ce que j’appelle les « fichiers du personnages », ce sont les fichiers et sous-dossiers (si vous avez un dossier au même endroit que des fichiers, et notamment le fichier DEF, ce sont des sous-dossiers englobés dans la notions de « fichiers du personnage »).

Partant de là, on va envisager plusieurs cas de figure. Le premier, c’est le cas idéal : les fichiers étaient directement compressés, et vous obtenez donc le schéma suivant :

chars/dossier_portant_le_nom_de_l’archive/fichiers_du_personnage

Dans ce cas, vous pouvez passer à l’étape 2. Deuxième cas : les fichiers étaient déjà compressés dans un fichier. Vous obtenez alors ce schéma :

chars/dossier_portant_le_nom_de_l’archive/dossier_contenant_les_fichiers/fichiers_du_personnage

le dossier_portant_le_nom_de_l’archive/ et le dossier_contenant_les_fichiers/ peuvent avoir le même nom ou pas, ce n’est pas important. Dans ce cas, vous devez vous placer dans le dossier_contenant_les_fichiers/, copier l’intégralité des fichiers (faites un Ctrl+A pour les sélectionner tous), et les coller dans le dossier_portant_le_nom_de_l’archive/. Ensuite, vous pouvez supprimer le dossier_contenant_les_fichiers/.

Vous devez donc normalement vous retrouver dans le schéma idéal :

chars/dossier_portant_le_nom_de_l’archive/fichiers_du_personnage

2. Vérification des noms de fichiers/dossier

Avant d’aller plus loin, il convient d’effectuer une petite vérification extrêmement basique : vous devez comparer le nom du dossier contenant les fichiers du personnage avec les fichiers DEF contenus dans ce dossier. Pour que tout soit correct, il faut que le nom du dossier concorde avec l’un des fichiers DEF.

Notez que cette comparaison n’est pas « case-sensitive » (c’est-à-dire qu’on ne s’occupe pas du fait que les noms soient en majuscules ou en minuscules).

Exemple pour Kung-Fu Man :

  • Le dossier est chars/KFM/
  • Ce dossier contient un fichier kfm.def (si vous regardez bien, il y a également des fichiers intro.def et ending.def, mais l’important, c’est d’avoir au moins 1 fichier DEF correspondant au nom du dossier).

Si c’est le cas, c’est bon, vous pouvez passer à l’étape 3. Sinon, il vous faut modifier soit le nom du dossier, soit le nom du fichier DEF afin que les 2 concordent. Par convention, on modifie le nom du dossier plutôt que celui du fichier DEF, même si cela n’a pas de réelle incidence.

Voilà, votre personnage est désormais prêt à être inséré !

3. Insertion dans Mugen

Maintenant que votre personnage est prêt à être utilisé par Mugen, il ne reste plus qu’à l’ajouter dans Mugen. Pour cela, il faut ouvrir le fichier select.def qui se trouve dans le dossier data/. Ce fichier s’ouvre avec n’importe quel éditeur de textes (cf. ce qui a été dit à l’article précédent pour le fichier mugen.cfg).

Ce fichier débute par un groupe [Characters], dans lequel vous allez pouvoir placer vos personnages. Sous la ligne [Characters], il y a normalement toute une série de lignes débutant par des « ; » et la dernière ligne indique « ;Insert your characters below. ».

Il suffit alors de taper le nom du dossier sous cette ligne. Notez que l’ordre de la liste correspond à l’ordre d’affichage dans l’écran de sélection dans Mugen (1ère ligne = 1ère case en haut à gauche).

Pour reprendre l’exemple de KFM, c’est logiquement qu’on trouve dans le select.def :

kfm, stages/kfm.def

Ici, kfm = nom du dossier contenant les fichiers de Kung-Fu Man = nom du fichier DEF dans le dossier KFM/. Ne vous souciez pas pour le moment de ce qu’il y a après le nom du personnage. Enregistrez le fichier select.def, et lancez Mugen : votre personnage doit maintenant apparaître dans la grille de sélection !

Attention ! Notez que dans le Mugen de base, vous ne pouvez mettre que 10 personnages ! Si vous en mettez davantage, tous les personnages inscrits à partir de la 11ème position n’apparaîtront pas.

4. Conclusion

Bon, c’était un peu long, mais surtout parce qu’il y avait des petits détails à éclaircir avec les méthodes d’extraction. En pratique, insérer un personnage demande quelques secondes seulement !

Retenez surtout cette règle de base :

Nom inscrit dans le select.def =

Nom du dossier du personnage =

Nom du fichier DEF du personnage

Si vous respectez cette règle à la lettre, vous n’aurez pas de souci pour ajouter des personnages.

Comments Aucun commentaire »