Programmer un jeu de tir/shoot A-RPG en 15 minutes

Avant propos

À quoi sert ce tutoriel ? À faire un jeu de shoot ou d’action RPG où l’on tire sur les méchants pour les tuer avec notre pistolet sur RPG Maker 2003 !


À qui s’adresse ce tutoriel ? Plutôt à des gens d’un niveau intermédiaire, qui ont déjà essayé de le faire, mais qui n’ont pas réussi. Pour les plus avancés, une lecture évasive permet aussi de saisir le principe sans entrer dans les détails.

Pourquoi ce tutoriel alors que tout le monde sait déjà comment faire ce qui est indiqué dedans ? Je sais pas je suis fou je crois

Je connais rien du tout !
Voilà quelques liens utiles :

• Tutoriel sur les coordonnées de coco
  
• Tutoriels sur les variables de Joke
  
• Tutoriel pour faire un coffre qui ne s'ouvre qu'une fois par rebel59fr
  

Introduction

Le jeu de tir ou de shoot en A-RPG est le rêve du maker débutant : qui n'a jamais été impressionné et un peu jaloux devant le SURVIVE de Kilam1110 ? Des tutos pour ce faire existent déjà, comme celui de coco, celui de Molokov, ou de Naked Snake.

Ces tutoriels reposent sur la comparaison de coordonnées. Dans le cas de celui de coco ou de Naked Snake, on vérifie si deux événements sont superposées l’un à l’autre (leur coordonnées sont égales). Celui de molokov vérifie seulement si le héros qui tire et un ennemi sont sur la même ligne, puis quel ennemi est le plus proche du héros.

Ces méthodes sont efficaces, mais présentent un désavantage, qui est la lourdeur de leur mise en place : il est requis de faire des dizaines et des dizaines de comparaisons de coordonnées, pour chaque ennemi, etc. Or, on sait tous que les makers sont des fainéant (moi le premier, je suis devenu allergique aux chaînes de conditions après AA City), donc la légèreté et la versatilité d’un système sont des points très importants.

Le tutoriel que je présente ne se veut pas comme l’ultime et unique gameplay de jeu de tir imaginable, mais plus comme une approche du problème grâce à une méthode différente, un tronc sur lequel facilement grimper sur les branches. J’explique beaucoup ce que je fais, mais rien n’est sorcier : in facto, c’est très simple, et avec l’idée en tête vous serez capable de réaliser en 15 minutes un système de tir tout à fait fonctionnel.

Principe

On a une balle imaginaire. Elle n’existe que par deux variables correspondant à ses coordonnées X et Y. On la fait avancer en boucle selon la direction dans laquelle le héros tire lorsqu’on appuie sur la touche action.

Pour ne pas que la balle ne traverse les murs, on vérifie l’ID du terrain correspondant à ses coordonnées. On attribuera un ID spécifique dans la base de données aux tiles non traversables. Si la balle est sur un terrain non traversable, on l’interrompt.

Pour vérifier si la balle rencontre un ennemi, on testera l’ID de l’événement qui est à la position correspondant à ses coordonnées. Si la balle est sur un événement, on l’interrompt. Pour éviter de tirer sur les portes et les coffres, on attribuera une bande d’ID aux ennemis (ex : tous les événements à l’ID supérieur à 50 sont des ennemis).

Pour infliger les dommages aux ennemis, on incrémente à l’aide des pointeurs une variable spécifique à chaque ID d’ennemi, par exemple la variable V[100+ID]. Ainsi, la variable V[158] sera la vie de l’ennemi à l’ID n°58. On pensera à mettre une page spéciale sur l’événement à l’ID n°58 lorsqu’il est mort. C'est là l'originalité.

C’est tout !

Table des matières :

• Programmer l'événement-maître
  
  
  
  • L'appui de touche
    
  • Le déplacement de la balle imaginaire
    
  • Le test d'ID terrain
    
  • Le test d'ID d'événement
    
  
  
  
• Programmer l'ennemi
  
• Améliorations secondaires : enrichir le gameplay
  
  
  
  • Système de straff
    
  • Rajouter des munitions
    
  • Ranger/sortir l'arme
    
  
  
  
• Améliorations tierces : si vous voulez en faire un vrai jeu
  
  
  
  • Rajouter des armes
    
  • Faire respawn les ennemis
    
  • Faire une intelligence artificielle plus développée
    
  • Rajouter une barre de vie et de munition
    
  
  
  
• Améliorations quartes : si vous voulez faire le ouf
  
  
  
  • Rajouter des animations/des interactions avec l'ennemi touché
    
  
  
  
• Le défi des 15 minutes
  
  

Programmer l’événement-maître

L’appui de touche

Créez un événement en processus parallèle. Demandez l’appui d’une touche (ici on fera avec la touche de validation, entrée ou espace) en décochant attendre l’appuie d’une touche, puis vérifier si la variable vaut 5 (= touche entrée). Éventuellement, rajoutez un petit effet sonore, puis un “attendre” au bout, histoire qu’on ne puisse pas tirer trop vite (ça fera office de cooldown de votre arme).

