Oniromancie: Tutoriels - )Joke's tuts)- (4) Base de programmation : Qu'il se passe automatiquement quelque chose dès qu'une valeur change !


Comment ça marche?

Aëdemphia
Par Sylvanor

Fighting Robots Quest
Par Boulon

Forstale
Par Ødd Clock

Geex
Par roys

Inexistence
Par Falco

La Légende d'Ibabou
Par Zaitan

Lije
Par Gaetz

LoveMaster
Par Cuddlefox

Sarcia
Par Kaëlar

Super Mario RPG - Lost Souls
Par Omegabowser

News: Concours des Alex d'Or 2017-18: (...) / News: MegaMaker : créez votre propre (...) / News: Test de Tinker Quarry / Sorties: Leave the Room / Jeux: Leave the Room /

Chat  (11 connectés)

Bienvenue
visiteur !






publicité RPG Maker!

Statistiques

Liste des
membres


Contact

79 connectés actuellement

9179637 visiteurs
depuis l'ouverture

714 visiteurs
aujourd'hui

Groupe Facebook

Barre de séparation

Partenaires




TOP
GAMEMAKING


Les 5 plus
visités

Lunae, le baz'arts d'Emz0

Le studio du chat vert

Pixelandgame

Tashiroworld

HeyMakeGames

Au hasard

HeyMakeGames

Shadow Temple

Co-RPG

Les deux derniers

Lunae, le baz'arts d'Emz0

Le studio du chat vert

Nos autres partenaires

Devenir
partenaire


Barre de séparation

Un site du réseau
War Paradise

Annuaires référenceurs





)Joke's tuts)- (4) Base de programmation : Qu'il se passe automatiquement quelque chose dès qu'une valeur change !
Ecrit par Joke



Ce tutoriel est utilisable pour tous les RPG maker ! (2000, 2003, XP, VX)

Ce tutoriel simple vous explique un truc super utile :
Comment détecter si le contenu d'une variable a changé !
"Hein ? Quoi ?"
Je veux dire par là faire en sorte qu'il se passe quelque chose à chaque fois qu'une valeur stockée dans une variable change !
2ème "Hein ? Quoi ?"
Ben oui ! Qu'il se passe quelque chose à chaque fois que la position du héros change (bruit de pas), ou que le nombre de points de vie change (les afficher), ou le nombre de munition, etc que des actions se fassent automatiquement quand une valeur change, donc, qu'un événement commun détecte quand est-ce qu'une variable change de valeur !
"Aaaah !"


Attention, c'est la technique la plus simple du monde, mais je vais quand même raconter ma vie, désolé ! Alors n'ayez quand-même pas trop la flemme de lire ! =)


Principe :




Le principe est vachement simple !

Il suffit d'avoir aux variables que l'on veut surveiller, leur double en "old" (ancien en anglais, trois lettres c'est plus court^^)

Quoi ??

Ben par exemple, si on veut faire en sorte qu'on entende le bruit des pas du héros, et pouvoir compter le nombre de ses pas, par la même occasion !
Il faut donc un bruit de pas à chaque fois que la position du héros change ! Et détecter si sa position change, ça se fait avec cette fameuse technique !

On aurait besoin de "X héros" et "X héros old", puis "Y héros" et "Y héros old" !

Il faut que les variables "X/Y héros" soient mis à jour tout le temps (prennent constamment les coordonnées du héros), et que les variables "X/Y héros old" ne soient mise à jour que lorsqu'on détecte grâce à elles les changements de position du héros ! Donc quand "X héros" deviendra différent de "X héros old", ou "Y héros" deviendra différent de "Y héros old" ! Si une de ces deux conditions étaient remplie, ça voudrait dire que la position du héros a changé en X ou Y, donc on joue l'effet sonore du bruit de pas, et augmente une variable "nombre de pas" de 1 pour compter le nombre de pas.

C'est qu'un exemple comme mille autre, cette technique et aussi et surtout utile pour réaliser les affichages de jauge à l'écran ! Vous voulez faire une jauge de PV ? Des quarts de cœur ? Afficher un nombre avec les munitions ? Tout ça ne doit s'afficher UNIQUEMENT lorsqu'on change de map ET lorsque l'une de ces variables change, à aucun autre moment, c'est pour cela que vous aurez besoin de cette fameuse technique !

Mettre à jour une variable : Quand je dis ça, je veux dire qu'on lui donne la valeur de ce qu'on veut contrôler, par exemple on lui donne le nombre de PV actuel, le munition actuel, la position actuelle, ce qu'on veut contrôler.

Pour qu'une variable "machin" soit mise à jour tout le temps, et une variable "machin old" non, il faut utiliser une boucle !
Au début de l'événement, on met à jour la variable "machin old" puis après on place une boucle pour que cette dernière action ne se répète pas, donc que la variable "machin old" ne soit plus à jour.
A l'intérieur de la boucle par contre, si c'est le changement d'une position X, d'une ID de carte, la véritable monnaie du jeu, une valeur de ce genre bref si on ne contrôle pas directement si le contenu de la variable change mais si c'est ce qu'on va mettre dedans change, on va mettre à jour la variable "machin" à l'intérieur de boucle pour prendre en boucle la valeur qu'on veut détecter le changement.
Si c'est pas une valeur de ce genre mais directement le nombre qu'il y a à l'intérieur de la variable "machin" (PV, munition, etc...) dont on veut contrôler le changement qui sera effectué dans le jeu (quand on ramasse un point de vie, des munitions, quand on en perd), c'est évident qu'on ne va la mettre à jour dans la boucle.
Enfin, vous comprendrez ! ^^
Bref, dans cette boucle il y aura surtout une condition "si machin différent de machin old" car si c'est le cas, ça veut dire que la valeur de la variable vient de changer donc on effectue l'action qu'on veut : ré-afficher la jauge, recalculer si on dépasse pas les PV max, jouer le bruit de pas, compter le nombre de pas, ce qu'on veut qu'il se passe dès que la valeur contrôlée change !

Pas pigé ? Mais si ! Je tourne un peu en rond dans ce que je dis alors que c'est tout con, voilà la formule générale, vous comprendrez :


La recette :




Si on veut que quelque chose se produise à chaque fois que la valeur de "machin" change, on fait, par exemple dans dans un événement commun "CHGMT" (abrégé de "changement") en processus parallèle :

modifier variable "Machin old" rendre égal à la valeur qu'on veut contrôler
boucle :

modifier variable : "machin" rendre égal à la valeur qu'on veut contrôler (note : cette ligne n'est pas obligée si la valeur à contrôler est directement la valeur de "machin")
condition : si "machin" différent de "machin old"
<>il se produit quelque chose à chaque fois que la valeur de "machin" change !
<>modifier variable "machin old" rendre égal à valeur qu'on veut contrôler

