[RM 2k3] Bismillahdventure (devblog)

Récemment, j’ai décidé de reprendre le projet nommé Bismillahdventure (abrégé Bismillah) sur RPG Maker 2003 et j'ai commencé un CBS pour ce dernier. Je pense qu’il serait intéressant de documenter l'histoire, comme je la vis, du développement de ce projet, de ses péripéties, de ses blocages et des solutions.

L'idée est de montrer comment je m'y prend pour créer ce jeu, non seulement en exposant le résultat, mais aussi en détaillant le processus. Je pense que ce serait instructif :think:

Le but est de me motiver à continuer de travailler dessus, et aussi d'avoir vos conseils sur comment faire !

Pavé césar incomming, donc brace yourself.

Partie 1 : Genèse de l’idée

Comme certains l’ont vu sur slack, ce week-end je suis allé chez AlexRE pour une petite session making sur un multimaker dont la sortie a longtemps été repoussée. En rentrant chez moi, j’avais encore envie de maker, et donc je me suis mis en tête de poursuivre un autre projet sur lequel lui et moi avions travaillé en 2016, Bismillahdventure.



Bismillahdventure (titre temporaire MDR) était parti d’une blague. J’avais fait une petite intro en voulant parodier certains RPG amateurs à l’histoire ultra-complexe et tarabiscotée, où des factions politiques, des personnages et des légendes sont plus nombreux que le nombre de minutes jouables, et où tous les dialogues feignent l’évidence de la connaissance de toutes les entités du jeu. « Comment ça, le Concile des 5 a annoncé l’Opprobre éternelle ? La prophétie antique disait donc vrai… Il faut en parler à Jérémiah le forgeron ! ». Je laissais entr’apercevoir les rouages d’un système qui paraissait réel, mais que j’avais à peine imaginé.  



Dit comme ça, ça a l’air d’être un vrai exercice de style intellectuel. Mais en réalité, c’était juste plutôt marrant et ça menait à des retournements de situation absurdes et répétés. D’autant plus que l’univers (l’action se déroulait dans un califat imaginaire pendant l’âge d’or de l’Islam médiéval) était somme toute rarement vu. Ça avait plu à AlexRE qui avait créé plusieurs cutscenes bourrées d’idées. Finalement, ça ressemblait presque une vraie intro. On avait pensé créer un concours autour de ce jeu, où le but était de continuer l’histoire, mais, comme beaucoup de projets, ça n’était pas allé au-delà.



Ainsi, samedi après-midi, dans le métro pour rentrer chez moi, je repensais à  ce projet inabouti. Le concept de la narration avait du potentiel, et j’avais quelques idées sur comment le faire aboutir d’une manière vraiment percutante. Mais il y avait un gros problème : ce n’était pas un film, mais un jeu. J’avais peut-être des idées d’histoires amusantes, mais si je voulais que quelqu’un aille jusqu’au bout du jeu, il fallait du gameplay.

« Ça manque de gameplay » était déjà une critique de garywiss sur la partie d’un multimaker que j’avais réalisé auparavant. Pour être tout à fait honnête, la deuxième partie de la critique était : « ça manque de gameplay, on se fait chier. » Ça m’avait profondément marqué, parce que c’était absolument vrai ! Je ne devais pas refaire la même erreur.

Quel est le gameplay dans un RPG ? Les combats. Est-ce que je veux utiliser ceux de RPG maker par défaut ? Ce ne serait pas très intéressant. Je repensais à AlexRE : dans le cadre d’un [projet secret], il avait commencé à programmer un CBS (custom battle system) où les combats avaient lieu directement sur la carte. Quand le héros rencontrait un ennemi, les membres de l’équipe qui suivaient le héros en chenille se mettaient en arc de cercle autour de lui, et l’interface du combat tour par tour apparaissait. Il y avait un système d’ATB à la Final Fantasy, une gestion de l’inventaire et plein de trucs très stylés. Même si ce n’était qu’un prototype, j’avais trouvé ça très, très stylé.