Pourquoi ne pas cocher “attendre qu’une touche soit appuyée” ? C’est parce que sinon, on ne pourra pas programmer des mitraillettes ou des armes automatiques, qui tirent en boucle lorsque l’on maintient la touche appuyée.

Oui, mais, si je veux une arme non automatique (où l'on ne tire qu'un coup à la fois) ? On va simuler une attente d’appui de touche alors. Tout en bas, rajoutez un autre test de touche pour la touche entrée, mais vérifiez si cette variable vaut 0 (= pas de touche appuyée), dans ce cas vous activerez l’interrupteur “touche relâchée”. On testera ensuite l’état de cet interrupteur pour les armes que vous choisirez comme non automatiques. Je place une condition sur ce test de touche, pour qu’il ne soit effectuée que lorsque l’interrupteur touche relâchée est désactivé, afin d’éviter de faire des tests pour rien.


Mon héros tire lorsque je suis dans un dialogue ! Mettez comme condition d’activation de cet événement un interrupteur, et pensez à le désactiver lorsque vous parlez à quelqu’un

Le déplacement de la balle imaginaire

On a fait les formalités. Passons à la programmation de la balle imaginaire. On rend égale ses coordonnées initiale à celles du héros, on stocke aussi la direction du héros dans une variable. Dans une boucle, on incrémente les coordonnées de la balle selon sa direction.

Astuce : Si vous peinez à savoir quelle valeur à la variable direction lorsque le héros regarde vers la gauche ou la droite, pensez à votre pavé numérique. Les valeurs concordent avec les flèches.
7 8 9 -----> 8 = haut
4 5 6 -----> 4 = gauche ; 6 = droite
1 2 3 -----> 2 = bas

Attention ! Ne lancez pas le jeu maintenant. La boucle tournera à l’infini, et pourra faire exploser votre ordinateur. Peut être.


Le test d'ID terrain

Notre balle imaginaire se déplace, mais se fiche complètement des murs ou des zones infranchissables. Pour contrer cela, dans l’éditeur de chipset de la base de données, on attribue aux tiles praticables un ID (un “type de terrain”) particulier, qu’on peut créer dans l’éditeur des types de terrains de la base de données aussi.


Ici, j’ai attribué l’ID 22 aux environnements que je juge impraticables pour les balles (les murs) et 21 à ceux praticables (les sols). Le numéro est arbitraire, vous pouvez le choisir comme cela vous arrange.

Ensuite, on effectue le test à proprement dit à l’aide de la commande “Stocker l’ID d’un terrain” (page 2, en bas à gauche), pour les coordonnées correspondant à celles de notre balle imaginaire (balle X et balle Y). Si l’ID est différent de 21 (l’ID de notre tile praticable), on sort de la boucle.


J’ai des tiles impraticables sur la couche haute et ma balle les traverse quand même ! Il est nécessaire que vous placiez un tile sur la couche basse avec le bon ID. Si votre tile en dessous est du sol, éditez votre chipset pour y rajouter un second tile identique graphiquement, mais avec un ID différent dans l’éditeur. On pourrait penser que cette solution est casse-pieds, mais au contraire, elle vous donne une meilleure maîtrise : des tiles impraticables pour le héros peuvent l’être pour vos balles (ex : des tables), et vice versa (ex : des échelles) !

Comment gérer mon autotile correspondant au toit dans un intérieur (avec le symbole “carré” dessus), qui est à la fois praticable et impraticable ? Je vous conseille de rajouter sur les côtés des tiles identiques graphiquement à cet autotile avec le bon ID.

Spoiler:

Le test d'ID d'événement

On veut que lorsque notre balle imaginaire se retrouve aux mêmes coordonnées qu’un ennemi, on soustrait 1 à la variable vie de notre ennemi. On va pour cela utiliser la commande “stocker l’ID d’un événement” (page 2, en bas à gauche) avec les coordonnées de la balle. Si l’ID est différent de 0, cela signifie qu’il y a un événement sur la case où se situe notre balle imaginaire.

J’ai dit dans la partie “Principe” qu’on attribuait une bande d’ID d’événements aux ennemis : on va donc seulement vérifier si l’ID de l’événement est compris dans l’intervalle des valeurs correspondantes. On fait ça pour éviter de pouvoir tirer (et donc tuer) sur des PNJ, des coffres, des portes, etc. Ici, j’ai choisi les ID entre 50 et 100, mais c’est à vous de le choisir et de l’adapter en fonction de vos besoins. Si vous avez un très gros projet, vous devez avoir moyen de définir ces valeurs dynamiquement en fonction des maps.

Comme énoncé dans “Principe”, on attribue à chaque ID d’événement ennemi une variable correspondante, dont l’ID est du style V[100+ID événement], en gros V[constante+ID de l’événement ennemi]. Pour cela, on s’aide des pointeurs.