attendre 0.1sec (ou 0.0sec (1 frame), ça dépend la précision !)
fin de la boucle


Et voilà, c'est exactement ce que je disais plus haut, donc je me passe de commentaire, regardez juste la progression du code, on ne sort jamais de cette boucle !

ATTENTION ! Contrairement à un processus parallèle qui tourne en boucle, une boucle fait un sacré millier de tours par seconde ! Autrement dit, un code qui se répète 10000 fois constamment toute les seconde, ça flingue le jeu totalement ! ^^ Pour éviter le massacre, vous ne devez surtout pas oublier de mettre un "attendre" à l'intérieur de vos boucles !! ^^ (Quand je dos "vos" boucles, je parle des autres que vous ferez, pour ce tutoriel vous n'en aurez besoin qu'une seule)


Si on veut contrôler plusieurs valeurs différentes :


Si vous faites un A-RPG ou autre, vous avez besoin de contrôler le changement de plein de choses (voir les exemples que j'ai cité, et plus encore) mais avez-vous besoin de faire plusieurs événements commun ?

Non, vous pouvez vous servir d'un seul événement commun !

modifier variable "1er machin old" rendre égal à la première valeur qu'on veut contrôler
modifier variable "2eme machin old" rendre égal à la seconde valeur qu'on veut contrôler
etc...
boucle :

modifier variable : "1er machin" rendre égal à la première valeur qu'on veut contrôler
condition : si "1er machin" différent de "1er machin old"
<>il se produit quelque chose à chaque fois que la valeur de "1er machin" change !
<>modifier variable "1er machin old" rendre égal à la première valeur qu'on veut contrôler

modifier variable : "2eme machin" rendre égal à la seconde valeur qu'on veut contrôler
condition : si "2eme machin" différent de "2eme machin old"
<>il se produit quelque chose à chaque fois que la valeur de "2eme machin" change !
<>modifier variable "2eme machin old" rendre égal à la seconde valeur qu'on veut contrôler

etc...
attendre 0.1sec (ou 0.0sec (1 frame), ça dépend la précision !)
fin de la boucle


J'ai juste ajouté en bleu la même chose que ce qui était en rose, histoire que vous voyez l'ordre des choses, vous pouvez donc en regrouper plusieurs de cette manière !


Attention, précision !


Si vous avez besoin d'une détection précise toute les 0.0sec, il ne faut pas qu'une de ces détections exécute une action qui fasse un long "attendre", ce qui casserait la précision des autres détections !

Oulà, je me met à parler chintok !

Une détection : Je veux dire détecter le changement d'une valeur (exemple : détecter le changement de position)

Exécute une action : C'est ce qu'il se passe à chaque fois que la valeur change (quand la condition est remplie) (exemple : un bruit de pas à chaque changement de position)

Détection précise :
Pourquoi je parle de détection précise ?
C'est par expérience et chipotage : Dans mon jeu j'ai un personnage qui suit le héros, à chaque fois que le héros change de position, j'assigne une nouvelle nouvelle destination pour le second personnage (la destination c'est le dernier pas du héros, qui est donc mémorisé grâce à la technique de ce tutoriel) donc pour que le personnage suive continuellement le héros, sans s'arrêter, il faut que cet événement commun tourne en boucle toute les 0.0sec sans s'arrêter, c'est ce que j'appelle une détection précise ! (que la condition soit toute les 0.0sec (1 frame) et pas autre chose)
Donc avant, j'avais toute les détections dans un seul événement commun (changements de munition, de PV, etc...) et c'est surtout l'animation d'affichage de PV quand on en perd ou en récupère, comme c'est une animation posée de 0.2sec, ça faisait que le personnage qui suit le héros s'arrêtait pendant 0.2sec à chaque fois qu'on perdait ou gagnait un point de vie ! Ça m'énervait avant que je trouve enfin d'où venait le problème ! ^^