(D'ailleurs, il y a quelques indices de ça sur le forum.)

Comme j’avais été très déçu que le [projet secret] s’essouffle et que le système de combat ne soit jamais terminé, je décidai de concevoir le miens, qui servirait pour Bismillah. Je me suis mis à imaginer différentes manières dont pouvait se dérouler les combats et j’ai abouti sur une vision assez floue, mais qui me plaisait. Le principe était de faire une sorte de Tactical-RPG, à la Fire Emblem. Les personnages se déplacent au tour par tour sur une grille, le but est d’arriver suffisamment proche de  l’adversaire pour pouvoir utiliser ses compétences. En tête, j’avais surtout Dofus.



L’idée était de faire quelque chose d’assez simple, mais de peu commun sur RPG Maker. Compte tenu de l’ampleur du projet (je doutais faire un jeu qui dure plus d’une heure), il n’y avait pas besoin de trop de profondeur. Il suffirait que ça marche assez bien pour distraire le joueur pendant 2 ou 3 combats, et j’aurais réussi mon coup.

---

Partie 2 : L’organisation du code et l’architecture des données

J’ai ouvert RPG Maker 2003, j’ai créé une map, j’ai ouvert les événements commun, j’ai créé une boucle, j’ai nommé quelques variables. Honnêtement, je n’avais aucune idée de ce que j’étais en train de faire.



Je n’avais fait aucun document préparatoire, mon concept de combat était au mieux embryonnaire, et je n’avais encore jamais programmé de CBS. Tout comme l’histoire de Bismillah, ce que je programmais laissait supposer que j’avais en tête une idée aboutie, immense, de ce que j’allais faire, alors qu’en réalité pas du tout. Je ne savais pas du tout où j’allais.

Que faire ?

1. Ou bien, faire des diagrammes, des schémas, des concept art, etc.
   
2. Ou bien, programmer de telle sorte que je puisse tout modifier à tout moment.
   

J’ai choisi de faire la seconde chose. Plutôt que de trop anticiper et de me décourager en imaginant un système de combat complet qui me demande trop d’effort, j’ai préféré avancer petit à petit, de façon à suivre mes idées au fil de l’eau, et à améliorer mon CBS au fur et à mesure. Cette seconde approche a beaucoup d’avantages, mais est aussi très dangereuse. Je ne pouvais pas non plus faire n’importe quoi, il fallait que ça soit facilement modifiable.

J’ai décidé donc d’avoir une approche hyper modulable, très inspirée des good practices de la programmation. Contrairement à AA City où je faisais du spaghetti code et j’étais presque fier d’avoir des événements illisibles avec des centaines et des centaines de lignes dedans, ici je sépare (parfois à l’extrême) mon code dans des événements communs distincts, pour garder quelque chose d’absolument lisible et simple. L’idée est d’avoir « un événement commun = une fonction = une seule tâche ».



De cette façon, même si une fonctionnalité n’est pas encore implémentée, je peux rajouter des événements communs placeholder qui font « comme si » elle l’était déjà, et avancer à la fonctionnalité suivante. Par exemple, je n’ai pas encore programmé les mouvements de caméra. Mais je sais que j’aimerais les rajouter. J’ai donc créé un événement commun « déplacer la caméra », que j’appelle aux bons endroits. Je sais déjà ce que j’aimerais qu’il fasse : je lui transmets des coordonnées X et Y, et l’événement commun doit me déplacer la caméra là-bas. Même si rien ne marche, c’est déjà presque construit : il me suffit de remplir l’événement commun avec le bon code. Je sais déjà qu’il y aura des problèmes (les bordures de map, par exemple) et qu’il y aura des subtilités de programmation (comment faire un joli mouvement de caméra ?). Mais ce sont des problèmes que je règlerai quand je m’occuperai de l’événement commun « déplacer la caméra ».

Voilà donc comment j’ai résolu mon premier problème, qui était « je n’ai aucune idée de ce que je fais » : faire quelque chose de très souple, qui fonctionne grâce à des petits bouts de code qu’on appelle par ci par là, et qu’on optimise les uns après les autres. Ça semble évident et simpliste ? Tant mieux, c’est supposé l’être !

Mon second problème est arrivé très vite.

Dans un système de combat, chaque personnage (allié ou ennemi) a des caractéristiques, des attributs : santé, mana, attaque, défense, magie… Toutes ces valeurs doivent être stockées quelque part pour que le jeu puisse calculer, par exemple, que les points de vie de l’ennemi doivent diminuer de 5 fois l’attaque du héros moins 2 fois la défense de l’ennemi. Il faut pouvoir facilement jongler avec toutes ces valeurs.

Problèmes :

• On ne sait pas, a priori, combien il y a de héros et d’ennemis. On peut avoir un combat où il y a un héros contre un ennemi. Ou bien, quatre héros contre vingt ennemis. Le programme doit pouvoir facilement gérer ces situations : pour lui, ça doit être « la même chose ».
  
  
• Je ne sais pas (car je travaille au fil de l’eau), combien il y a de caractéristiques pour chaque personnage. Combien de données caractérisent un héros ? 5 ? 8 ? 18 ? Il y a certes la santé, le mana, etc. Mais il y a aussi la santé actuelle. Et les équipements. Et les sorts utilisables. Et les états : empoisonné, boost force, etc. Et combien caractérisent un ennemi ? Il y peut y avoir des variables pour gérer l’intelligence artificielle, ses animations de combat, etc, etc.
  

Bref, on a un souci de gestion de base de données. Tout ça est géré silencieusement et intelligemment par RPG Maker, mais, ici, tous ces problèmes rejaillissent.

J’avais alors de vagues souvenirs que AlexRE avait eu des problèmes similaires avec son propres CBS. Il utilisait un système de get/set, inspiré de la programmation et des systèmes de base de données. Si je résume le principe, toutes ces données sur les héros et les ennemis étaient stockées dans des variables RPG Maker. Ensuite, quand on a besoin de connaître la valeur d’une variable ou de la modifier (je veux les HP du héros), on se contente d’appeler une commande (« get » pour récupérer la valeur ou « set » pour la modifier) en lui fournissant en paramètre ce qu’on veut (« les HP » du « Héros »). Un code, caché, fait plusieurs calculs pour retrouver où est cachée cette valeur dans les variables RPG Maker, et faire ce qu’on lui demande.



Ça crée donc une interface entre moi, le programmeur, et les données auxquelles je veux accéder. Je ne suis pas obligé de savoir que les HP du héros sont stockées dans la variable 1332, et que les points de défense du troisième zombie que j’affronte sont stockés dans la variable 2938. Je peux me contenter d’appeler les commandes get et set en leur demandant des informations que, moi, je comprends facilement : « les hp du héros ». Ça enlève un niveau de complexité, et, putain, ça fait du bien.

Cette architecture formidable date des années 1980. Donc en réalité, ici, dans RPG Maker, on est littéralement en train de réinventer la roue. Et pour poursuivre la métaphore, je dirais qu’on est en train de réinventer la roue à bord d’une voiture, qui elle-même roule sur un tramway, qui lui-même roule sur un train. Yes.

Bon, l’utilisation des get et des set est à peu près évidente. Maintenant, que place-t-on dans ces événements get et set ? En réalité, il s’agit ni plus ni moins qu’une utilisation élégamment décorée des pointeurs. Dans mon cas, les héros ont 6 caractéristiques : PV max, PM max, PA max, PV courant, PM courant, PA courant. Ces 6 caractéristiques sont stockées arbitrairement à partir de la variable 301 de la façon suivante :

Code:

301 : PV max du premier membre de l’équipe
302 : PM max du premier membre de l’équipe
[…]
306 : PA courant du premier membre de l’équipe
307 : PV max du second membre de l’équipe
[…]

Pour récupérer le i-ème attribut (entre 1 et 6) du j-ème membre de l’équipe (entre 1 et 4), l’événement retourne ou modifie la valeur de la variable, dont l’ID est le suivant : 301+(i-1)*(j-1).
Il y a un système analogue pour les caractéristiques de l’ennemi.

Il est à noter que ce mode de stockage est complètement arbitraire ! À tout moment, je peux changer un paramètre et décider de stocker ces caractéristiques à partir de la variable 8039. Ou bien de passer le nombre de caractéristiques de 6 à 33. Ça ne modifiera en rien l’interface get/set à côté.

Donc c’est très bien, j'ai (pour l'instant) résolu mon problème de base de données en recréant, approximativement et de mémoire, le système qu'employait AlexRE. Son système était encore plus avancé. Imaginez si deux commandes cherchent à, simultanément, set les mp du héros : l'un à 4 et l'autre à 18. Que se passe-t-il ? Comment gérer ces conflits ? On rend égal la valeur à 4, à 18 ? On donne raison au premier arrivé, au dernier arrivé ? On donne la priorité à un type de commande plutôt qu'à une autre ?