Qu’est ce qu’un pointeur ? Le pointeur va prendre l’ID de la variable qu’on veut modifier. Pour modifier une variable, à la place d’indiquer son ID manuellement, on indique le pointeur. RM 2k3 fait ensuite le boulot à notre place : si le pointeur vaut 150, et qu’on rend égal la variable pointée à 4, la variable à l’ID 150 vaudra désormais 4. C’est pratique car ça évite de faire plein de conditions, et je déteste faire plein de conditions.

J'ai rien compris du tout ! Pas de panique ! Pour plus de détails sur les pointeurs, ce tutoriel de Joke est top.


Voilà. Les deux tiers du boulot sont faits !

Programmer l’ennemi

Notre ennemi est un nouvel événement dont l’ID est compris dans l’intervalle défini précédemment, qui a deux pages. La première est une page où l’ennemi est en mode “aggressif”, c’est à dire qu’il marche vers le héros (mais pas trop vite, c’est relou les zombies qui sprintent), il s’active lorsqu’il est en contact événement/héros. À l’intérieur, il y a ce que vous voulez qui arrive quand votre héros est touché. Je n’ai pas particulièrement développé cet endroit, c’est libre, c’est à vous de choisir ce qui va se passer. J’ai indiqué plusieurs idées sur l’image, mais cela ne dépend que de vous.

L'astuce d'Alex RE : Pour éviter d'avoir à modifier tout les ennemis du jeu si vous voulez faire un tout petit ajustement sur l'attaque de vos monstres, mettez ce code dans un événement commun "attaque ennemie" (condition d'activation appel). Dans la première page de l'événement de votre monstre, vous ne mettrez donc qu'une seule commande, l'appel de l'événement commun "attaque ennemi".


La deuxième page correspond au moment où l’ennemi est mort, elle est en processus parallèle. Elle a pour condition d’activation la variable V[constante + id de l’événement] qui est égale à l’opposé de ses PV. Dans le cas ici présent, on avait choisi 100 comme constante pour nos pointeurs, et j’ai pris 5 comme nombre de PV. Je teste donc si la variable V[100+52] (cet événement a pour ID 52), donc V[152], est égale à -5. Dedans, on se contente d’effacer l’événement. Vous pouvez rajouter une petite animation.


Je peux tuer mon ennemi, mais j'entends encore l'effet sonore d'un monstre qui agonise ! Il faut tester la variable vie correspondant à l’événement en dessous de la balle imaginaire. Cela se fait dans la partie “test ID d’event”. Si elle est supérieure à l’opposé de sa vie (donc si il est mort), on ne lui retire pas de PV. Ici, on imbriquerait tout le bloc de modifications de variables dans une autre condition “Si V[100+ID] supérieure à -5”.

Attention : RM 2k3 ne peut pas utiliser de pointeur dans les conditions. Il faudra donc utiliser des variables tierces pour stocker la valeur de la vie de l'événement.


Vous pouvez essayer allouer dynamiquement la valeur de la vie en passant par encore une autre variable (par exemple V[200+ID]) qui contiendrait la vie maximale de votre ennemi. Vous testeriez alors “Si V[100+ID] supérieure à V[200+ID]”.  

Voilà, vous pouvez dors et déjà tester votre projet, ça marche bien, et en 15 minutes vous pouvez faire rapidement tout ce processus ! On peut intégrer autant d’ennemi que l’on veut au jeu, avec une modification minime sur chacun d'eux. Mais n'oubliez pas de modifier la variable sur la deuxième page !

Améliorations secondaires : enrichir le gameplay

Je n'inclue pas dans ces améliorations les idées graphiques etc. C'est uniquement sur le point de vue de la programmation.

Système de straff

Le straff, c’est le système de fixation de direction ; à mon avis c’est essentiel. Lorsque l’on maintient une touche, notre héros va lui aussi maintenir sa direction. Ça peut paraître anodin, mais c’est grave pratique et beaucoup plus agréable à jouer. Le nom et l'idée me viennent de molokov.

Une des solutions imaginables est de créer un événement, qui est un autre processus parallèle, et qui teste l’appui d’une touche sans attendre que l’on appuie dessus. Il vérifie si la touche appuyée correspond, et dans ce cas il fixe la direction du héros. Sinon, il arrête la fixation du héros.

Spoiler:

Mais attention ! Avec cet événement simpliste, aucun déplacement appliqué au héros ne peut marcher (impossible d’utiliser la commande "déplacer un événement" sur le héros). C’est parce qu’à toute les frames, le “déplacer/modifier” de cet événement sera prioritaire sur toute autre déplacer/modifier événement. Pour contrer à cela, je préconise un autre événement, un peu plus complexe. À l’aide d’un interrupteur, on ne va fixer la direction du héros qu’une seule fois lors du premier appui de la touche maj, et la défixer qu’une seule fois aussi, lors du premier non appui de touche. C’est une méthode similaire à celle que l’on a utilisé dans l’appui de touche de l’événement-maître.


Rajouter des munitions

Bon, ça paraît peu probable à prime abord quand on regarde des films hollywoodiens, mais c’est vrai qu’on peut rarement tirer à l’infini, cela nécessite des munitions. Ce n’est rien de sorcier, il suffit d’englober tout ce qu’on avait déjà fait dans l’événement maître pour vérifier si une variable munition est supérieure à 0, et de retirer 1 à cette variable si oui. Vous n’oublierez pas de faire en sorte que l’on puisse récupérer des balles à certains endroits. J’en profite pour mettre tout l’événement-maître, si vous avez raté quelque chose.

Spoiler:

Ranger/sortir l'arme

C'est décoratif, mais moi j'aime bien. Définissez un nouvel interrupteur "arme sortie". Dans l'événement maître, imbriquez tout ce qui est actuellement dans la condition "Si touche appuyée = 5" (//On a appuyé sur la touche Entrée) dans une autre condition "si l'interrupteur arme sortie = ON". Indépendamment, testez si l'on appuie sur la touche MAJ, ou Esc, ou tout autre touche que vous voulez définir comme celle sortant l'arme. Dans ce cas, activez l'interrupteur "arme sortie". Pensez à faire de même pour une touche qui servira à ranger l'arme et désactiver l'interrupteur "arme sortie".

À ce stade, vous pouvez déjà refaire SURVIVE v1.0, il vous suffit de copier/coller 100 ennemis sur une map

Attention ! N'oubliez pas de changer à chaque fois la variable vie du deuxième onglet, pour qu'elle corresponde bien à celle de l'ennemi ! (V[Constante + ID])

Améliorations tierces : si vous voulez en faire un vrai jeu

Bon, là on a largement dépassé les 15 minutes. Si vous voulez creuser un peu plus profondément, voilà de la matière.

Rajouter des armes

En définissant une variable comme "arme équipée" et en testant sa valeur, vous êtes capables d'altérer le comportement qu'elle aura dans l'événement maître. Je ne vais pas m'attarder sur le sujet, puisque ça me semble être relatif à chacun, mais je vous cite des choses que vous pouvez très très facilement modifier de cette manière :

• Le cooldown de l'arme (c'est le "Attendre 0.2 Sec" qui est à la fin). Augmentez le pour faire un fusil à canon scié !
  
