Posted October 05, 2024 by Lo-shen
#Tutoriel
L'article présenté ici est la suite de ce tutoriel. Il nécessite d'avoir sous la main un projet "vierge", c'est-à-dire purgé de presque toutes ses entrées et de la vaste majorité de ses ressources (images, sons, plugins etc).
Les sources à l'origine de ce tutoriel sont toutes disponibles en fin d'article.
Objectif : organiser l'arborescence des maps pour s'y retrouver plus tard
Avant toute autre organisation à mettre en place, on commence par créer les maps suivantes, selon les très bons conseils de Yanfly :
Les maps TODO, WIP, Cinématiques, ZoneX servent de dossiers pour les autres maps. Toute map apparaissant en jeu passera par le dossier TODO, puis le dossier WIP et sera enfin classée dans le bon dossier de rangement quand elle sera terminée (Cinématiques ou l'un des dossiers ZoneX).
Dans Cinématiques, je crée tout de suite les maps intro et fin.
Mon projet est divisé en quatre + une zones (quatre régions géographiques puis une dernière zone spécifique pour les souterrains, les donjons et la bataille finale). L'arborescence complète des dossiers de rangement est donc :
Enfin, je crée quelques maps vierges dans TODO, au cas où l'envie de mapper se manifeste.
Objectif : avoir la satisfaction de finir la création d'un jeu !
Prérequis : réserver une variable
Première étape : réserver une variable. C'est très facile.
Deuxième étape : lier tous les dossiers de maps entre eux et suivre la progression du joueur dans les objectifs de jeu.
Conseil : lire ce comic (en anglais).
Dans mon cas, les maps-dossiers vont s'enchainer ainsi :
intro > Zone 1 > donjon hanté > Zone 2 > donjon temple 1 > souterrain 1 > Zone 3 > donjon temple 2 > souterrain 2 > Zone 4 > Zone 5 > bataille finale > fin.
Note 1 : la zone 3 propose trois embranchements :
La variable Avancement progresse ainsi :
Le message de victoire apparaissant après la scène de fin dépend du score :
En résumé, dès que la variable avancement est supérieure ou égale à 7 (fin de la zone 3), la liaison vers la zone 1 est débloquée.
Dès qu'elle est supérieure à 8 (fin du donjon temple 2), toutes les destinations sont débloquées.
C'est un peu plus compliqué que l'architecture proposée par Yanfly à cause des lieux optionnels. À adpater aux besoins de chacun.
Note : pour ceux qui savent lire l'Anglais, bgillisp propose une explication illustrée avec un système un peu plus simple sur Steam.
Objectif : réfléchir en amont à ce dont on a réellement besoin avant de se lancer dans la création de systèmes personnalisés.
Cette liste ne devrait contenir que les systèmes qui feront l'essence du jeu, qui le rendront différent des autres. En général, cette liste à tendance à s'étoffer avec le temps. Il faut régulièrement y revenir pour voir si le projet n'est pas en train de dérailler. Une fois que ces systèmes seront en place, il sera toujours temps d'en ajouter.
Pour mon projet, c'est rapide et la liste est centrée autour du combat :
À retenir : même si c'est toujours bon pour le moral de pouvoir rêver un peu, essayer de rester modeste dans ses envies. Sinon le jeu ne sortira jamais. Pour ma part, j'y joins toujours mes exigences en termes de graphismes et sons.
Cette étape est très importante : elle permet de faire le point sur les besoins réels (beaucoup de choses peuvent être faites avec les événements). L'objectif est d'essayer de réduire la liste des plugins au minimum. Plus il y en a, plus le risque d'incompatibilités augmente, s'ils viennent de plusieurs développeurs différents.
À chaque plugin de la liste ci-dessous ajouté, je respecte le protocole suivant :
Une fois qu'ils ont tous été testés, je désactive tous ceux qui ne sont pas immédiatement nécessaires.
Si j'en ajoute un nouveau, je les réactive tous puis j'ajoute le plugin et je reprends le protocole.
Voici ma liste perso (il y en a environ 60 différents, sans compter les miens)
Tous les plugins qui sont en gras sont considérés comme vitaux pour le projet.
Plusieurs de ces plugins sont tout simplement trop pratiques (gros gain de développement pour tout ce qui touche à l'eventing) pour s'en passer ou devraient être fournis de base avec le logiciel (Database Inheritance, Verbose Error Screen).
Les plugins en italique sont nécessaires pour l'immersion du joueur, mais n'apporte pas grand chose en termes de gameplay. Tous les autres seront activés au fur et à mesure de l'avancée du projet.
Note : Slope Move est un petit plugin gratuit très utile pour permettre de forcer le mouvement en diagonale (pour les escaliers, les pentes de falaises).
Note 2 : Gab Window (de VisuStella) est techniquement dispensable, mais je l'utilise pour les messages systèmes (gain d'objet, zone inaccessible etc). Gab Windows (d'Aerosys) fait techniquement la même chose que le plugin de VisuStella et est capable de générer des bulles de dialogue en plus.
J'en utilise deux différents pour avoir deux piles différentes de fenêtres, une pour les messages systèmes et une pour les dialogues. Chaque pile a sa propre configuration (windowskin, placement à l'écran) et n'interfère pas dans l'affichage des fenêtres de l'autre pile.
À la fin de cette étape, on doit pouvoir savoir si les idées de gameplay énumérées aux étapes précédentes sont viables (à savoir : est ce que les plugins sont compatibles ? est-ce qu'on parvient à les configurer et à les utiliser ? si non, est-ce qu'on peut trouver un remplacement ? est-ce qu'on a les épaules pour faire le système en events ?)
Cela nécessite de faire des tests sur de petits projets en parallèle du projet principal.
Rappel : la variable 22 est requise pour garder le contrôle de l'avancement du joueur.
Objectif : pouvoir accéder aisément aux variables/switches/events les plus communs et ordonner les éléments relevant des systèmes de jeu.
Par défaut, la première page de variables et de switches est dédiées aux variables et switches temporaires.
La seconde (et la troisième éventuellement) est dédiée aux variables et switches système réservés par un plugin.
On peut enfin commencer à maker !
Sources :