Heureusement, vu que mon CBS sera désespérément simple (un tour par tour très proche du jeu de plateau), je n'ai pas à gérer tout ça.

Partie 3 : DynRPG

Une fois la structure des données intelligemment (plus ou moins) mise en place, il reste à programmer tout ce qu’il y a entre cette base de données et le joueur. C’est-à-dire, le CBS lui-même. Mdr.

J’avais en tête deux-trois choses. D’une part, je cherche à faire quelque chose d’efficace. Et ici, efficace peut être compris comme rétro et minimaliste : très bonne nouvelle. Mon HUD peut se réduire à une fenêtre en haut à droite du personnage dont c’est le tour. Pour le créer facilement, j’utilise DynRPG et le Textplugin, qui permet d’afficher du texte à l’écran.



Le désavantage de cette idée, c’est qu’on ne connaît le nombre de HP d’un ennemi ou d’un héros que lorsque c’est son tour, mais on va dire que c’est une feature. Ça renforce le côté rétro et hardcore gaming de ce projet. C’est connu, dans le passé, il n’y avait que des mauvais jeux où on ne comprenait rien à ce qu’il se passait.

J’ai aussi implémenté le déplacement sur la map. Dans Fire Emblem, dans Dofus, et dans tous les Tactical RPG dignes de ce nom, on choisit simplement la case où on veut aller et un algorithme détermine le chemin optimal. Ça me paraissait, certes, possible, mais trop compliqué à programmer. Il aurait fallu faire un curseur, gérer les terrains impraticables, gérer les terrains inaccessibles avec du pathfinding… Ainsi, j’ai préféré simplement proposer au joueur d’utiliser les touches fléchées pour se déplacer. Parfois, il faut savoir faire des compromis techniques. L’important, c’est qu’on puisse déplacer son personnage.

Et si jamais, un jour, je veux faire un grand « overhaul » de tout ça, ce ne sera pas trop compliqué puisque tout est pensé de façon très modulable (cf Partie 2).



Quand c’est le tour d’un autre personnage, la caméra se déplace pour le placer au centre le personnage dont c’est le tour. Et une infobulle avec ses caractéristiques s’affiche également.



Grâce au plugin DynParams, c’est tout le temps le même code qui est utilisé. DynParams est pour moi le plugin le plus sous-côté du RPG Making français. Après, c'est aussi peut-être parce que la communauté RPG Maker 2003 est vivotante (qui utilise encore ce logiciel vieux de 15 ans ?)

En deux mots, DynParams permet de déterminer par une variable n’importe quel paramètre d’une commande en événement.