• Les dégâts de l'arme. Au lieu de retirer 1 à la variable vie de l'ennemi, retirez plus !
  
• Arme automatique : enlevez la condition "Si interrupteur touche relâchée : ON" pour que l'on puisse tirer indéfiniment et non plus par acoup.
  
• Changer les effets sonores et le coût en munition
  
• Changer le tile qui est traversable : peut être qu'un lance flamme est inefficace si vous êtes dans l'eau, mais qu'un pistolet, oui ?
  
• Limite de distance
  

Faire respawn les ennemis

Sur la page de la mort de l'événement, au lieu de mettre un "effacer cet événement", mettez un "Attendre" assez long (une trentaine de secondes), puis rendez égale la vie de cet ennemi à 0.

Je vais devoir changer deux variables pour chaque ennemi à chaque fois lorsque je le copie colle ? RPG Maker 2003 ne propose pas de méthode directe pour obtenir directement l'ID d'un événement. Une astuce détournée consiste à rendre égale deux variables tests aux coordonnées X et Y de "cet événement", puis d'utiliser la commande "stocker l'id d'un événement" en y précisant les deux variables tests précédentes. La variable dans laquelle l'ID sera stocké sera celui de "cet événement".

Une intelligence artificielle plus développée

Reprenons notre événement de l'ennemi. Ce qui n'est pas terrible, c'est que pour l'instant il ne fait que suivre le héros tout le temps ; c'est pas très logique lorsqu'il est à l'autre bout de la map. On souhaite faire un ennemi qui, lorsque le héros n'est pas là, fait sa vie, et qui une fois vois le héros apparaître dans une zone autour de lui, va alors chercher à le pourchasser. Une fois qu'il le pourchasse, pas de raison qu'il s'arrête !

Pour cela, on rajoute une page en première position. La page 1 sera la page où l'ennemi est inactif (iddle), la page 2 sera celle où il est agressif, et la page 3 sera celle où il est mort.

