Event Making, apprentissage sur la création d’un CBS
Dans ce tutoriel, nous allons voir comment, facilement mettre en place un système de combat personnalisé au moyen des évènements de RPG Maker. La version utilisée est RPG Maker VX pour assurer une colorisation syntaxique correcte des évènements. Cependant, il sera possible d’utiliser ce que je vais développer ici sur n’importe quelle version de RM de 2000 à VX.
Ce tutoriel est avant tout conçu pour apporter une base théorique permettant à n’importe quel maker ayant bien compris la logique du cours de se lancer dans l’élaboration de son premier système complexe. Je ne donnerai donc pas de solution miracle pour la création d’un CBS, mais bien des pistes théorique
Première partie : la création d’un « pierre, papier, ciseaux »minimaliste
Bien que pour beaucoup, cela puisse paraitre inutile et primaire, je trouve que cet exercice présente bien les notions de base pour se lancer dans la création d’un CBS.
La première version de notre jeu utilisera le système de choix rattacher aux messages, ensuite nous ferrons une application plus graphique.
Une notion de scène
Nous allons isoler notre système sur une map pour donner l’impression d’une scène, cette map sera vide et nous utiliserons les images et les panoramas pour l’habiller graphiquement. Par exemple, pour rendre notre scène un peu plus dynamique, il serait envisageable de faire défiler un panorama assez coloré.
C’est donc sur cette map que nous développerons notre application.
Déroulement du programme
Voici un schéma qui va modéliser le déroulement de notre application. J’ai toujours beaucoup apprécié l’utilisation de schémas pour modéliser une application, car ils établissent déjà la trame de notre application. Pour le « pierre, papier, ciseaux », vous vous apercevrez vite qu’il est assez simple.
Comme dans presque toutes les applications, nous allons commencer par l’initialisation des données. Pour un jeu de ce type, les premières variables seront donc « nbVictoires » et « nbVictoiresEnnemi », ce sont ces variables qui vont définir le nombre de manches remportées par un des 2 joueurs (soit joueur1 contre ordinateur).
Elles commencent toutes les 2 à zéro, car au début du programme, aucune manche n’a été gagnée par qui que ce soit. Ensuite, pour effectuer des comparaisons, nous allons définir 2 autres variables : « choixJoueur » et « choixEnnemi », ces variables débutent à zéro et correspondront au choix des 2 joueurs (soit zéro = pierre, 1 = papier et 2 = ciseaux). L’initialisation de ces variables n’est absolument pas nécessaire, car leur attribution sera définie à chaque itération de la boucle du jeu. Cependant, par souci de lisibilité, je définis toujours les variables que je devrais utiliser dans l’application endébut de programme, à l’étape que j’appelle : « L’initialisation ». Par après, il est plus facile de voir quelle variable est utilisée et dans quel contexte.
Sans plus attendre, voici donc un rapide schéma du déroulement de notre application.
Comme vous pouvez le voir, l’initialisation est la première partie du programme, elle va attribuer les valeurs par défaut aux variables utilisées durant le programme. Ensuite nous entrons dans la période de boucle. Cette partie est celle qui répètera les actions tant qu’aucun des 2 joueurs n’a atteint le statut de victoire (si on admet que pour gagner il faille 3 manches, ce statut est atteint lorsqu’une des 2
variables comptabilisant le nombre de manches gagnées est à 3). Si une victoire est attribuée, on sort de notre répétitive (soit de notre boucle) et on affiche le résultat du match. Sinon, on retourne à la première étape de la boucle, soit le choix du joueur 1.
Explication des étapes de la boucle
Le choix consiste à demander à l’utilisateur ce qu’il choisit comme arme (soit pierre, papier ou ciseaux), le premier traitement sera d’attribuer la valeur adéquate à la variable « choixJoueur » (je répète : 0 = pierre, 1 = papier et 2 = ciseaux). La partie choix Ennemi est présente dans le schéma par souci de clarté, mais elle correspond à un traitement, nous allons attribuer une valeur aléatoire de 0 à 2 dans la variable « choixEnnemi » et la seconde partie de ce traitement sera donc de vérifier qui a gagné la manche (ce second traitement sera donc plus long que le précédent), pour savoir qui a gagné, il s’agit simplement d’une condition qui vérifie le joueur victorieux en fonctionde la logique : pierre < papier < ciseaux < pierre. Le gagnant voit donc sa variable qui fait office de compteur de manche augmenter de 1.
L’étape suivante vérifiera si un des 2 compteurs de manche est = au nombre de manches gagnées requises pour gagner un match, nous sortons de la boucle et nous affichons en fonction du gagnant un petit message de victoire.
Implémentation de l’application
Nous allons maintenant implémenter notre jeu, j’ai choisi un évènement en processus parallèle isolé sur une map. Je vous montre le code que j’ai tâché de commenter un maximum.
(Le code est découpé en plusieurs parties, car il est trop grand pour être affiché sur une seule page.)
-Première partie du code-
-Seconde partie du code-
-Troisième partie du code-
-Quatrième partie du code-
-Cinquième partie du code-
Bien que ce code puisse paraitre complexe, si vous le décomposez, vous vous rendrez vite compte qu’il ne s’agit que de simple manipulation de variable et de condition. Il aurait été possible de faire une version plus compressée, cependant, j’ai opté pour assez grande décomposition du code par souci de lisibilité et de compréhension. Si vous faites une analogie entre le code et le schéma, vous vous
apercevrez vite que les étapes spécifiées dans le schéma correspondent avec les étapes
dans le code.
La prochaine étape sera la même application, mais en version plus graphique.
Effectivement, aussi joli que soit votre windowskin, votre architecture graphique est entièrement limitée par les positionnement envisageable. Nous allons donc faire un jeu encore plus custom en désignant notre propre interface.
Il s’agira de la dernière étape de préparation avant la réalisation d’un vrai CBS.
Seconde partie. Le même « Pierre, papier, ciseaux » version graphique, avec sélection de choix custom
C’est dans cette partie que nous verrons réellement comment concevoir un système original et esthétique pour vos jeux. Les règles du jeu sont identiques, cependant, la mise en forme sera sensiblement différente. La première étape est donc la création d’une interface de jeu. Pour cela, ouvrez votre éditeur de graphisme favori.
Différences par rapport à l’autre système
Contrairement à notre ancien système où les commandes de messages et de choix faisaient office de « blocage », soit d’attente de la saisie de validation. Cette fois, nous allons devoir nous même programmer cette attente de la saisie. Pour cela, c’est une fois de plus une boucle qui va nous permettre ce genre de chose. L’idée repose sur le bouclage d’une condition « si la touche C (enter sous RM) est pressée », on sort de la boucle. De même que pour la sélection, la boucle contiendra X conditions, les 2 premières concerneront la détection des flèches directionnelles pour modifier le curseur de sélection, la suivante vérifiera si la touche C est pressée et les dernières traiteront l’affichage de la sélection.
Suggestion d’une interface
J’ai réalisé une petite interface graphique relativement simple, les ressources sont disponibles en fin de page, dans les annexes (ainsi qu’une démo des systèmes conçus au cours de ce tutoriel), vous êtes libre de l’utiliser.
Cependant, vous êtes libres de paramétrer votre interface graphique comme bon vous semble. Sa structure est définie par la manière dont vous positionnerez vos images.
Déroulement du programme
Comme pour la version précédente, nous allons modéliser le déroulement de notre programme sous forme de schéma et d’explication. La logique du système est identique cependant, elle sera ponctuée par de nouveaux concepts (par exemple, le système de choix personnalisé).
Comme avant, tout commencera par l’initialisation de nos données et cette fois, de l’affichage de l’interface graphique. Bien que les quelques variables définies précédemment soient toujours d’actualités, il nous en faudra des nouvelles. Il nous faudra une variable de sélection qui correspondra au curseur de notre menu personnalisé. Donc comme précédemment, une initialisation, ensuite un bouclage, et, une nouvelle boucle imbriquée qui fera office d’attente de la sélection. Puis le traitement de l’ennemi, l’affichage graphique des choix des 2 joueurs, la définition de la victoire, la condition de sortie de la boucle, sinon le retour au début de la boucle principale. Si vous avez bien compris la partie précédente, celle-ci devrait vous paraitre relativement simple. Cependant, un schéma sera surement le bienvenu pour
mieux visualiser les différences avec le système précédent, car les systèmes graphiques font souvent entrer plus de modifications que ce que l’on peut imaginer.
Sans plus attendre, voici le schéma du projet :
Pour rendre l’application un peu plus complète, j’ai ajouté un choix supplémentaire qui permet au joueur, une fois un match achevé de choisir s’il veut rejouer ou retourner vers l’écran titre.
Comme vous pouvez le voir, il change tout de même beaucoup par rapport à l’ancienne version. Car, en plus d’effectuer des traitements de variables, il va nous falloir afficher les bonnes images en fonction des données entrées. Pour bien comprendre comment implémenter ces choix, nous allons, dans la partie
suivante, effectuer un système de 3 choix très rapidement, basé sur l’affichage d’une seule image à la fois. Cette étape est primordiale, car elle vous permettra, par après de créer vos propres choix rapidement et facilement.
Votre premier système de choix affranchis du système de base
Nous allons créer un PNJ qui aura pour rôle de nous laisser choisir entre 3 choix, si nous prenons le choix 1, il nous dira « Vous avez choisi le choix 1 », 2 pour le 2 et 3 pour le 3. Pour cela, nous allons utiliser une fois de plus une Initialisation qui va placer le curseur à zéro, un traitement qui se fera au sein d’une boucle pour détecterles touches et a la sortie de la boucle, les conditions d’affichages en fonction de la
sélection. Le code pourra vous paraitre barbare, cependant, décomposez-le bien et vous verrez
qu’il n’est qu’une suite d’instructions séquentielles facilement décomposables et réutilisables.
-Première partie du code-
-Seconde partie du code-
Concrètement, il ne s’agit que de simples conditions en fonction d’une variable.
Donc faire un choix est vraiment très facile. Cependant, si j’ai mis un temps de 10 frames dans les conditions d’appuis, c’est pour éviter que le curseur ne se déplace trop vite, et qu’il détecte 2, 3 appuis de touche, mais bien qu’il se limite à une seule détection par tour.
Maintenant que nous savons comment créer notre fenêtre de choix customisé (je rappelle qu’en annexe se trouvera une démo de chacun des systèmes réalisés ici et donc que les images seront mise à disposition pour mieux comprendre la découpe du système), nous allons pouvoir utiliser ces choix dans notre système de Pierre, papier, ciseaux, graphique. Ce n’est pas encore un vrai CBS, cependant, on se rapproche de l’idée du CBS, car, fondamentalement, rien ne nous empêcherait de faire un jeu où les systèmes de combats se joueraient à Pile ou Face ou encore à Pierre, papier, ciseaux.
Les images que je vais utiliser seront nommées de manière claire pour qu’à la lecture du code, l’idée générale soit bien perçue.
Décomposons les étapes
Tout d’abord, nous allons placer une étiquette « Debut » pour pouvoir revenir très facilement au début du jeu lorsqu’on choisit de recommencer une partie. Ensuite, nous allons initialiser les variables que nous utiliserons, pour que chaque foisque nous relancions une partie, elles soient réattribuées comme si la partie reprenait (ce qui est le cas), parce qu’imaginez que vous lanciez le jeu, et que vous le
recommenciez une partie, si les scores n’ont pas été remis à zéro, votre partie ne durera qu’un seul tour !
Une fois que les variables sont attribuées, il faudra mettre en place l’interface graphique au moyen d’images. (Par soucis d’esthétique, je joue avec l’opacité pour rendre le tout plus joli.). Une fois que tout est mis en place, nous pouvons lancer notre boucle qui sera la boucle principale du projet.
Ensuite, il faudra demander au joueur de choisir une arme. Pour ça, nous allons procéder de la même manière que pour notre système de choix customisé que nous avons réalisé à l’étape précédente, une simple boucle (avec des temps d’attentes correctement paramétrés) des conditions et une condition de sortie, en bref, exactement comme pour l’étape d’avant.
Après, il faudra attribuer une valeur aléatoire pour le choix de l’ennemi, puis simplement afficher l’image du joueur et l’image de l’ordinateur. Une petite animation pourrait être amusante pour rendre le tout plus esthétique. Il faudra mettre l’interface à jour (supprimer les images qui ne doivent plus apparaitre, mettre à jour le compteur de score, etc.)
Puis, vient le moment où nous allons nous interroger sur le fait qu’il y ait un gagnant potentiel. S’il y en a un, on sort de la boucle et on affiche le choix de recommencer ou de repointer vers l’écran titre. Sinon, on laisse la boucle tourner et elle se chargera elle même de repointer au bon endroit.
Nous avons fini de développer les étapes, et mis à plat, cela semble plutôt facile, il va maintenant falloir implémenter le code. Je le répète, mais la solution que je donne n’est absolument pas la seule (et peut-être pas la meilleure) donc pour vous lancer dans le code, plutôt que de recopier simplement la solution fournie, je vous invite plutôt à respecter le cahier de charge et le schéma pour arriver à devenir autonome lors de la réalisation de vos futurs systèmes.
Présentation de ma version
Ce code peut paraitre très long, cependant, les traitements des images (pour afficher de petites animations) prennent beaucoup de place, si vous avez bien suivi le déroulement des étapes et bien compris le schéma, vous devriez comprendre ce code sans trop de difficulté. Si jamais vous n’y arrivez pas, n’hésitez pas à consulter directement la démo fournie pour agir directement sur le code sans devoir recopier ligne par ligne cette hypothétique solution.
Je vous souhaite beaucoup de courage pour la lecture, car, quand on est néophyte, ce n’est pas évident. En tout cas, prenez votre courage à deux mains, car il s’agit de la dernière ligne droite avant de s’intéresser à la création du système de combat personnalisé, il est donc primordial que vous ayez bien compris le principe de « narration » dans votre code (soit le chemin que parcourra le système de son
initialisation jusqu’à son étape de clôture). Comprendre aussi comment fonctionne la détection des touches, la saisie du ENTER sont à bien maitriser pour se lancer dans la conception d’un système de combat.
-Première partie du code-
-Seconde partie du code-
-Troisième partie du code-
-Quatrième partie du code-
-Cinquième partie du code-
-Sixième partie du code-
-Septième partie du code-
-Huitième partie du code-
Vous êtes maintenant en mesure de réaliser des petits systèmes ponctuels (appelable au moyen d’une simple téléportation sur une carte). Une idée intéressante à creuser pour vérifier que vous avez bien compris le principe en essayant, par vos propres moyens de développer une machine à sous au rendu custom.
Bonne chance.
Troisième partie : Utilisons nos acquis pour concevoir un CBS
Nous y sommes enfin, la partie où nous allons évaluer les méthodes de réalisation d’un système de combat exclusivement réalisé au moyen des commandes évènementielles de RPG Maker. Avant de commencer, il est important de préciser que, pour une première, réaliser un CBS est souvent assez fastidieux, car il demande d’évaluer énormément de cas et demande d’être méticuleux pour fonctionner
correctement. De plus, rappelons que les évènements ne sont, à la base, pas prévus pour concevoir ce genre de système complexe et qu’un système réalisé de manière couplée avec l’interface de programmation de RM est bien plus adapté, car l’élasticité absolue de l’application est presque impossible à gérer avec les commandes évènementielles de base.
Un premier souci
Dans l’introduction de cette partie, j’ai parlé d’élasticité. J’entends par là que pour qu’un système soit viable, idéalement il doit être facile à modifier et doit pouvoir recevoir des données dynamiques. Ores, vous verrez nous seront souvent confronté à du paramétrage en masse. C’est-à-dire que vous ne saurez pas faire de recherche dynamique dans la base de données.
Pourtant, il est tout de même possible de faire preuve d’ingéniosité et de créer des systèmes agréables à jouer et ne requérant pas trop de configuration préalable. Nous allons donc voir quels sont les outils que le logiciel met à notre disposition pour se lancer dans le développement d’un système de combat totalement affranchi de celui d’origine.
Méthode de travail mise en pratique
Contrairement aux parties précédentes, je ne vais pas développer une manière de créer une chose, mais je vais tâcher d’expliquer le fonctionnement de certains outils et les méthodes à mettre en place pour concevoir son CBS.
Ce n’est pas par fainéantise, mais bien pour que ce soit la technique qui serve le développement du CBS et non le recopiage abruti de code.
Tout commence par une scène
Comme pour nos précédentes applications, un système de combat tour par tout serait facilement normalisable sous forme de scène, soit une map dédiée.
Une des premières parties de l’initialisation (rappelé vous ce que nous avons vu précédemment) serait de définir le fond, soit l’image 1 (ou encore via la modification des panoramas, uniquement accessible via un script sous VX). Pour cela, il suffit de comparer l’ID de la map et de conditionner l’affichage du fond en fonction d’une ID précédemment stockée, par exemple, si le combat est sur le Village Town1, on afficheun fond relatif à ce village.
Facile à mettre en place, mais révélateur des soucis d’élasticité. Si on possède 987 endroits différents de combats, il faudra donc paramétrer 987 conditions différentes. Le premier conseil que je vous donne est donc de fractionner vos maps par types de terrains pour répondre facilement à une séparation des images de fond.
L’attribution des données par variables
Une étape importante est d’avoir des données statistiques sur le héros sur les monstres présents. Les outils de modification de variables donnent accès aux données sur les monstres et sur les joueurs.
Vous savez maintenant créer vos propres menus, rien ne vous empêche donc d’en créer pour choisir un personnage, une action et un monstre. Donc, dans l’initialisation, il faudra définir un ensemble de données (au moyen des variables) pour permettre de définir les statistiques du monstre.
Cependant, il est aussi imaginable de spéculer totalement les statistiques d’un monstre sans pour autant passer par la base de données. Cette première attribution aura lieu dans l’étape d’initialisation, cependant, vous devrez définir des variables de type statistique dans le corps de votre CBS.
Notamment pour les calculs de dommages quels qu’ils soient.
L’attribution des variables pour les statistiques des monstres : Point particulier.
Via un évènement normal, il est impossible d’attribuer des points de statistiques à des monstres via les commandes de modification de variables. En effet, celles-ci sont utilisables dans les commandes d’attribution des évènements dans un groupe (accessible via la base de données).
La solution la plus abordable pour attribuer ces points de statistiques est donc d’inventer ces points de statistique en fonction d’une variable qui ferait office de « dérouleur de scénario » (un tutoriel de Joke sur Oniromancie développe le concept : http://www.rpg-maker.fr/tutoriels-170-joke-s-tuts-3-une-seule-variable-pour-deroulertout-le-scenario.html ).
Les monstres seraient donc définis par une variable qui se chargerait d’attribuer les points de statistique.
Diviser pour mieux régner (utilisons des procédures).
Comme nous avons pu le voir dans les rubriques précédentes du cours, la longueur du code devient vite assez grande pour l’éditeur d’évènement de RPG Maker, de plus, celui-ci n’étant pas doté de scrollbarre horizontale, l’imbrication excessive peut vite devenir problématique. Pour éviter des évènements trop gros et plus facile à mettre à jour ou à maintenir, une commande est primordiale, celle qui permet l’appel
d’évènement commun. En effet, si vous nommez correctement vos évènements communs, il devient très commode de les utiliser pour effectuer des traitements gourmands en ligne de code pour que l’évènement principal (chargé d’appeler les évènements communs) ne soit pas surchargé en longueur. Le choix de la découpe en procédures est libre. Je n’ai strictement aucune directive, cependant, moi j’utilise, en général, un évènement commun pour le menu de sélection, un pour les objets, un pour les calculs de dégâts, et un pour les affichages de dégâts.Cependant, c’est un peu au gout de chacun et je n’ai pas vraiment de conseils à prodiguer de ce côté.
Comment afficher 9999
Un autre épineux souci est : l’affichage de nombres. En effet, la solution instinctive serait d’afficher 9999 conditions, mais, ce serait totalement in-viable et affreux à mettre en place. Pour cela nous allons voir comment transformer 9999 conditions en 4 * 10 conditions.
Nous allons isoler les unités, dizaines, centaines, milles. Pour cela, RPG Maker nous fournit un opérateur « modulo » qui va vous donner le reste d’une division euclidienne.
Par exemple 5 % 2 (% = l’opérateur de modulo) donnera comme valeur 1 parce que 5 = 2*2+1. Avec cet opérateur, nous allons pouvoir découper un nombre. Car :
• les unités : Mon nombre % 10
• les dizaines : ((Mon nombre % 100) – les unités)/10
• les centaines : ((Mon nombre % 1000) – (Mon Nombre % 10))/100
• les milles : Mon nombre / 1000
Il suffit maintenant de faire un 4 conditions de 0 à 9 pour les nombres et il est maintenant possible d’afficher vos MP, HP, Dégâts et autres données numériques ne pouvant pas être statique.
Une notion de tour
Votre boucle principale correspondra au déroulement du jeu. Comme à chaque affichage du menu, la boucle se met en pause (au moyen d’une autre boucle imbriquée), on peut considérer qu’a chaque retour en début de boucle, un tour a été effectué (car la vitesse de passage de la boucle principale est bridée par le menu de sélection (voir les menus de sélections).
C’est donc en fin de boucle qu’il faudra (dans le cas où vous faites un tour par tour) traiter le fait que l’ennemi attaque, ou pas, et que vous devrez faire vos traitements en fonction des altérations d’états. Ainsi que la partie « traitement graphique » qui va rafraichir correctement toutes les images de l’interface graphique.
Conclusion
Vous avez maintenant assez d’outils pour vous lancer dans la création de votre propre système. Bien que cette dernière partie fût moins assistée que la précédente, vous avez toutes les cartes en main.
Et comme je le répète, ne pas avoir fourni d’exemple direct est uniquement par but
pédagogique pour éviter de tomber dans le syndrome du script surexploité et vu, vu et revu dans plein de démos.
Sachez tout de même que je reste ouvert à vos questions et que vous pouvez me joindre via xavier.vdw@gmail.com ou par MSN àxavier-vdw@hotmail.fr. Sinon, je tâcherai de
dresser des « feedbacks » sur les forums où j’aurai posté mon tutoriel.
Je vous remercie pour la lecture de ce didacticiel, en espérant que les retours soient bons et qu’ils me motivent à rédiger d’autre cours avec, peut être, des objectifs moins théoriques, mais plus orienté vers du concret.
N’hésitez pas à vous rendre sur le blog http://funkywork.blogspot.com pour y lire d’autres rédactions relatives à la création de jeu, avec ou sans RPG Maker.
Annexes
La démonstration du tutoriel est disponible, elle reprend les 2 Pierre Papier Ciseaux ainsi qu’un exemple de choix customs. Je n’ai pas alourdi la démo en ajoutant les RTP. Il vous faudra donc les RTP de RPG Maker VX pour lancer la démo. Elle n’est pas cryptée pour que vous puissiez analyser le code.
Bonne lecture.
Télécharger la démo du tutoriel (ici http://nuki.music-all.be/tutos/TUTO-CBS.rar)
Bonne chance dans la réalisation de vos systèmes, soyez forts et originaux !
Remerciements
Merci à Al’Jeit pour sa patience et sa correction.
- Auteur : Nuki