Par exemple, je l’utilise pour afficher sans trop me casser la tête ces infobulles. Pour afficher ces infobulles, j’ai besoin des coordonnées X et Y dans l’écran de l’événement représentant le personnage dont c’est le tour. Pour les récupérer, j’utilise la commande « Modifier variable » et ce petite menu pour sélectionner l’événement dont je souhaite les coordonnées.



Mince. Pour sélectionner l’événement, c’est un menu déroulant. J’aimerais pourtant indiquer ici une variable, dire au logiciel « on s’en fiche de ce menu déroulant, choisit l’événement dont l’ID est dans la variable 143 ! » DynParams permet de faire ça. Quand je travaillais sur AA City, c’était une feature dont j’avais souvent désespérément besoin. Maintenant, je peux rendre mon moi du passé très satisfait. Ce code suffit à récupérer tout ce dont j’ai besoin.



Bref, DynParams, un plugin qui est, je trouve, malaimé, et pourtant l’un des plus utiles pour libérer sa créativité et s’affranchir des (sages) limites de RPG Maker 2003. Il est certes un peu complexe à comprendre au départ, et j’ai toujours son « readme » de plusieurs dizaines de pages ouvert quand je l’utilise. Mais il permet de faire beaucoup.

Un autre moment où j’utilise DynParams est, par exemple, pour faire défiler l’écran. Grâce à des calculs, il est facile de savoir que l’événement est « 3 cases à gauche » et stocker cette valeur dans une variable. Cependant, dans la commande faire défiler l’écran, il est d’ordinaire impossible de demander « déplace moi l’écran du nombre de cases indiqué dans cette variable ». DynParams permet de dépasser cette limitation arbitraire. C’est vraiment chouette.

Dans ces trois blogs, j’ai dit la majorité des choses que je voulais dire jusqu’à présent. Le prochain arrivera un peu plus tard, le temps que j’avance un peu plus. Voilà ce sur quoi j’ai envie de travailler dans la suite :

• La gestion des attaques/compétences. J’aimerais bien faire quelque chose d’assez élégant, en faisant en sorte que les héros et les ennemis puissent utiliser les mêmes attaques, comme dans le Trésor des âmes damnées de Zim. Ça donnerait un côté puzzle pas inintéressant. Et, si je suis malin, ça simplifierait beaucoup la programmation.
  
• L’intelligence artificielle. Nous ne sommes pas en temps réel donc, a priori, tous les ennemis cherchent à tuer le héros. Je voudrais cependant qu’ils puissent détecter lequel est le plus proche, comment l’atteindre (pathfinding), comment l’attaquer, et comment fuir s’il est affaibli.
  
• Des feedback visuels simples, mais grandioses, pour les attaques et les compétences. Comme dans The Darkest Dugneon où des jolis artworks se superposent quand on attaque. C'est cheap à faire, mais ça marche bien.
  
• Un système de parade, de coup critique, et plein d'autres petits éléments aléatoires qui viendront pimenter la partie.
  

Je sens que j'ai encore de quoi m'amuser

Trop bien, la renaissance de Bismillahdventure.

Et la renaissance des idées ayant servi pour mon POC de système de combat personnalisé.

Oui Dynparams c'est le bien. Mangez-en.

Trop cool un Tactical ! C'est presque dommage de faire un système de jeu aussi avancé pour un jeu de seulement une heure. Mais vaut mieux un jeu d'une heure qui est fini que de 10 heures et... tu vois ce que je veux dire.

Bon courage, AA.

Cool ! J'aime beaucoup ce genre d'article, c'est très instructif de lire la manière de penser/faire des autres

Bon courage pour avancer ce projet et le mener à son terme !

Merci les gars ! Je suis content que l'idée et le format vous plaisent

Partie 4 : Relier le CBS à la Base de données RPG Maker

Je n'ai pas rouvert le projet sur RPG Maker depuis mais j'ai continué à réfléchir à deux-trois choses. J'aimerais les poser à plat pour que ces idées ne soient pas oubliées et cessent de me tenir éveillé la nuit.

D'abord, il y a un problème que j'esquive habilement depuis le départ, qui est le stockage des caractéristiques des héros et des ennemis. De la même manière que RPG Maker conserve une bibliothèque de tous les héros et des monstres que l'on rencontre dans le jeu, il faut que mon CBS puisse manier de telles informations. Il faut que quelque part soit inscrit "Jérémy a 510 PV au niveau 31", "un zombie a 3 points d'attaques", etc.

Cependant, conserver ces données et créer une interface pour facilement pouvoir les modifier, c'est compliqué. L'idéal serait de pouvoir réutiliser la BDD de RPG Maker pour ce CBS. De cette façon, le CBS n'est qu'une surcouche discrète des autres systèmes, et on peut aisément le combiner avec les systèmes préexistants (par exemple : le menu par défaut).

Certaines informations de la base de donnée (celles sur les héros) sont facilement accessibles depuis la commande "Modifier une variable".



(Il me semble que "Nombre de" est une erreur de traduction et devrait être compris comme "ID de l'équipement", mais je ne suis pas certain)