La page 1 va être en processus parallèle. Dedans, on va vérifier la distance de cet événement par rapport au héros à l'aide d'une technique (expliquée par Naked Snake) détaillée dans l'image. On peut utiliser les mêmes variables pour tous nos événements ennemis, ce n'est pas très important. Si cette distance est inférieure à une valeur donnée, on va activer un interrupteur du type I[Constante + Id de l'événement ennemi], ici I[40+ID], un peu comme pour la vie de ces monstres. J'utilise encore une fois les ID d'événements pour éviter de faire plein de conitions, et pouvoir copier/coller facilement ces événements sur la carte.


Attention ! Ici j'ai fait en sorte que l'ennemi ne bouge pas dans sa phase inactive. Cependant, vous pouvez très bien faire qu'il exécute une routine, un va et viens, voire peut être un déplacement au hasard. Cela dépend du level design que vous souhaitez adopter.

Dans la seconde page, c'est la phase agressive. Elle est désormais activée par l'interrupteur I[Constante+ID] qu'on a activé en page 1. Ici, c'est l'interrupteur I[40+63] donc I[103] qui doit être vérifié. Sur cette page, on réadopte le comportement agressif de notre zombie de tout à l'heure : il marche vers le héros, il inflige des dégâts, activation en contact événement/héros, etc.

Spoiler:

Rajouter une barre de vie et de munition

En effet, ce serait pratique. Je vous renvoie vers un tutoriel spécialisé sur le sujet.

Améliorations quartes : si vous voulez faire le ouf

Rajouter des animations/des interactions avec l'ennemi touché

C'est une section que j'ai volontairement passé sous silence. Si RPG Maker 2003 nous permet facilement d'incrémenter une variable pointée, c'est plus compliqué de faire des animations, du style flasher l'ennemi qui est touché, faire apparaître une gerbe de sang sur lui, le faire reculer d'un pas en arrière, etc. Le seul cache-misère que j'ai utilisé pour l'instant, c'est un effet sonore, mais faut le dire : c'est bof. Pour résoudre ça, je vois deux méthodes.

Première méthode : encore un interrupteur.
La première consiste à activer (encore) un autre interrupteur du style I[Constante+ID de l'événement] dans l'événement-maître. Lorsque la balle va toucher un ennemi, elle va activer cet interrupteur. Dans la programmation de l'événement ennemi, on va faire une nouvelle page en antépénutième position (juste avant celle de mort), activée par cet interrupteur I[Constante+ID de l'événement]. Dans cette page, on case alors toutes les animations que l'on veut faire : flasher cet événement, afficher une animation de combat sur cet événement, fixe la direction et fuit le héros d'un pas... Puis, on désactive cet interrupteur.

Cette méthode peut fonctionner. Mais entre ça et l'intelligence artificielle, on commence à avoir un peu beaucoup d'interrupteurs et de constantes. De plus, il peut y avoir des bugs, à cause des priorités des pages, etc. Pour cette raison, je ne la détaille pas.

Seconde méthode : avec DynRpg
DynRPG est un patch qui permet d'appliquer des mini-patchs (plugins) très puissants à votre jeu super facilement. Je vous renvoie à la présentation d'Alex RE sur le sujet.

Il vous est possible d'utiliser le plugin DynParams (que vous installez comme ceci) afin de préciser n'importe quel argument d'une commande en event par une variable. Le manuel d'utilisation est en anglais et un peu abscons à saisir, mais en gros c'est du pain béni pour ce que l'on veut faire.

En gros, dans notre événement-maître, au même endroit que là où on joue l'effet sonore ("cow" dans mon exemple), on précise simplement dans des commentaires :

<>// @dynparams_add param 1, V12
<>// @dynparams_overwrite_next
<>Flasher événement ou héros : Héros, 0.1s, pausé

Et cela va flasher l'événement dont l'idée est dans la variable V[12] (c'est pour cela que l'on indique V12, on peut remplacer V12 par V84 ou autre, selon les besoins). Le fonctionnement est très bien détaillé dans le readme du plugin, et cela revient à grossièrement appliquer le code ci dessus dérivé à toutes les sauces.

C'est la fin de ce tuto qui s'éternise un petit peu trop. Allez, bon making !

Conclusion : réaliser le tutoriel en 15 minutes

Pour ne pas faire mentir le titre, je relève le défi des 15 minutes dans cette vidéo, comme quoi c'est archi faisable de tout programmer en un quart d'heure yo

Spoiler:

Voilà le lien de la démo que j'ai réalisé en 15 minutes sous la contrainte de la caméra. Autant dire que c'est un système qui conviendra parfaitement à toutes les sessions de speed-making et Delirium, un vrai sport !

Bon making à tous !

15 minutes, 15 minutes, haha... faut lire vite quand même.
En tout cas, c'est super complet, bien présenté. J'espère que ça servira à ceux qui veulent en faire un.
Ca t'a pris comme ça, AA, de faire un mega-tuto alors qu'on en a plus depuis des lustres ?
Trop bien quand tu es dynamique.

Citation :

Tutoriel pour faire un coffre qui ne s'ouvre qu'une fois par rebel59fr

jerry

OMG, ça doit être le meilleur tuto sur E-magination.

En effet, pour les 15 minutes c'est un peu loupé, je crois.

Tu pourrais fournir une démo téléchargeable, pour ceux qui veulent juste copier/coller le système. (Bon, en étant plus optimiste : ceux qui veulent comprendre en voyant directement depuis une vraie démo.)

Il y a deux points d'amélioration que je verrais, et tous deux concernent les ennemis qu'on doit éditer à chaque fois qu'on les copie-colle. Ce serait mieux de pouvoir copier-coller simplement, bêtement, et ne rien modifier. Pour cela, je suggère :

- Faire un évènement (sur la map ou évènement commun) qui gère comment l'ennemi se comporte quand il touche le héros, et un autre qui gère quand l'ennemi est touché par le héros. En gros, si tu veux modifier ces comportements tu modifies juste cet/ces évènement(s) et pas tous les ennemis que tu as copiés-collés ce qui serait très très long, oui, oui.

- Faire un évènement commun qui téléporte l'évènement d'un ennemi qui meurt dans une zone invisible pour le joueur : une sorte de charnier pour ennemis. Cela évite d'avoir une page "vide" pour chaque ennemi, sur laquelle il faut changer la variable d'activation. Ça nécessite cependant DynRPG/DynParams, puisqu'on ne peut pas déplacer un évènement selon son ID sinon.

[[ Ce que j'ai fait dans G.Rémy Unleashed me donne une autre idée, qui peut s'appliquer aux deux précédents points. Sans DynRPG, on peut s'en sortir avec la commande "Appelez l'évènement dont l'ID est dans et dont la page est dans " ! En gros, il faut que sur une page, l'évènement ennemi ait un simple "Effacer cet évènement". ]]

AristA a écrit:

Attention ! Ne lancez pas le jeu maintenant. La boucle tournera à l’infini, et pourra faire exploser votre ordinateur. Peut être.

Haha.

AristA a écrit:

Pourquoi ne pas cocher “attendre qu’une touche soit appuyée” ? C’est parce que sinon, on ne pourra pas programmer des mitraillettes ou des armes automatiques, qui tirent en boucle lorsque l’on maintient la touche appuyée.

Oui, mais, si je veux une arme non automatique (où l'on ne tire qu'un coup à la fois) ? On va simuler une attente d’appui de touche alors. Tout en bas, rajoutez un autre test de touche pour la touche entrée, mais vérifiez si cette variable vaut 0 (= pas de touche appuyée), dans ce cas vous activerez l’interrupteur “touche relâchée”. On testera ensuite l’état de cet interrupteur pour les armes que vous choisirez comme non automatiques. Je place une condition sur ce test de touche, pour qu’il ne soit effectuée que lorsque l’interrupteur touche relâchée est désactivé, afin d’éviter de faire des tests pour rien.

Ah oui, j'avais jamais pensé à ça !

Bon travail Arista, ça fait plaisir à voir =D

@Choco : Gros merci !

Relm a écrit:

Ca t'a pris comme ça, AA, de faire un mega-tuto alors qu'on en a plus depuis des lustres ?
Trop bien quand tu es dynamique.

Merci beaucoup ! Je l'ai fait surtout parce qu'après j'avais peur d'oublier comment on faisait

AlexRE a écrit:

Il y a deux points d'amélioration que je verrais, et tous deux concernent les ennemis qu'on doit éditer à chaque fois qu'on les copie-colle. Ce serait mieux de pouvoir copier-coller simplement, bêtement, et ne rien modifier. Pour cela, je suggère :

- Faire un évènement (sur la map ou évènement commun) qui gère comment l'ennemi se comporte quand il touche le héros, et un autre qui gère quand l'ennemi est touché par le héros. En gros, si tu veux modifier ces comportements tu modifies juste cet/ces évènement(s) et pas tous les ennemis que tu as copiés-collés ce qui serait très très long, oui, oui.

C'est vrai que les ennemis c'est le truc que j'ai le moins poussé, par manque d'expérience nul doute. Bonne astuce pour l'événement commun, c'est annodin mais fort pratique, et ça colle avec l'idée du système (copier coller des événements partout ! wouw !   )

D'ailleurs, j'aurai dû faire ça dans mon jeu, parce que j'ai plusieurs fois galéré à tout rechanger ce que faisaient les ennemis. Je vais l'inscrire dans le tuto !

Citation :

- Faire un évènement commun qui téléporte l'évènement d'un ennemi qui meurt dans une zone invisible pour le joueur : une sorte de charnier pour ennemis. Cela évite d'avoir une page "vide" pour chaque ennemi, sur laquelle il faut changer la variable d'activation. Ça nécessite cependant DynRPG/DynParams, puisqu'on ne peut pas déplacer un évènement selon son ID sinon.

[[ Ce que j'ai fait dans G.Rémy Unleashed me donne une autre idée, qui peut s'appliquer aux deux précédents points. Sans DynRPG, on peut s'en sortir avec la commande "Appelez l'évènement dont l'ID est dans et dont la page est dans " ! En gros, il faut que sur une page, l'évènement ennemi ait un simple "Effacer cet évènement". ]]

Téléporter les ennemis dans une autre zone est vachement plus astucieux, que d'avoir à tester la vie de l'événement dans l'événement du shoot même et à faire plein de variables secondaires, je n'y avais pas pensé ! En plus, ça permettrait de gérer facilement des cycles de respawn et tout, pour faire un jeu typé arcade : on n'efface pas les événement, mais on ne les garde pas non plus.

C'est un des trucs que j'aime bien avec cette méthode : il y a plein d'idées que l'on peut y intégrer grâce aux ID des événements, le tout en quelques lignes de codes. Elles semblent toutes aller de soi, et aucune n'est contradictoire avec l'autre. En plus, c'est odieusement simple à faire  

Je n'ai pas super bien saisi l'intérêt de ton idée entre crochet. Pourquoi faire encore une autre page avec effacer l'événement, alors qu'il y a déjà une page correspondant au moment où l'ennemi est mort ? Ça ne serait pas un peu redondant ?

Citation :

Tu pourrais fournir une démo téléchargeable, pour ceux qui veulent juste copier/coller le système. (Bon, en étant plus optimiste : ceux qui veulent comprendre en voyant directement depuis une vraie démo.)

Très très juste ! J'avais omis ce détail qui pourtant est toujours un bonus, la petite poire sucrée du tuto.

D'ailleurs, bouh à vous : ça se programme parfaitement en 15 minutes ! J'en veux pour preuve cette vidéo où je reprogramme tout ça en 15:26, un peu plus de 15 minutes, mais pour me dédouaner je joue au jeu, je fais des erreurs, et je fais une map avec 30 ennemis. En 10 minutes j'avais déjà à peu près fini. Voilà le lien pour télécharger ce semblant de démo, qui aurait plus sa place dans un delirium.



Bon, j'admet qu'en 15 minutes c'est un peu lacunaire et pas très ouf, j'ai un peu donné la durée au pif. C'était surtout pour que le titre soit plus accrocheur, et avoir de meilleurs résultats dans les moteurs de recherche

Je compte retravailler ça (graphiquement et au niveau des ennemis) pour proposer un truc un peu plus propre et plus "vitrine"

Toutes ces années où Slump a cherché comment faire un "A-RPG avec projectiles"... et il fallait juste 15 minutes ?


Bah en fait, c'est très rapide alors, c'est encore mieux.
La vidéo est un réel point vendeur pour ce genre de tutos qui peuvent sembler longs et complexes, ça met en confiance l'utilisateur et permet d'être un support supplémentaire pour plus de clarté, bref, superbe tuto, encore merci !

Partager ça avec nous, même pour t'en souvenir est très cool.

Le AA jeune et dynamique me manquait !
Ce serait vraiment chouette si tu avais plus de temps pour prendre en charge les sections making de E-m, tu sembles travailler chez toi mais on voit rarement les choses, c'est pas si grave, mais hésite pas à partager le plus possible.

Je propose que ce tuto soit mis en avant sur une news Guelnika et sur la bannière de l'index du forum, c'est tellement accrocheur comme titre et en plus vrai et bien réalisé.
Je vais m'occuper de la news, rapidement.




PS : peux tu juste éditer ton premier post et y inclure la vidéo ? merci

Voilà ! Merci pour l'initiative ! j'en ai aussi profité pour un peu corrigé bbc code du tutoriel sur guelnika au passage

Il est fou ce AA

Très bon tuto en tout cas, bravo. Je pense que je le testerai quand j'aurai le temps ( Et tu pourras avoir l'honneur d'accéder au club très fermé des gens ayant réussi à me faire lancer RM )

AristA a écrit:

Je n'ai pas super bien saisi l'intérêt de ton idée entre crochet. Pourquoi faire encore une autre page avec effacer l'événement, alors qu'il y a déjà une page correspondant au moment où l'ennemi est mort ? Ça ne serait pas un peu redondant ?

C'est pareil, c'est dans l'idée de ne pas avoir à changer l'interrupteur ou la variable pour chaque ennemi. La commande "Effacer cet évènement" est une sorte d'interrupteur local pour chaque évènement, sauf qu'il n'a qu'une seule conséquence : la disparition totale de l'évènement. Il évite de devoir changer l'interrupteur pour chaque ennemi. En plus, il n'y a pas de commande "Effacer un évènement selon son ID" (peut-être avec DynParams ?), donc il faut que l'effacement vienne de chaque évènement en lui même. Heureusement, appeler une page où se trouve la commande "Efface-moi" revient un peu à gérer cela par un évènement commun, mais de façon détournée.

Je ne sais pas si je suis clair.

Sinon, regarde mes ennemis dans G.Rémy Unleashed : l'interrupteur This->Mort appelle la commande "Effacer cet évènement", c'est diabolik.

Heyy mais c'est grave malin

Du coup dans le big événement-maître, lorsqu'on retire 1 PV, il suffirait de rajouter une condition qui teste "Si PV = 0" ou quelque chose du style pour appeler la page "mort" de l'événement correspondant.

Habile Alex. Très habile.

Du coup il faut réécrire le tutoriel !

On approche du tutoriel parfait

Merci AristA pour ce tutoriel. C'est vraiment bien foutu, et ça va m'être utile pour mon jeu Western. Je vais le réadapter un peu pour pouvoir gérer des projectiles plus long comme des flèches, des lances, etc.

Franchement merci !

Merci Cheikh !

@Slump : On va dire que ça restera un tutoriel "ouvert" où chacun peut y trouver des améliorations

PS : je viens de voir qu'en 2011, j'avais déjà prédit ce tutoriel... Ça va je prends mon temps pour faire les choses

On en avait déjà parlé à l'époque de ce système d'évènement virtuel et de test de l'ID terrain associé.

Tu en as fait une super explication en tout cas, je suis réellement impressionné

Si tu veux méditer là-dessus :
Il est également possible avec un système similaire de représenter un champ de vision d'un évènement (pour un jeu d'infiltration par exemple) et qui prendrai en compte d'éventuels obstacles.

