❤ 0 EMG 3 : Simuler des interrupteurs locaux
I Introduction
Le tutoriel suivant est surtout utile pour RPG maker 2003, les version suivantes ayant nativement des interrupteurs locaux. Il peut cependant convenir aux personnes souhaitant optimiser au maximum leur code en réduisant le nombre de pages.
Comme pour le système présenté dans le tuto #1https://www.rpg-maker.fr/index.php?page=tutos&id=544], je ne suis pas le premier découvreur de cette technique, mais n'ayant pas non plus trouvé de ressources sur le sujet j'ai jugé utile d'en parler ici.
II Concept
Un des soucis de rpg maker et en particulier de RM 2003, est le fait de ne disposer ni d'interrupteur locaux, ni de variables locales. ce qui fait que, lorsque vous devez créer des copies d'un event utilisant une variable qui lui est allouée, il vous faudra alors changer le code de chaque copie pour modifier les variables qui lui sont allouées et qu'il utilise. De fait, plus il y aura d'events sur votre map, plus il vous faudra faire de modification, ce qui n'est pas vraiment très agréable.
Un moyen simple pour éviter ce problème est d'utiliser des données relatives à l'event, ce qui permet d'avoir un résultat différent selon l'event qui exécute le code.
III Éléments relatifs
Voici les données propres à un event que l'on peut récupérer :
- Sa position en X
- Sa position en Y
- Sa position relative à l'écran en X
- Sa position relative à l'écran en Y
- Sa direction
- Son ID
À noter que pour l'id la technique est un peu retors, car on ne la récupère pas avec la commande Control Variables comme c'est le cas pour les autres mais avec la commande Get Event ID qui renvoie l'id d'un event d’après ses coordonnées. De fait pour récurer cette valeur il faut d'abord stocker les positions X et Y de l'event puis les utiliser dans la commande Get Event ID pour stocker l'ID dans une troisième variable. Donc comme ceci :
IV Conditions relatives
Comme il n'est pas très utile d'utiliser des valeurs relatives sans avoir de quoi les contrôler, voici donc les conditions qui jouent sur ce genre de données.
- Test de la valeur d'une variable.
- Test de la direction dans laquelle l'event regarde.
C'est peu, mais comme la plupart des commandes stockent une valeur d'une variable, le test de la valeur d'une variable peut presque se suffire à lui seul.
Mais bon, assez de théorie, faisons un petit exemple !
V Exemple de code
Voici un petit système, dans une map finement soignée :
Le principe est simple : La porte est fermée et il faut activer le levier pour l'ouvrir. Et plutôt que d'utiliser un interrupteur pour distinguer les deux états du levier et de la porte, on va jouer sur la direction dans laquelle l'event regarde.
Voici donc le code du levier :
Comme vous pouvez le voir, tout le code est basé sur une condition qui vérifie si l'event regarde vers le bas (quand il est desactivé) ou vers la gauche (quand il est activé) et agit en conséquence, c'est à dire qu'il modifie le côté dans lequel la porte et le levier regardent.
Et du coup, voici le code de l'event de porte :
Le principe est le même que pour l'event précédent : on regarde dans quelle condition l'event regarde et on agit en conséquence en affichant que la porte est fermée ou ouverte.
(Bon dans le cas de ouvert on aurait pu aussi téléporter l'équipe mais je pense que vous avez compris le principe)
VI Conclusion
Donc, pour conclure, vous avez pu voir comment réaliser du code qui ne s’exécute pas de la même manière selon où l'event regarde.
Je tiens cependant à préciser qu'il est plutôt préférable d'utiliser cette technique dans des maps qu'on ne revisite plus une fois qu'on l'a quittée. En effet lors du retourne sur la map les events seront remis à leur position d'origine. Dans mon exemple il faudrait alors réactiver le levier à chaque fois qu'on revient en arrière.
Heureusement il est possible de corriger ce souci, mais ce sera le sujet d'un autre tutoriel 
| 
Chat
