Ça fait longtemps qu'on a plus fait de devlog. Reprenons cette habitude!
L'un des gros gains du passage de RPG Maker VXace à Unity, dans le cas de HopDrop, est sans aucun doute le workflow qui est plus fluide. Créer des outils utilisables dans l'éditeur est évident sur Unity, Godot ou Unreal, mais ce n'est pas possible sur RPG Maker quelle que soit la version. Aujourd'hui, nous allons parler de quelques outils conçus spécifiquement pour HopDrop.
1- BLOC-NOTES INTÉGRÉ
Il peut paraître complètement idiot de programmer un bloc-notes alors que tout OS respectable en intègre un, c'est l'application la plus simple qui existe et qui existe depuis l'aube de l'informatique. Cependant, passer du bloc-notes à Unity peut devenir long et chiant, et j'ai mieux à faire avec mes crayons et mon papier (comme du graphisme, nous aurons l'occasion d'en parler). C'est là qu'intervient ce bloc-notes, puisqu'il est directement intégré à Unity, il est toujours devant moi et je peux noter des informations temporaires et m'y référer quand le besoin s'en fait sentir. En cas de besoin, ce bloc-notes dispose de fonctions de sauvegarde et de chargement de fichiers txt.
2- L'INSTANTATEUR
Les prefabs sont quelque chose de vraiment génial qui n'a pas d'équivalent sur RPG Maker... Ou peut-être qu'il y en a, c'est ce qu'on appelle les "événements communs" mais la technique est limitée (on peut sinon l'améliorer par des scripts mais ça reste assez laborieux). Instancier des prefabs dans une scène en les glissant-déposant de l'onglet projet vers l'onglet hiérarchie fonctionne très bien. Mais je suis une feignasse de compet', putain c'est incroyable. Ainsi, les prefabs les plus courants (collectables, décors ou bases PNJ, entre autres) sont créables depuis un menu déroulant dans le menu déroulant principal "GameObject".
3- L'IDENTIFICATEUR
Dans un collectathon ou tout autre type de jeu qui demande de collecter des objets, il est essentiel pour les développeurs d'avoir un suivi sur les objets qui sont placés dans les scènes. L'identificateur permet de nommer les différents GameObject en fonction de leur type et de leur identifiant. Prenons un exemple concret : les Fées.
Il y a au total 9 Fées par monde, elles ont un tag "Fee" pour définir de quel type de GameObject il s'agit, elles ont aussi un identifiant allant de 0 à 8 (donc de 1 à 9 en langage humain). On place une Fée dans une scène, grâce à notre menu déroulant cité plus tôt, l'identifiant va nommer l'objet "Fee0" car l'id de base est 0. Si on change l'id de cette Fée dans le champ dédié, par exemple avec 5, l'identifiant va renommer notre GameObject "Fee0" en "Fee5".
Cet identifiant fonctionne aussi pour les changeurs de scène où le modèle est le suivant "Vers_NomDeLaScene" (la convention de nom du projet est en français).
4- L'INSPECTEUR DE PROGRESSION
Cet outil tire parti du précédent. Il permet de voir où en est le développement d'un monde en comptant et en listant chaque objet collecté placé (bonbons, sacs de 10 bonbons, collectables locaux et Fées) en fonction de leur ID. Cet outil, qui établit un rapport à la fin de son fonctionnement, détecte les doublons et les scènes où se trouvent lesdits doublons ainsi que les collectables qui ne sont pas censés exister (par exemple une Fée qui aurait un id de -1). Bien que les collectables qui ne sont pas censés exister (toujours une Fée avec id -1 par exemple) se détruiront d'eux-mêmes lors du chargement de la scène, tout comme les doublons si l'un des deux a été récupéré.
L'identificateur cité plus tôt est donc très utile dans le cas où une erreur a été détectée par l'inspecteur de progression, car nous pourrons voir d'un coup d'œil le collectable problématique dans la scène où il a été trouvé.
5- PATCHEUR DE SAUVEGARDES
Il s'agit d'un outil externe codé en Python et qui porte très bien son nom, il rend les sauvegardes des anciennes versions compatibles avec les plus récentes. En effet, une ancienne sauvegarde peut être chargée et continuée, mais elle aura quelques problèmes : validation des lieux visités au moins une fois et informations manquantes. Le patcheur résout tous ces problèmes.
Les possibilités de patcher les sauvegardes de la version RPG Maker étaient, compte tenu de la logique de ce moteur, très limitées. J'ai dû faire un système de compatibilité pour empêcher le chargement d'anciennes sauvegardes, ce qui n'était pas idéal. Pour palier à ce problème, j'avais une réserve de sauvegardes pour les bêta-testeurs et pour le débogage.
Ce patcher sera disponible dans le téléchargement du jeu afin que chacun puisse continuer là où il s'est arrêté sans problème.
LE WORKFLOW
Sur la version RPG Maker, il était parfois laborieux de faire un rapport sur les mondes. Autant compter les Fées ça allait, il n'y en avait que 8 sur RPG Maker et même 7 dans des versions plus ancestrales, il fallait simplement se rappeler où se trouvaient les Fées. Autant ce n'est pas trop grave pour les Fées, autant les bonbons posaient plus de problèmes, car il y en avait 50 et il fallait les compter à la main et éviter de perdre le compte, et ils n'étaient pas aussi unique que sous Unity. Je prenais des notes du placement des bonbons par écrit dans un carnet, mais cela restait une opération fastidieuse.
Comments