Concrètement tu décides d'un ensemble de cases à tester (dans le cas où le champ de vision serait entièrement libre, i.e. aucun obstacle).
Ça peut être une forme simple (un rectangle) :
.H.
xxx
xxx
xxx
xxx
xxx

Ou plus complexe (un triangle) :
..H..
.xxx.
.xxx.
xxxxx
xxxxx

Puis pour chacune de ces cases tu lances ton évènement virtuel vers cette case (avec un peu de math et d'équations linéaires) et tu vérifies qu'il ne rencontre aucune case à l'ID interdit :
..H..
.x?x.
.??x.
x?x?x
oxxox

Pas super évident avec les maths foireuses de RM mais le résultat est plutôt sympa.

Merci beaucoup Manderr ! Et, wow, en effet, c'est très malin ! (je n'y aurais jamais pensé pour le coup )

Sinon, il y a le plug-in DynRPG "champ de vision". => http://rpgmaker.net/engines/rm2k3/utilities/33/

Comment il se la pète l'autre avec ses plugins

Encore une autre petite astuce (qui me trottait en tête) dans le cadre de ce tutoriel qui décidément n'aura jamais fini d'être perfectible !  

J'ai retrouvé un ancien projet où j'utilise une autre méthode pour gérer les attaques des ennemis. De mémoire, c'est celle qui est utilisée dans IParadise Gaiden : Le Château du souvenir d'Astram/Dastrem.