Toujours est-il que ces informations sont loin d'être exhaustives. Nous n'avons pas d'information sur les compétences des héros, par exemple. Et nous ne pouvons pas accéder à d'autres "onglets" de la BDD qui nous intéresseraient : les monstres, les attaques...

À l'époque où AlexRE faisait sont CBS, il n'avait pas le choix. Il a dû réencoder ces données à la main, ailleurs. Dans un événement commun, il définissait une vingtaine de variables supplémentaires avec, par exemple, le taux de coup critique, les compétences d'un héros, son statut, les caractéristiques de l'ennemi... En témoigne ce bout de documentation que j'ai retrouvé.



C'était un sérieux souci. AlexRE, garywiss et moi avions essayé de coder un plugin qui permettait d'extraire ces informations, mais les capacités de chacun (AlexRE la connaissance de ce dont il avait besoin, moi la motivation, gary l'environnement technique) étaient trop éparses pour qu'on mène le projet à bien.

Maintenant vient le moment d'épiphanie. Je croyais me souvenir que AlexRE était allé poster sur le topic anglophone de DynRPG pour parler de ce problème (en réalité, non, il parlait d'autre chose). Quand j'y suis passé, regardez ce que j'ai découvert !



Audrey The Bard (par ailleurs le créateur de DynParams) et DJC (que je ne connais pas) avaient eux aussi connaissance du problème d'Alex et moi. Et après un rapide tour sur la page de leur plugin... wow. Ils avaient créé une très large partie des fonctionnalités dont j'avais besoin.

(D'ailleurs @AlexRE, eux aussi ils ont un github super quali)

Ainsi, par chance, ce plugin apparu sorti il y a 3 mois me permettrait d'avancer encore plus vite sur ce point complexe. Certes, je ne compte pas réutiliser exactement les informations de la base de donnée RPG maker à l'identique. Mais pouvoir stocker des valeurs tranquilou et les modifier à l'aise, ça fait zirplé.

Par exemple, j'ai (pour l'instant) prévu comme caractéristiques : points de vie, points d'action, points de mouvements. La BDD de RM n'a pas de points d'action ni de points de mouvements. Mais je peux renommer les "points de magie" en "points d'action", et "l'agilité" en "points de mouvements", grâce au menu ci-dessous. Résultat : le CBS peut facilement récupérer l'information et l'illusion est parfaite pour le joueur qui, dans le menu, voit des choses cohérentes.



Si jamais j'ai besoin de variables supplémentaires, je peux également détourner l'usage de l'une d'elle. Notamment, pour les ennemis, la caractéristique "intelligence" peut me servir de clef pour assigner à l'ennemi son comportement. Par exemple, une intelligence de 1 signifierait : cet ennemi attaque à distance et eveut rester à une distance de 3 cases du héros. Une intelligence de 2 signifierait : cet ennemi attaque au corps à corps et cherche à coller le héros à tout prix. L'intelligence, au lieu de me servir pour des calculs de dégâts magiques ou de soin, me permettrait donc de paramétrer aisément l'intelligence artificielle des ennemis. Astucieux.

Finalement, je n'aurais qu'à dire : "ce combat est contre 6 ennemis de type 4 et 3 ennemis de type 7". Au lieu d'à chaque fois préciser : "ce combat est contre un ennemi qui a 10 HP, 4 PA, 2 PM, qui attaque à distance, qui fuit le héros ; un autre ennemi qui....". C'est vraiment top !

Bref, je partais d'un problème, et je découvre que tout s'annonce bien plus facile que prévu  

On se revoit bientôt

Citation :

Maintenant vient le moment d'épiphanie.

Citation :

ça fait zirplé

Ces expressions.


Yes, j'ai vu l'amélioration de ce plugin y'a quelques semaines, c'est trop bien ! C'est clair que ça peut aider pour Le jeu pour Relm. Et ce projet !

Partie 4 bis - Data 2

Je me suis attelé à ce dont j'avais parlé dans mon dernier post : charger les données sur les héros et les ennemis depuis la base de donnée RPG Maker. Une simple boucle for et l'affaire était dans le sac.



Ça marche parfaitement bien avec les héros.

Ça marche beaucoup moins bien avec les monstres.

En effet, les commandes suivantes du plugin Dyn Data Access ne fonctionnent en fait qu'en combat, de ce que j'ai pu expérimenter.



Le "ennemy number" fait référence au numéro de l'ennemi dans un groupe de combat, et non pas dans la base de donnée. Dès lors, comment récupérer cette information ?

• Option 1 : participer au projet github du plugin DynRPG, coder les fonctions dont j'ai besoin en C++ avec la dernière version du SDK de DynRPG, contacter Audrey The Bard pour avoir de l'aide, faire des tests pour vérifier que tout marche, commit mes améliorations à la version officielle, compiler une nouvelle version du plugin, aider la communauté RPG maker en proposant un plugin plus complet et abouti.
  
  
• Option 2 : Démarrer un combat avec les bons ennemis, appeler un événement commun pour récupérer les données, terminer automatiquement le combat.
  

...

Allez, option 2



Ça ne fait aucun sens. Mon CBS commence donc par... un combat normal. Qui se termine immédiatement. Yes.