Bref, dans ce genre de cas, il faut mettre à part les détections précises (les mettre dans un événement commun différent) en sorte qu'aucune exécution d'action ne stoppe leur précision !

Par exemple, j'ai deux événements communs : "CHGMT coor", qui détecte les changements de coordonnée et d'ID de map, et "CHGMT item" qui détecte les changements des variables "PV", "Munition1", "Munition2", "Arme équipée", "Argent"... c'est toute les choses qui sont affichées en image dans les coins de l'écran dans le jeu, a chaque fois qu'une de ces variables change, il y a leur animation propre à l'ajout ou au retrait, avec l'effet sonore, et la condition qui fait qu'on n'ira pas en dessous de la valeur "0" et pas au dessus de la valeur "PV max", "Munition1 max", etc ! Et quand je programme par exemple un point de vie sur la carte, à l'intérieur de l'événement il n'y a strictement rien d'autre qu'un "modifier variable "PV" additionner 1","effacer cet événement" ! L'affichage du PV, l'animation sur le héros se fait automatiquement !
Et mieux encore, quand je fais un événement qui ajoute ou retire une grande valeur à la variable "argent", l'argent affiché défile automatiquement en décompte chiffre par chiffre jusqu'à la nouvelle valeur comme les rubis de Zelda, automatiquement grâce à cet événement "CHGMT item", j'ai fais pareil pour le premier type de munition ! ^^ Je vous expliquerait ça à la fin !

Vous êtes sensés avoir compris la méthode, la voici appliquée dans l'exemple d'un système de bruit de pas et comptage de nombre de pas !


Exemple 1 : Détecter les déplacements du héros !




Vous voulez détecter quand est-ce que le héros change de position ? (bruits de pas, comptage de pas, autre chose)