Un des ennuis avec la méthode que j'ai présenté, qui consiste à directement intégrer dans le code de l'événement les dégâts et l'animation sur le héros, c'est que plusieurs ennemis peuvent attaquer en même temps le héros. De la même manière, un ennemi peut attaquer plein de fois le héros à la suite en un très court laps de temps. Mettre des "Attendre" dans le code de cet événement ne résout pas le problème : l'événement étant en contact événement/héros, il bloquera les déplacements du héros. Cela peut résulter en une attaque ennemi frustrante, difficile à maîtriser et à rendre fun.

En quoi la technique d'Astram/Dastrem va-t-elle pouvoir nous aider pour résoudre ce problème ?

En bref : Dans la phase agressive des ennemis, lorsque l'ennemi entre en contact événement/héros, activer simplement un interrupteur. Cet interrupteur active un événement commun en processus parallèle qui s'occupera de jouer l'animation sur le héros, lui retirer des PV, d'attendre un peu, puis désactiver l'interrupteur.


Quelle différence ? Désormais, un seul monstre peut attaquer en même temps le héros. De plus, les ennemis ne pourront l'attaquer qu'à un rythme précis, que l'on définira par le "Attendre" dans cet événement. Cela permet de mieux équilibrer les dégâts par seconde des ennemis, de rendre le jeu moins frustrant car plus maniable, et donc globalement de rendre le jeu plus maîtrisable.

Dans cet exemple, même si le joueur est entouré des quatre côtés par des ennemis en surnombre, il ne se fera attaquer qu'au maximum une fois toutes les secondes : ça lui laisse le temps d'étaler son jeu et de ne pas se faire enchaîner tout le temps, pour se dégager. C'est plus amusant !

N'hésitez pas à alterner les méthodes selon le gameplay envisagé

Dans ma partie de G.Rémy, quand un monstre touche le héros, un évènement commun "Invincibilité temporaire" s'active. C'est un peu le même principe.

Je crois que ça rend les ennemis traversables temporairement aussi.

C'est obligatoire dans un jeu de type A-RPG.

C'est très utile et je ne l'ai pourtant jamais lu nul part

J'ignorais que c'était si usité. Surtout dans un jeu tel que G. RÉMY UNLEASHED dont GARYWISS6 doit TERMINER SA PARTIE.

AlexRE a écrit:

C'est obligatoire dans un jeu de type A-RPG.

je ne savais pas pardon

Utilisé aussi dans Koyomon