J'ai un peu dissimulé la chose en rendant le fond du combat noir, et les ennemis et les héros transparents. Le HUD n'a pas le temps de s'afficher. Donc, visuellement, on voit juste un fondu au noir. Ça fait en réalité une très bonne transition avant un combat : je pense que je modifierai le fond de combat pour afficher un gros texte "FIGHT !" et jouer un effet sonore. À partir de ce moment là, on pourra même croire que tout ça est fait exprès.

Bref, même en construisant quelque chose de très structuré, parfois le plus rapide est de faire n'importe quoi...

Spoiler:

Prochaine étape : les compétences

J'espère qu'on peut les charger directement depuis la BDD, sinon ce CBS va très vite partir en vrille

Partie 5 - Преступлене и наказание

Après (déjà !) une semaine de pause, je rouvre RPG Maker, bien décidé à en découdre avec les compétences.

J'ai imaginé le système dans ma tête : je n'ai pas envie de programmer un curseur. Ca briserait le rythme. J'aimerais que le joueur n'ai jamais à maintenir une touche appuyée et qu'il doive sans cesse taper dessus pour l'activer, façon arcade. Donc, pour choisir "où attaquer ?", il suffira d'indiquer une direction et d'appuyer sur entrée. Le rythme ne sera pas brisé, pas besoin d'aller indiquer précisément l'ennemi qu'on veut attaquer. C'est un peu plus nobrain, mais ça peut être cool.

Je me suis occupé d'implémenter mon idée dans le code. D'après mes tests, ça marche.



Pour détecter les "collisions" (entre la portée de la compétence et un événement ennemi), j'utilise la même astuce que dans mon tutoriel pour programmer un jeu de tir en 15mn : la commande "stocker l'ID d'un événement" et une liste d'ID d'événements correspondant aux ennemis. Comme quoi, une bonne astuce est toujours utile, même 4 ans plus tard. J'ai été un peu fainéant et je n'ai pas ajouté d'animation de combat sur les ennemis touchés, mais ça ne saurait tarder.