Par exemple, la variable "nombre de pas" augmente de 1 à chaque pas ! Ça vous permet de faire un combat personnalisé tous les "x" pas, ou d'autres trucs, donc dans le jeu à chaque fois qu'on veut mesurer le nombre de pas, on fait "modifier variable "nombre de pas"=0" et on saura combien de pas fait le héros à partir de ce moment ! ^^ (Ça a plein d'utilité ! Genre "condition : si "nombre de pas" >ou= à "1" : le héros a bougé ! Donc pratique pour effectuer une action dès que le héros se déplace après que vous ayez mis la variable "nombre de pas" à zéro. (si ça peut donner des idées ! ^^))

Il suffit de faire dans notre événement commun "CHGMT" en processus parallèle :

modifier variable "X old" rendre égal à "coordonnée X héros"
modifier variable "Y old" rendre égal à "coordonnée Y héros"
boucle :

modifier variable "X now" rendre égal à "coordonnée X héros"
condition : si "X now" différent de "X old"
<>jouer effet sonore : "bruit de pas"
<>modifier variable "nombre de pas" additionner "1"
<>modifier variable "X old" rendre égal à "coordonnée X héros"

modifier variable "Y now" rendre égal à "coordonnée Y héros"
condition : si "Y now" différent de "Y old"
<>jouer effet sonore : "bruit de pas"
<>modifier variable "nombre de pas" additionner "1"
<>modifier variable "Y old" rendre égal à "coordonnée Y héros"

attendre 0.1 sec
fin de la boucle


Et voilà, si vous ne comprenez pas, c'est que vous avez eu la flemme de lire ce que j'ai expliqué plus haut !


Exemple 2 : Détecter le changement de PV




Vous voulez que les points de vie soient affichés à l'écran ?
En jauge, en chiffre, ou en quarts de vie ? Donc une variable "PV" ?

Mais comment voulez vous l'afficher ?

Vous appelez un événement commun qui ré-affiche la jauge après chaque fois que vous modifiez la variable "PV" dans le jeu ?
Pire, vous copiez/collez le code d'affichage à chaque fois que vous modifiez la variable ?
Pire que tout, vous affichez la jauge en boucle comme ça elle est toujours à jour ??

Ça ne serait pas mieux de l'afficher automatiquement sans rien avoir à faire ?

Qu'à chaque fois que vous mettez un "modifier variable "PV" additionner/soustraire x" dans un événement, quand on joue au jeu il y ait un événement commun tout simple qui ré-affiche la jauge automatiquement pile à ce moment et à aucun autre moment ? Que cet événement commun l'affiche aussi automatiquement à chaque changements de map et à aucun autre moment ? Qui vous permette de faire automatiquement une animation quand vous perdez/gagnez un PV ?


Bref, c'est là qu'on utilise notre événement commun "CHGMT" qui va détecter si la variable "PV" change !


Alors qu'est ce qu'on veut qu'il se passe à chaque fois que les PV du héros changent ?

** on joue un effet sonore "blup !"

** on appelle un événement commun en mode "appel" "affichage PV" qui ré-affiche les PV (Donc, affichage des chiffres si c'est un affichage au nombre, jauge qui se déplace si c'est une jauge, etc... je ne vais pas dire le contenu de cet autre événement, vous devrez vous référer à un autre tutoriel ou à vos méninges !!)

** on fait une condition voir si les PV dépassent les PVmax (donc prévoir une variable "PVmax") > si c'est le cas, on rend les PV égal aux PVmax !

** on fait une condition voir si les PV viennent à zéro > si c'est le cas, c'est le game-over !


Ouah ! il se passera tout ça automatiquement grâce à un événement commun rien que si mon monstre frappe je met un simple "modifier variable : "PV" soustraire "1"" ?? Que si on ramasse un PV il n'y ait qu'un simple "modifier variable : "PV" additionner "1"" dedans ?


Eh oui, c'est bien pratique ! ^^ Et voilà ce que donne le code avec la même recette que l'exemple précédent !


Dans votre événement commun nommé "CHGMT" :

modifier variable "PV old" rendre égal à valeur de la variable "PV"
boucle :

condition : si "PV" différent de "PV old"
<>jouer effet sonore : "blup !"
<>appeler événement commun : "affichage PV"
<>condition : si variable "PV" supérieur à variable "PV max"
---<>modifier variable "PV" rendre égal à valeur de la variable "PV max"
<>condition : si variable "PV" inférieur ou égal à "0"
---<>Game Over !
<>modifier variable "PV old" rendre égal à valeur de la variable "PV"

attendre 0.1sec
fin de la boucle


Donc voilà encore une fois, c'est exactement la même recette donc je me passe de commentaire !
C'est génial, les PV s'affichent à chaque fois que la variable change, et on s'occupe en même temps de la limite PVmax et du game over ^^

Mais les PV doivent s'afficher aussi à chaque fois qu'on change de map, non ?

Détecter le changement de map, on peut pas détecter ça par variable ?

Ben si ! Pourquoi ne pas avoir les variables "ID map" et "ID map old" ?

On peut faire "modifier variable "ID map" rendre égal à "événement : ID de la carte du héros" !

Et faut-il faire un nouvel événement commun ? Ben non, on a dit qu'il était mieux de tous les mettre dans le même événement commun, notre bon vieux événement "CHGMT" :
Et zouu, toujours la même recette, on va compléter le code :

(Pour RPGmaker2003 !)
modifier variable "PV old" rendre égal à valeur de la variable "PV"
modifier variable "ID map old" rendre égal à événement : ID de la carte du héros
boucle :

condition : si "PV" différent de "PV old"
<>jouer effet sonore : "blup !"
<>appeler événement commun : "affichage PV"
<>condition : si variable "PV" supérieur à variable "PV max"
---<>modifier variable "PV" rendre égal à valeur de la variable "PV max"
<>condition : si variable "PV" inférieur ou égal à "0"
---<>Game Over !
<>modifier variable "PV old" rendre égal à valeur de la variable "PV"

modifier variable "ID map" rendre égal à événement : ID de la carte du héros
condition : si "ID map" différent de "ID map old"
<>appeler événement commun : "affichage PV"
<>Ainsi que les autres choses que vous voulez effectuer à chaque changement de map ! (exemple, les autres affichages)
<>modifier variable "ID map old" rendre égal à valeur de la variable "ID map"

attendre 0.0 sec
fin de la boucle


Voilà c'est exactement le même principe, sauf qu'à la différence des PV, on doit modifier la variable "ID map" tout le temps pour toujours lui donner l'ID actuelle de la carte !

Mais c'est seulement ainsi pour RPGmaker2003 !
Pour RPGmaker XP et VX, il ne faut pas faire comme ça pour détecter le changement de map !!
Les événements communs ne fonctionnent pas comme le 2000 et 2003, pour XP et VX, les événements communs recommencent depuis le début à chaque changements de map !

Donc, voici ce vous devez faire à la place :

(Pour RPGmakerXP ou VX !)
modifier variable "PV old" rendre égal à valeur de la variable "PV"
appeler événement commun : "affichage PV"
Ainsi que les autres choses que vous voulez effectuer à chaque changement de map ! (exemple, les autres affichages)

boucle :

condition : si "PV" différent de "PV old"
<>jouer effet sonore : "blup !"
<>appeler événement commun : "affichage PV"
<>condition : si variable "PV" supérieur à variable "PV max"
---<>modifier variable "PV" rendre égal à valeur de la variable "PV max"
<>condition : si variable "PV" inférieur ou égal à "0"
---<>Game Over !
<>modifier variable "PV old" rendre égal à valeur de la variable "PV"

attendre 3 frames
fin de la boucle



Pour la version RPGmaker2003, j'ai mis "attendre 0.0sec" plutôt que "attendre 0.1sec" car la détection du changement de map doit être précise si on veut que les PV soient affichés même pendant la transition entre les deux maps ! ^^


Vous avez compris le truc ? Génial !
Alors comme ça les PV s'affichent vraiment QUE si on change de map, QUE si la variable des PV changent !
Et quand vous programmez votre jeu et que vous voulez modifier les PV du héros ? Vous n'avez rien d'autre qu'un simple "modifier variable" à faire pour que votre jauge se mette à jour en s'animant, etc !
C'est la facilité totale pour la suite de votre jeu et pour rechanger les actions comme on veut ! ^^ Et ça ne ralentit pas le jeu, bien sûr ! ^^



Ce dernier code, en bleu, pour détecter les changements de carte, c'est super utile !
Par exemple si vous avez des interrupteurs à désactiver ou des variables à remettre à zéro à chaque fois que vous changez de map (j'en ai une tonne pour mon système A-RPG !)

Mais surtout, c'est aussi utile pour créer des interrupteurs et des variables temporaire !
Hein ?? Quoi ??
C'est simplement une énorme économie d'interrupteur et variable bien pratique !
Un mini-jeu, par exemple, ou d'autres choses, on utilise plein d'interrupteurs et variables mais après, on n'en a plus jamais besoin de ces interrupteurs et variables il n'y a plus de conditions portées sur leur valeur sur d'autres maps !

Alors si ces valeurs ne sont pas importante, et qu'elle peuvent ou doivent être remise à zéro quand on sort de la carte, on peut les réutiliser pour un autre mini-jeu, ou une autre énigme, ou autre chose !

Alors pourquoi ne pas les distinguer des autres interrupteurs et variables ?

Des interrupteurs et variables qui se remettent à OFF et 0 à chaque fois qu'on sort de la carte !
Par exemple créer les variables "(A)>..., (B)>..., (C)>..., (D)>... etc jusqu'à (Z)>..." et les interrupteurs "[1]>..., [2]>..., [3]>..., [4]>...,etc jusqu'à [20]>..."
"..." serait un nom provisoire propre à chaque carte qui les utilise (exemple : le premier interrupteur temporaire s'appellerait "[1]>Début course" sur une map et "[1]>Premier levier" sur une autre map, donc le mieux serait de noter en commentaire sur chaque map le nom que vous donnez à vos variables et interrupteurs, pour vous y retrouver !!
Et pour que toute ces variables et interrupteurs soient effectivement "temporaires", il suffit simplement d'ajouter dans la zone bleue de ce dernier exemple (détection de changement de map) : "modifier variable [0001 à 0020] rendre égal à 0", "désactiver interrupteurs [0201 à 0220]" (j'ai dis des ID au pif, vous savez comment ça marche, c'est le premier et le dernier ID du bloc de variable/interrupteur) ! Ainsi, on est sûr que lorsqu'on fait une nouvelle carte, on peut utiliser à nouveau ces variables et interrupteurs en étant sûr qu'ils soient remis à zéro !

Et voilà, vous savez comment donner à votre jeu un nouveau type d'interrupteur et variables : les interrupteurs temporaires [1]>... à [20]>... et les variables temporaires (A)>... à (Z)>... Que vous pourrez utiliser librement pour toute les valeurs qui ne concernent que la carte en question et peuvent ou doivent être remises à zéro pour la prochaine carte, et quand vous les utilisez vous leur donner le nom que vous voulez à la place des "...", vous notez bien en commentaire ces appellations par exemple dans un événement qui aurait un charset spécial bien visible sur la carte et un interrupteur "bilou" en déclencheur, interrupteur qui ne sera jamais sur ON, en sorte que cet événement spécial n'apparaisse jamais dans le jeu ! (donc que l'événement ne serve vraiment qu'à inscrire à l'intérieur la liste des interrupteurs/variables temporaires utilisées avec leur nom) Et lorsque vous les réutiliserez sur une nouvelle map, vous leur donnerez un nouveau nom à la place de l'ancien que vous inscrirez dans un même événement. Question d'organisation, vous serez récompensé d'une économie énoooorme !


Bref, vous pouvez y ajouter ce que vous voulez à cet événement commun "CHGMT" ^^
Y rajouter l'exemple1, une nouvelle jauge, autre chose, vous connaissez la recette !



Exemple 3 : Décompte progressif jusqu'à la bonne valeur à chaque fois que la valeur change !




Exemple : les rubis qui se décomptent, dans Zelda !

Dans Zelda, les rubis sont affichés en chiffres, quand on perd ou gagne un grand nombre de rubis, on les voit et entend défiler en décompte chiffre par chiffre jusqu'à la nouvelle valeur ! C'est bien mieux que de les voir s'afficher d'un coup d'un seul à la nouvelle valeur ! ^^

Ben ça, vous pouvez le programmer très simplement ! En modifiant légèrement le code !

Alors on considère qu'on est trop fort et on a créé un événement commun en mode appel "Rubis affichage" qui affiche le nombre de rubis dans un coin de l'écran à partir de la variable "Rubis" !
Vous saurez programmer un tel événement avec un autre tutoriel ou en réfléchissant !

modifier variable "Rubis old" rendre égal à valeur de la variable "Rubis"
boucle :

condition : si "Rubis" supérieur à "Rubis old"
<>condition : si variable "Rubis" supérieur à variable "Rubis max"
---<>modifier variable "Rubis" rendre égal à valeur de la variable "Rubis max"
--sinon :
---<>appeler événement commun : "Rubis affichage"
---<>jouer effet sonore "rubis en plus"
---<>modifier variable "Munition old" additionner "1"
---<>attendre 0.0sec
---<>attendre 0.0sec
condition : si "Rubis" inférieur à "Rubis old"
<>condition : si variable "Rubis" inférieur à "0"
---<>modifier variable "Rubis" rendre égal à "0"
--sinon :
---<>appeler événement commun : "Rubis affichage"
---<>jouer effet sonore "rubis en moins"
---<>modifier variable "Rubis old" soustraire "1"
---<>attendre 0.0sec
---<>attendre 0.0sec

attendre 0.0 sec
fin de la boucle


Qu'est ce qui change ? A part qu'on a programmé en sorte qu'il se passe quelque chose de différent si la variable diminue que si elle augmente ?
Au lieu du "modifier "machin old" rendre égal à "machin" de notre recette, on fait "modifier "machin old" additionner/soustraire "1"" et c'est là toute la différence, c'est grâce à ça que la monnaie va défiler toute seule en décompte chiffre par chiffre ! ^^
Pour ce code, elle va défiler rapidement (pour XP ou VX, je ne sais pas quel genre d'attendre vous pouvez mettre, jaugez pour que ce ne soit pas trop lent !) pour RPGmaker2003, deux attendre "0.0sec" plus le dernier "0.0sec" à la fin ça fait une pose idéale qui représente environ la moitié de 0.1sec pour le défilement des chiffres et du bruit assigné ! ^^

Vous pouvez faire pareil en moins rapide pour vos points de vie si c'est des quarts de cœurs qui s'ajoutent ou se retirent un par un comme dans Zelda ! ^^ Ou pour vos munitions si elles sont affichées en chiffres !

ATTENTION, l'argent doit aussi être affichée à chaque fois que vous changez de map, mais maintenant vous savez quelle est la démarche à suivre !
Sur RPGmaker2003 vous faites "appeler événement commun "Machin affichage"" dans le même condition que celle que vous avez voyez en bleu dans l'exemple des points de vie ! ^^
Si vous êtes sur RPGmakerXP ou VX, rappelez vous ce que j'ai dis, vous n'avez qu'à faire cette action avant la boucle, vu que l'événement commun recommence dès son début à chaque changements de carte !

Pas compris ? Ca m'étonnerait, la recette devrait commencer à être claire, elle est si bête que j'ai hésité à en faire un tutoriel ! ^^

A vous le potentiel créatif ! ^^
Vous pouvez personnaliser d'avantage la technique par exemple, comme on différencie quand-est-ce que la variable diminue et quand-est-ce qu'elle augmente, vous pouvez faire trois événements fréquents au lieu d'un seul "affichage munition" pour chaque changement de carte, "affichage munition en +" avec une animation propre à l'ajout de munition, pv ou autre, "affichage munition en -" avec une autre animation propre au retrait de munition, pv ou autre !




Vous savez maintenant programmer un événement commun qui détecte tout !
Tout est automatique et quand un monstre vous touche ou autre chose, vous n'avez plus à vous embêter, faites "modifier "PV héros" soustraire 1" et l'événement commun fait automatiquement le reste !


Bilou !



Bastienre4 - posté le 25/06/2008 à 23:04:19. (21 messages postés)

Petit Maker ^^

mouai je sui pa sur davoir tt saisi mais c assez chouete:)

J'apprends le C++ (c'est pas gagner :F)


Joke - posté le 02/07/2008 à 00:47:26. (5029 messages postés)

Si tu comprends c'est vraiment pratique ce truc.

Aujourd'hui j'en ai encore eu utilité : J'ai programmé en sorte qu'il y ait un combat à chaque fois qu'on fait 40 pas, ben j'ai fais comme ce tutoriel : j'ai programmé en sorte que l'événement fréquent détecte à chaque fois que la position X et Y du héros change, ça ajoute 1 à la variable "nombre de pas" et voilà comment on compte facilement le nombre de pas.

C'est utile pour plusieurs choses.

http://rmex.github.io/ | Joke's Tuts | Joke's Gribs | SoundCloud | Terre cuite | BilouCorp | Genesis | Groupe Skype RPG Maker | DELIRIUM-II


virateck - posté le 14/07/2008 à 10:22:22. (47 messages postés)

yoooooooouuuuuuuuuuuuppppppppppppiiiiiiiiiiii !!!!!!! jcomprend les variables!!!!:biere:joint

fana de metroid jusqu'au bout!!!


Joke - posté le 22/11/2008 à 01:56:45. (5029 messages postés)

Tutoriel mis à jour, pour plus de clarté et infos ! :noel

http://rmex.github.io/ | Joke's Tuts | Joke's Gribs | SoundCloud | Terre cuite | BilouCorp | Genesis | Groupe Skype RPG Maker | DELIRIUM-II


Stuart - posté le 23/11/2008 à 02:51:22. (1872 messages postés)

Citation:

ATTENTION ! Contrairement à un processus parallèle qui tourne en boucle, une boucle fait un sacré millier de tours par seconde !


Oh putain ça va grandement m'aider de savoir ça, merci. :)

Tu connais à peu près le nombre de processus parallèles qui équivaut à une boucle ?


Monos - posté le 23/11/2008 à 10:41:12. (56278 messages postés) - admin

Vive le making libre

Je viens de faire un test.
J'ai ajoutée une variable +1 dans un processus //
et une variable + 1 dans une boucle


Réalisé sur Rpg Maker 2003 version 1.09b
Test 1
Temps:11 seconde
Boucle: 2253333
//:675

Test 2
Mon 2em test sur 1 1seconde: Cela n'a pas du tous changé.

Ce qui fait environ 204848/seconde en Boucle
Environ 61/seconde en //

Donc la boucle est 3358 plus rapide qu'un événement en //
Sur programmation identique.

(Sondage insé. Tous droit non réservé)

Pixner|Offgame | Le comptoire des clikeurs


Stuart - posté le 23/11/2008 à 11:35:40. (1872 messages postés)

Trop bien !! Merci Monos.


Joke - posté le 23/11/2008 à 11:57:39. (5029 messages postés)

Eh oui c'est utile si on veut effectuer une centaine de calculs en une fraction de seconde !! :) Et ça ne ralentit pas le jeu si cette centaine de calcul n'est pas sensé durer plus d'une fraction de seconde grâce à la condition qui fait "sortir de la boucle", autrement c'est du fusillage de jeu comme je dis si une boucle sans "attendre" dure longtemps ! ^^

Merci Monos d'avoir donné des valeurs à cette affirmations ! =)

http://rmex.github.io/ | Joke's Tuts | Joke's Gribs | SoundCloud | Terre cuite | BilouCorp | Genesis | Groupe Skype RPG Maker | DELIRIUM-II


Monos - posté le 23/11/2008 à 12:20:38. (56278 messages postés) - admin

Vive le making libre

De rien.

Je voulais faire la même manipe avec VX pour comparé et

une événement en // plus un boucle et directement +1 dans une variable, ça me freeze le jeu et me le bloque.

La franchement ^^

=====Edit======

Teste sur Vx j'ai réussis.

Alors
Test 1
//: 636
Boucle: 635
Temps: 10

Test 2
//: 612
Boucle: 611
Temps: 10


Ba heu sur Vx la boucle et les événement // c'est égaux.


Re edit, j'ai refais un autre teste les boucles sont 2* plus rapide que //.

^^

Pixner|Offgame | Le comptoire des clikeurs


Joke - posté le 23/11/2008 à 12:57:05. (5029 messages postés)

Moi j'ai fais des test sur RPGmaker2003

Pour un simple code :
condition si "chrono" est à 0
<>message : \V[81]
fin de condition
modifier variable "81" +1

rien d'autre dans le jeu, et un événement qui lance le chrono et active le code en question sans rien faire d'autre, j'arrive à des mesures bien rondes :

Dans un événement commun :
Processus seul : 60 tours/sec
Boucle : 120 000/sec
Étiquette : 150 000/sec

Dans un événement de la carte :
Processus seul : 60 tours/sec
Boucle : 120 100/sec
Étiquette : 150 125/sec

Et plus le code tournant en boucle est grand, moins il y a de tours effectué.
Mais le résultat démontre qu'une boucle d'étiquette est quand même plus rapide ^^ Et plus rapide en événement simple qu'événement commun.


J'ai fais les mesure sur le chrono lancé à 20 secondes.

Un mode automatique fait autant de tours qu'un processus parallèle, mais le processus parallèle démarre même avant la transition entre les cartes contrairement à l'automatique qui ne démarre qu'à la fin de la transition d'affichage de la carte, chose à savoir si vous voulez modifier les tons de l'écran, afficher une image avant que la map n'apparaisse !

http://rmex.github.io/ | Joke's Tuts | Joke's Gribs | SoundCloud | Terre cuite | BilouCorp | Genesis | Groupe Skype RPG Maker | DELIRIUM-II


Stuart - posté le 25/11/2008 à 13:06:29. (1872 messages postés)

Bon bah en fait ça m'aide pas beaucoup. ^^' J'ai un calcul über long qui doit tourner constamment donc obligé de mettre un 0.0 pour éviter le gros lag, du coup ça revient au même qu'un proc //
Bon c'est tout de même bien de connaitre la différence, je m'en servirai sûrement pour autre chose, thanks !


renardeau - posté le 09/02/2012 à 12:40:10. (95 messages postés)

Résurrection...

Est-ce qu'il ya moyen de détecter la position d'un event ???

Résurrection...


Dragown - posté le 09/02/2012 à 12:45:27. (56278 messages postés) - admin

Vive le making libre

Ba oui. Dans la gestion des variables tu peux faire ça et mémoriser la position X et Y (en carreau) de l’évènement. Ensuite couplé avec une condition... Tu fais ce que tu veux.

Pixner|Offgame | Le comptoire des clikeurs


Klmett - posté le 12/05/2012 à 01:05:41. (32 messages postés)

Citation:

Vous appelez un événement commun qui ré-affiche la jauge après chaque fois que vous modifiez la variable "PV" dans le jeu ?



C'est exactement ce que je faisais je savais bien qu'il y avait un autre moyen mais j'avais pas trouvé, merci beaucoup j'apprend énormément :)

Sinon, juste un petit truc, y a pas un soucis avec ce code ?

Portion de code : Tout sélectionner

1
2
3
4
5
6
7
8
9
10
11
12
modifier variable "PV old" rendre égal à valeur de la variable "PV" 
boucle : 
condition : si "PV" différent de "PV old" 
<>jouer effet sonore : "blup !" 
<>appeler événement commun : "affichage PV" 
<>condition : si variable "PV" supérieur à variable "PV max" 
---<>modifier variable "PV" rendre égal à valeur de la variable "PV max" 
<>condition : si variable "PV" inférieur ou égal à "0" 
---<>Game Over ! 
<>modifier variable "PV old" rendre égal à valeur de la variable "PV" 
attendre 0.1sec 
fin de la boucle 



En gros si on à PV+1 sur la map, bon ça dépend ce qu'on met dans l'event appelé d'affichage, mais en général si on dépasse les PVs max, là ça va faire BLUP et la barre vas pas bouger. C'est pas très grave mais faudrait pas mettre la condition avant ? Parce que si on prend plein de vie et qu'on est full ça va faire BLUPBLUPBLUP non ? :sourit

Merci de ta rep et merci de ce tuto awesome :biere

Parce que j'aime le Making mais aussi la musique, voici quelques mixes et sons : http://djklmett.free.fr/ :)


Joke - posté le 01/06/2012 à 02:03:19. (5029 messages postés)

Désolé pour le temps de réponse, bien sûr on ne sait jamais quand-est ce qu'on reçoit un commentaire sur nos tutoriels sur Oniromancie ! :D

Là si on prend plein de vie et que ça dépasse PVmax, il fera une seule fois le "blup !" car il corrige la variable "PV" pour la rendre égale à PVmax et non la laisser supérieure. ^^

Alors effectivement, ça fera bien "blup !" si on reçois des PV alors qu'on est au maximum, mais un maker aguéri changera effectivement mon code pour mettre un "blup !" différent dans ces conditions, pour signaler le trop-plein ! ^^

http://rmex.github.io/ | Joke's Tuts | Joke's Gribs | SoundCloud | Terre cuite | BilouCorp | Genesis | Groupe Skype RPG Maker | DELIRIUM-II

Suite à de nombreux abus, le post en invités a été désactivé. Veuillez vous inscrire si vous souhaitez participer à la conversation.

Haut de page

Merci de ne pas reproduire le contenu de ce site sans autorisation.
Contacter l'équipe

Plan du site:

Activité: Accueil | News | Forum | Flash-news | Chat | Commentaires | Galerie | Screen de la semaine | Sorties | Articles perso | Livre d'or | Recherche
Jeux: Index jeux séparés | Top Classiques | Top Originaux | Les autres | RPG Maker 95 | RPG Maker 2000 | RPG Maker 2003 | RPG Maker XP | RPG Maker VX | RPG Maker VX Ace | RPG Maker MV | Autres | Jeux complets | Proposer
Rubriques: Le Wiki | Collection Oniro | Tutoriaux | Scripts | Guides | Gaming-Live | Tests | Making-of | Interviews | Articles perso | OST | L'Annuaire | Divers | Palmarès
Hébergés: Aëdemphia | Fighting Robots Quest | Forstale | Geex | Inexistence | La Légende d'Ibabou | Lije | LoveMaster | Sarcia | Super Mario RPG - Lost Souls
Ressources: Jeux | Programmes | Packs de ressources | Midis | Eléments séparés | Sprites
RPG Maker 2000/2003: Chipsets | Charsets | Panoramas | Backdrops | Facesets | Battle anims | Battle charsets | Monstres | Systems | Templates
RPG Maker XP: Tilesets | Autotiles | Characters | Battlers | Window skins | Icônes | Transitions | Fogs | Templates
RPG Maker VX: Tilesets | Charsets | Facesets | Systèmes
RPG Maker MV: Tilesets | Characters | Faces | Systèmes | Title | Battlebacks | Animations | SV/Ennemis