Nelfe -
posté le 07/02/2013 à 13:55:23 (3 messages postés)
❤ 0
Domaine concerné: Script Logiciel utilisé: VX Ace Bonjour à toutes !
Je viens de me lancer dans ce logiciel, voulant réaliser des petits jeux pour m'occuper après mon boulot (qui n'a rien, mais alors rien à voir avec les jeux-video ^^).
J'ai pu réaliser l'immense potentiel de l'éditeur de script, avec lequel je me suis amusé un peu, et donc j'aimerais partager avec vous mes réalisations pour aider ceux qui y comprennent pas grand chose .
Ce premier tutorial servira à personnaliser la partie : modifier le nom du personnage, activer les sauvegardes ou non.
Voilà ce que ça donne :
Décortiquons ce bazar :
Premier point : le déclenchement du script est automatique, donc sélectionnez en bas à gauche "Paralell process". Ne touchez à rien d'autre, sauf si vous voulez que ce soit un "PNJ" qui vous propose de personnaliser la partie.
Ensuite, le script lui-même :
- Conditional Branch: Variable [0001] <= 1
J'utilise en effet une variable (la numéro 001) pour éviter que le script tourne en boucle et que le menu se lance perpétuellement (ce qui bloquerait totalement le jeu). Pour que le script se lance, la variable doit avoir une valeur inférieure ou égale à 1 : ça tombe bien, en début de partie, la variable a une valeur automatique de 0. Le script peut se lancer et le menu apparaître !
Pour faire cela, dans l'Event Commands, choisir le "Conditional Branch". Choisir l'option Variable, sélectionner la variable 001, mettre la condition à "Less than or equal to", puis choisir "Constant" et entrer 1 juste à côté .
- Text: -, -, Normal, Bottom "Personnaliser le nom"
Je demande donc à afficher une boîte contenant le texte "Personnaliser le nom", sans image à côté, un truc tout simple donc.
- De "Show Choices" au premier Branch End :
Première personnalisation de la partie : je propose au joueur de modifier le nom du personnage. La première réponse, "Oui", ouvre un menu permettant de modifier le nom du personnage, avec une limite de 15 caractères (Name Input Processing: Eric, 15 characters). La limite de caractère peut changer selon vos goûts.
Si le joueur sélectionne Non, il ne se passe rien et on passe à la suite.
Ici, je vais proposer au joueur un mode où il ne pourra pas sauvegarder dans le menu du jeu, mais uniquement via des objets disposés sur la map (principe de checkpoint) : le jeu paraîtra donc plus dur !
- De "Show Choices" au second Branch End :
Même principe que tout à l'heure pour le nom : si le joueur choisi "Oui", le jeu grisera l'option de Sauvegarde dans le menu du jeu et le joueur ne pourra pas sauvegarder librement. J'utilise pour cela le "Change Save Access", page 3 des Event Commands, que je met sur Disable.
Et pour finir, une fois les choix effectués, je passe la variable à 2 pour empêcher la répétition du script. Dans les Event Commands, choisir l'option Control Variables, choisir Single et sélectionner la variable 001, l'opération Set ("mettre") et la constante à 2.
- Else : "Exit event processing" : j'ai un doute sur son utilité, mais je pense que cela coupe le script et libère donc de la mémoire. C'est simple : puisque désormais la variable n'est plus inférieure ou égale à 1, le script choisi la seconde option : se couper !
Et voilà ce que ça donne en "vrai":
Ce n'est qu'une base : vous pouvez aussi rajouter un mode "ultra simple" donnant au joueur un équipement surpuissant dès le départ, et j'en passe
J'espère que cela vous aura servi !
Zeus81 -
posté le 07/02/2013 à 16:25:42 (11071 messages postés)
❤ 0
Citation:
"Exit event processing" : j'ai un doute sur son utilité
Ça termine l'événement, comme si tu mettais une étiquette tout en bas de la liste et que tu faisais sauter vers cette étiquette.
Plutôt que d'utiliser une variable un interrupteur aurait fait l'affaire et plutôt qu'un proc parallèle avec une condition vaut mieux un démarrage automatique + une deuxième page vide qui s'active avec l’interrupteur.
Sinon y'a pas vraiment de place pour ce genre de chose sur le forum, normalement tout ça va sur le site, t'as un bouton Proposer à gauche dessous la messagerie.
Nelfe -
posté le 07/02/2013 à 16:43:20 (3 messages postés)
❤ 0
Merci pour les idées d'amélioration, je vais regarder ça en détail
(et merci aussi pour l'indication, j'avais un léger doute en postant^^)
Joke -
posté le 07/02/2013 à 19:18:55 (5090 messages postés)
❤ 0
Bilouteux fou
Zeus81 a dit:
Citation:
"Exit event processing" : j'ai un doute sur son utilité
Ça termine l'événement, comme si tu mettais une étiquette tout en bas de la liste et que tu faisais sauter vers cette étiquette.
Ace est tout plein de surprise en évent, j'aime ça !
Mais du coup, l'utiliser était inutile dans ce cas je pense. C'est l'occasion de retirer le champ "Else"
Et si tu utilise un interrupteur au lieu d'une variable, tu peux directement le mettre dans les conditions d'enclenchement de la page actuelle, sans créer de deuxième page. Comme ça ça s'exécute uniquement quand l'interrupteur "X" est ON
Zeus81 -
posté le 07/02/2013 à 19:34:32 (11071 messages postés)
❤ 0
La commande y était déjà avant en fait, c'est juste que c'était mal traduit "Arrêter tous les événements".
Sinon les interrupteurs sont sur off par défaut, donc si t'en mets un dans la première page ça ne s'exécutera jamais vu que c'est censé être au début du jeu.
Joke -
posté le 07/02/2013 à 20:48:06 (5090 messages postés)
❤ 0
Bilouteux fou
Ah ok, j'avais effectivement oublié le "Arrêter tous les événements" ! xD A une époque je croyais que c'était pour arrêter tous les déplacements, j'ai dû me rendre compte un moment donné de ce que ça faisait mais j'ai pas dû m'en servir et oublier. ^^
Pour l'interrupteur, sa manière d'empêcher la répétition est si peu naturelle que j'ai cru qu'il (elle ?) voulait que ça s'enclenchait seulement quand la variable était égale à 1 (Et j'ai zappé le <=) Du coup c'était plus simple de faire "=0" et rendre ensuite après la variable égale à 1, et même de faire une deuxième page vide avec comme déclencheur "variable >= 1", ce qui suivrait du coup la logique du scénario en une seule variable, et réutiliser cette variable pour les autres étapes du jeu, plutôt que de s'empêtrer avec plusieurs interrupteurs.
En tout cas c'est pas beau de laisser un processus parallèle vide tourner en boucle quand on ne veut pas qu'il se répète.
Après je dis certainement une grosse bêtise mais réflexion faite on peut se demander si dans le mode d'interprétation événementiel de RPG maker c'est pas plus léger pour lui de faire tourner un processus parallèle qui n'exécute rien, plutôt qu'un événement en "appui touche" qui n'exécute rien, puisque RM doit vérifier que le héros est devant l'événement et que le joueur appuie sur la touche ?
Zeus81 -
posté le 07/02/2013 à 23:27:06 (11071 messages postés)
❤ 0
C'est quand t'appuies sur une touche que ça vérifie les positions (de tous les événements) et pas l'inverse donc en fait ça change rien.
Un proc // peut ne rien consommer si il est complètement vide mais c'est quand même moins bien et puis là même si ça fait plus rien c'est pas vide.