À noter qu'on peut contrôler sur la carte autant de joueurs qu'il y a dans l'équipe. Ici, le deuxième joueur. On peut voir que la zone bleue (portée de l'attaque) est différente. (On peut aussi voir que j'ai oublié de bien le positionner).



La caméra se déplace pour se centrer sur le héros ou l'ennemi dont c'est le tour. Sur le screen ci-desus, on voit que ce déplacement de caméra n'a pas de souci avec le fait que le héros n'est pas "exactement" au centre de l'écran. C'est une bonne nouvelle !

J'ai toutefois eu quelques déconvenues en programmant.

D'une part, le plugin Dyn Data Access, que j'imaginais résoudre tous mes problèmes, ne permet pas de récupérer suffisamment d'informations sur les compétences dans la BDD RPG Maker. En fait, il ne permet de récupérer que le coût en MP d'une compétence. Difficile d'en tirer grand chose.

J'ai donc dû hardcoder en event les comportements et attributs de mes compétences : leur coût en points d'action, leur portée, leurs dégâts. Et utiliser des facilités de raisonnement : par exemple, supposer qu'une compétence alliée ne peut toucher qu'un ennemi. (Ce qui est faux, dans le cas des sorts de soins ou de d'auto-boost. Il faudra gérer ces edge cases avec des pipelines différentes. Relou.)

On en arrive au consternant schéma suivant qui me donne envie d'entourer ma gorge d'une corde, de la serrer très fort, et d'enfin vérifier empiriquement les lois newtoniennes sur la pesanteur.





En bref, si je ne m'exprime pas assez clairement, tout ça signifie que je vais galérer à accéder et modifier proprement mes données. Et ça m'embête, car ça signifie que faire la moindre chose demande beaucoup plus d'actions, de rajouts, et de conditions dans des événements différents.

Serait-ce un retour de flamme ? Un coup du sort après avoir choisi la diabolique option 2 dans la Partie 4 bis ? C'est une ironie probable.

Si j'avais été plus sérieux et choisi l'option 1, j'aurais pu facilement étendre le plugin Dyn Data Access pour avoir ces infos sur les compétences qui m'intéressent. Et en plus, je saurais maintenant coder en C++, et Code::Blocks tournerait sur mon ordi avec le bon compilateur. J'aurais peut-être même pu faire des fonctions mathématiques customs.

Enfin, peut-être. Peut-être que ça m'aurait tout fait abandonner beaucoup plus tôt

En fait, le vrai piège est le suivant. Si je me mets à programmer avec de vrais outils, il ne me reste que très peu de raison de continuer à programmer en event. Pour continuer les schémas, je pourrais très bien faire quelque chose du genre, bien plus propre :



Je suis donc, présentement, dans une forte dubitativation (je suis très dubitatif).

• Ou bien, je continue le CBS avec les outils qui me sont disponibles, mais je code d'une façon qui va m'handicaper et me pénaliser sur le long terme.
  
• Ou bien, je prends la peine d'en développer de nouveau, mais alors je n'ai aucune raison de garder tout ce que j'ai programmé jusqu'à présent et je dois recommencer à zéro.
  

Est-ce que j'ai déjà atteint l'état mentionné au point 11. de cet article ?

Dites-moi vos avis, les amis. Je me pose beaucoup de questions et, pour une fois, je n'ai pas les réponses

AristA a écrit:

Dès lors, comment récupérer cette information ?

• Option 1 : participer au projet github du plugin DynRPG, coder les fonctions dont j'ai besoin en C++ avec la dernière version du SDK de DynRPG, contacter Audrey The Bard pour avoir de l'aide, faire des tests pour vérifier que tout marche, commit mes améliorations à la version officielle, compiler une nouvelle version du plugin, aider la communauté RPG maker en proposant un plugin plus complet et abouti.
  
  
• Option 2 : Démarrer un combat avec les bons ennemis, appeler un événement commun pour récupérer les données, terminer automatiquement le combat.
  

...

Allez, option 2

Trop bien ce passage.


Je viens de prendre le temps de lire le dernier message jusqu'au bout.  

Je pense que tu es loin de ce point 11 quand même, vu que tu n'en es qu'à la phase de prototypage, et que ça vaudrait le coup d'investiguer sur l'option 1... Avec quelques étapes que tu peux sauter d'ailleurs.

Mais ouais ça demande sûrement de recoder plusieurs trucs...

Quand tu vois ce que certains arrivent à faire, ça donne tout de même de l'espoir.



(Bon, je dis ça alors qu'en fait je suis en train de déchanter vis à vis de DynRPG en ce moment. )


En tout cas, ça fait plaisir de voir que certaines techniques mises en places dans des projets précédents sont toujours utiles (utiliser les pointeurs pour faire une pseudo base de données, stocker l'ID du terrain et des évènements, ...)

Partie 6 - RPGSS

Salut les kids, je suis de retour, après une petite (grosse) pause.

Nous nous étions quitté en janvier sur le problème que j'avais : je ne trouvais pas le moyen d'efficacement accéder à la base de données RPG Maker. La solution qui s'imposait à moi était de programmer un plugin DynRPG en C++. Et ceci... m'embêtait au plus au point.  

L'affaire était sortie de mon esprit quand, un peu par hasard, je suis tombé sur ce module DynRPG, RPGSS, qui permettait d'incorporer des scripts Lua dans RPG Maker 2003. Intéressé, j'ai écrit un bref article là-dessus. À ma grande déconvenue, hélas, le plugin ne permettait pas d'accéder à la base de données RPG Maker de la manière que j'imaginais.

Toutefois, il conservait certains avantages par rapport à DynRPG :

• Pas besoin d'installer de compilateur GCC obsolète bizarre auquel je comprends R
  
• Pas besoin de compiler les scripts, qu'on peut éditer à la volée (donc : itérations très rapides)
  
• Un peu moins galère en POO que le C++ (bien que pas aussi sympa que Python)
  
• L'univers des modules Lua est accessible (merci les messieurs et mesdames de github qui mettent tout en opensource  )
  

Sur ce dernier point, je me demandais alors : pourrai-je utiliser un module Lua qui me permettrait de créer une base de donnée extérieure à RPG Maker ? En effet, ça me permettrait d'éviter de démarrer un combat pour utiliser un plugin dynrpg chelou, de hardcoder en events des informations essentielles concernant les sorts, les monstres, l'intelligence artificielle, etc.

La réponse était : bien sûr que oui.  

On pourrait imaginer de nombreuses façons de créer une base de données supplémentaires. Mais, comme toujours, la solution que j'ai finalement mise en place est l'une des plus simples. Les données sont stockées "en dur" dans des fichiers CSV, à éditer avec Excel ou Notepad. Des scripts Lua font le pont avec le jeu RPG Maker. Les données entrent dans le nuage "bordel de variable rpg maker" grâce aux événements communs SET classiques. Et, depuis le "bordel de variables rpg maker", sont joliment accessibles grâce aux événements communs GET.  



C'est un beau système. Je n'ai pas parfaitement finalisé l'intégration avec ce qui est déjà programmé, mais j'ai réussi à faire marcher le gros du truc. Ça m'a déjà pris pas mal de temps parce que, honnêtement, j'ai rien bité au Lua et j'avais trop la flemme d'apprendre, donc je tâtonnais de ouf mdr.

Les prochaines étapes consistent à :

• Inclure ces lectures de données de fichiers CSV (appels de script) à l'initialisation du combat
  
• Transformer ce qui est hardcodé en event pour l'instant en lectures de données de fichiers CSV. Notamment pour : les sorts.
  

Mon approche (fichiers CSV) a des limites : le joueur, pour tricher, n'a qu'à éditer un fichier csv très compréhensible, à l'aide d'un éditeur de texte. Il pourrait ainsi mettre à 0 tous les PV des ennemis et gagner tous les combats immédiatement. Mais, s'il fait ça, c'est qu'il ne veut pas jouer au jeu, donc osef en vrai

J'ai également profité de mon élan de motivation pour inclure le plugin DynRPG OpenGL pour ne plus avoir de pixels flous.

Ce système de scripts RPGSS est plutôt sympatoche. Je pense que ce sera plus simple de programmer l'intelligence artificielle des ennemis en .lua que dans RPG Maker, surtout si je dois faire un peu de math. Par exemple, faire du pathfinding A*, trouver les héros les plus proches (oui, rpg maker n'a pas de fonction minimum... yes... lol...), agir selon certains comportements... J'avais regardé des vidéos sur le sujet, et ça a l'air fun à faire !

C'était les nouvelles du front. Post terminé.

C'est trop cool !

Pour le pathfinding il y a déjà ce plugin de Cherry (en avance sur tout le monde ce Cherry) : http://cherrytree.at/cms/lang/en/download/?did=22

Ça me dérange un peu le côté "le joueur peut éditer le fichier CSV comme ça", j'aurais bien rajouté une petite couche de chiffrage pour réserver cela aux bidouilleurs plus avancés.

Mais c'est pas prioritaire.

Mince, va falloir que j'utilise toutes tes avancées pour le jeu pour Relm.

AristA a écrit:

Salut les kids

"Cool" kids, au moins, j'espère ?

Citation :

Je pense que ce sera plus simple de programmer l'intelligence artificielle des ennemis en .lua que dans RPG Maker

Mais je croyais que tu avais la flemme d'apprendre le langage ?

Évidemment vous êtes des super cool kids


Yes, je connaissais ce plugin. Je verrai comment goupiller tout ça le plus intelligemment !

Je t'enverrai mes (sublimes) scripts si tu veux ajouter ça au jeu pour Relm


Concernant le chiffrage, je peux peut-être ajouter un script qui teste l'intégrité du fichier avant de le charger, en faisant un md5 checksum, par exemple. Mais il suffirait de supprimer la ligne qui teste l'intégrité du script et ça n'aura servi à rien

Sinon, on peut mettre le fichier "Scripts" dans un zip. Les bases de données seront donc dans une archive, ce qui découragerait déjà d'y fouiller. Ensuite, un md5 checksum checkerait l'intégrité de l'archive contenant tous les scripts, et sinon, supprimerait tous les fichiers et signalerait le joueur à la police

Bref, je ne sais pas vraiment. C'est pas vraiment le but du projet ! Mais ça pourrait être une mécanique intéressante pour le projet DS.Ace 5


Concernant l'IA. Il y a différentes manières de le faire, mais j'imaginais peut-être un système où l'ennemi a un certain nombre d'actions à disposition. Il est capable d'anticiper (simuler) les conséquences de chacune de ses actions sur lui. Par exemple, il a le choix d'avancer vers le héros A et d'attaquer celui-ci, ou d'attaquer le héros B à côté de lui puis fuir. Dans le premier cas, il tuerair le héros A mais subirait 5 dmg du héros B. Dans le second cas, il affaiblirait seulement le héros B mais ne perdrait pas de point de vie.

L'IA serait capable d'assigner un score à chacune de ces stratégies (par exemple : perdre des PV fait baisser le score, infliger des dmg le fait monter, tuer un héros le fait beaucoup monter...). Et ensuite de choisir la stratégie avec le meilleur score.

Évidemment, l'influence des "conséquences" sur le score serait un problème d'équilibrage, et dépendrait du comportement qu'on veut donner aux monstres (kamikaze, fuyard, tank...)

Ce genre de système ne me paraît pas invraisemblable à programmer en Lua, même si ça nécessite de réinventer un peu la roue. Par exemple, on peut récupérer d'un coup toute la carte, tous les événements, et ensuite faire de la POO (relativement) élégante. Même si je ne connais que les bases du langage ! Mais en programmation event, ce serait très fatiguant à faire, voire quasi-impossible.

Bon, après, c'est que des réflexions. Si ça se trouve, ça va me souler, et je me contenterai de faire un truc conditionnel (si ennemi a moins de 10% de ses pv, alors fuir...) et les event suffiront amplement pour ça !

Ah pas bête du tout le md5 checksum. C'est simple mais efficace pour bloquer ceux qui sont pas bidouilleurs mais savent modifier un fichier Excel.

Oui, j'avais lu/entendu que les systèmes d'IA pour les jeux (échecs, go, etc.) étaient des systèmes qui calculaient un score de réussite pour tout l'arbre des possibles, sur plusieurs tours en avance.

Ça doit être intéressant à faire, mais assez compliqué et long. Et est-ce qu'on a envie d'une IA qui gagne à tout prix ? La réponse est NON !

(Je cherche depuis plusieurs semaines un poly de cours d'algorithmique que j'avais eu en école d'ingé, où on avait parlé de ça. Faudrait que je reprenne mes recherches. )

Citation :

et sinon, supprimerait tous les fichiers et signalerait le joueur à la police

Ah oui, parfait ! "Supprimerait tous les fichiers" de l'ordinateur, on est bien d'accord ?

AristA a écrit:

Évidemment vous êtes des super cool kids  

Ce que j'essaye de faire, quand j'ai des fichiers textes pour mes jeux (sauvegardes, map de niveaux), c'est effectivement de passer par plusieurs couches de chiffrage basique. En général, c'est des algo assez simples (à base d'une clé qui peut être un mot) et relativement efficace pour le commun des mortels.

Pas de quoi repousser les mecs un peu débrouillards, mais ça évite les triches trop évidentes, surtout si en 2 clics tu peux passer ton perso du niveau 2 au niveau 99 ^^