~ S'évader de la banalité... Et entrer dans l'imaginaire ! ~
 
AccueilGuelnika, le site de E-m !S'enregistrerConnexion

Partagez | 
 

 [RM 2k3] Bismillahdventure (devblog)

Aller en bas 
AuteurMessage
AristA
Maker qui quitte vraiment E-m Lv 60
Maker qui quitte vraiment E-m Lv 60
AristA

Nombre de messages : 10924
Age : 21

MessageSujet: [RM 2k3] Bismillahdventure (devblog)   Lun 07 Jan 2019, 16:15

Bismillahdventure


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.


Dernière édition par AristA le Sam 12 Jan 2019, 16:09, édité 11 fois
Revenir en haut Aller en bas
http://arista.lescigales.org
AristA
Maker qui quitte vraiment E-m Lv 60
Maker qui quitte vraiment E-m Lv 60
AristA

Nombre de messages : 10924
Age : 21

MessageSujet: Re: [RM 2k3] Bismillahdventure (devblog)   Lun 07 Jan 2019, 16:22

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.


Dernière édition par AristA le Sam 12 Jan 2019, 11:50, édité 2 fois
Revenir en haut Aller en bas
http://arista.lescigales.org
AristA
Maker qui quitte vraiment E-m Lv 60
Maker qui quitte vraiment E-m Lv 60
AristA

Nombre de messages : 10924
Age : 21

MessageSujet: Re: [RM 2k3] Bismillahdventure (devblog)   Lun 07 Jan 2019, 23:28

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 fufu
Revenir en haut Aller en bas
http://arista.lescigales.org
AlexRE
Admin trop trizo Lv 65
Admin trop trizo Lv 65
AlexRE

Nombre de messages : 29743
Age : 31

MessageSujet: Re: [RM 2k3] Bismillahdventure (devblog)   Mar 08 Jan 2019, 01:15

Trop bien, la renaissance de Bismillahdventure. fan hystérique

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

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

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. focus

Bon courage, AA. Boxing day

____________
Relm a écrit:
Merci pour la confirmation Gary et fuck my life.
Revenir en haut Aller en bas
http://www.alexzone.net
harusame
Flood Maker Lv 35
Flood Maker Lv 35
harusame

Nombre de messages : 1805
Age : 28

MessageSujet: Re: [RM 2k3] Bismillahdventure (devblog)   Mar 08 Jan 2019, 21:42

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

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

____________


"Mange des Chocobos au petit dej"
Revenir en haut Aller en bas
http://jeremy-lebrun.fr/
AristA
Maker qui quitte vraiment E-m Lv 60
Maker qui quitte vraiment E-m Lv 60
AristA

Nombre de messages : 10924
Age : 21

MessageSujet: Re: [RM 2k3] Bismillahdventure (devblog)   Mer 09 Jan 2019, 00:02

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

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  yeah yark ouhou gogo

On se revoit bientôt Le making c\'est dur
Revenir en haut Aller en bas
http://arista.lescigales.org
AlexRE
Admin trop trizo Lv 65
Admin trop trizo Lv 65
AlexRE

Nombre de messages : 29743
Age : 31

MessageSujet: Re: [RM 2k3] Bismillahdventure (devblog)   Jeu 10 Jan 2019, 13:38

Citation :
Maintenant vient le moment d'épiphanie.

Citation :
ça fait zirplé

Ces expressions. love


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 !

____________
Relm a écrit:
Merci pour la confirmation Gary et fuck my life.
Revenir en haut Aller en bas
http://www.alexzone.net
AristA
Maker qui quitte vraiment E-m Lv 60
Maker qui quitte vraiment E-m Lv 60
AristA

Nombre de messages : 10924
Age : 21

MessageSujet: Re: [RM 2k3] Bismillahdventure (devblog)   Sam 12 Jan 2019, 01:05

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 jv.com :noel:



Ç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 Le making c\'est dur

J'espère qu'on peut les charger directement depuis la BDD, sinon ce CBS va très vite partir en vrille je pète 1 cable woon
Revenir en haut Aller en bas
http://arista.lescigales.org
AristA
Maker qui quitte vraiment E-m Lv 60
Maker qui quitte vraiment E-m Lv 60
AristA

Nombre de messages : 10924
Age : 21

MessageSujet: Re: [RM 2k3] Bismillahdventure (devblog)   Ven 18 Jan 2019, 23:16

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. Owi toutafé olala



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.



Alex et ses smileys

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 Note

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. Oscar a les boules
  • 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. Nerd Sang

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

Dites-moi vos avis, les amis. Je me pose beaucoup de questions et, pour une fois, je n'ai pas les réponses
Revenir en haut Aller en bas
http://arista.lescigales.org
Contenu sponsorisé




MessageSujet: Re: [RM 2k3] Bismillahdventure (devblog)   

Revenir en haut Aller en bas
 
[RM 2k3] Bismillahdventure (devblog)
Revenir en haut 
Page 1 sur 1

Permission de ce forum:Vous ne pouvez pas répondre aux sujets dans ce forum
E-magination :: ~ Forums de création de jeux ~ :: Projets en cours-
Sauter vers: