Tuto: RMXP/VX premières approches et astuces de programmation en event/ruby

Enfiiiiiiiiiiiiiiiiiiiiiiiiiin ! Tout d’abord, merci à Nus’ d’avoir créé ce topic que j’attendais tant… une semaine =>[]
Surtout avec une place d’honneur dans le coin des artistes !

Sérieusement, voici mon premier tuto qui concernera surtout la programmation en mixte, c’est-à-dire insérer du ruby en event. Allergiques au ruby ? Ne vous en faites pas, rien de compliqué ! Ce tuto vous permettra de réaliser des systèmes qui sont impossibles à créer avec RM, ou qui nécessite un travail fastidieux et inutile…
Au programme, changement de windowskin, simplement et rapidement sans besoin de scripts, apprentissage de l’utilisation de variables autres que celles proposées par RM, enregistrements de données non accessibles par les commandes RM etc…

La seule chose requise est la compétence d’utilisation de variables RM, ainsi qu’une connaissance des autres commandes RM… Je me charge du reste !

Une variable est en quelque sorte une boîte possédant un nom et contenant une valeur.
Il faut savoir qu’à la base, le ruby est un langage de programmation surtout orienté table, c’est-à-dire faire des tableaux contenant plusieurs informations. On peut le voir dans RM, avec la base de donnée, qui est enfaite une immense table regroupant pleins de valeurs, comme le nom des héros, leurs sorts etc… Ces informations étant enregistrées par des variables. Vous me direz alors, y a du texte pour les noms des héros, etc… Et bien oui, les variables RM sont limitées à une valeur entière relative, c’est-à-dire pas de virgules, mais pouvant être négatives… C’est de là que mon tuto prend son utilité !

Tout d’abord, il existe plusieurs types de valeurs pour une variable, bien que dans RM, en event, on ne puisse utiliser qu’un type entier, ce qui est bien dommage et qui limite des choses !
- Type entier, ou integer en anglais, expliqué plus haut
- Type string, ou chaîne de caractère, permet d’enregistrer du texte dans une variable. Les types string sont enregistrés entre guillemets.
- Type real, ou réel, permet d’enregistrer des nombres à virgule, et des objets mathématiques, comme π …etc
- Type array, ou tableau, permet d’enregistrer plusieurs valeurs dans une seule variable
- Type Boolean, ou booléen, synonyme de variable logique : ces variables ne peuvent avoir que deux valeurs : true ou false (vrai ou faux). Dans RM, cela correspond aux interrupteurs, qui ont donc pour valeurs initiales false, puisqu’ils sont tous désactivés dès le lancement de RM.

_______________________________________

Ca suffira pour les types. Cependant, comme je l’ai dit, une variable possède un nom, ET une valeur. Que se passe-t’il lorsque la variable n’est pas encore initialisée, c’est-à-dire qu’elle n’a aucun type attribué ?
Et bien une variable a toujours une valeur en ruby, et lorsque la variable est vide, elle possède la valeur nil, qui indique qu’il n’y a rien dans la variable !
Pourquoi ce cour sur les variables ? Tout simplement car il vaut mieux que j’indique les différentes possibilités du ruby, et de montrer ce que RM propose en event pour vous inciter à aller un peu plus loin dans le tuto !

Comme je l’ai dit au début, pleins de choses sont « bridées » en event à cause de RM et des pauvres paramètres qu’il permet. Cependant, il existe une commande appeler un script et disponible depuis un événement. Non, cela ne sert pas uniquement à appeler des scripts de bestiaire ou autre…
Cela vous permet aussi de gagner du temps, faire des systèmes pas vraiment possible avec les options proposées par RM…etc

Tout d’abord, sachez que lorsque vous utilisez une commande RM, cela est traduit directement en ruby par le logiciel, donc vous faite du ruby, mais par une interface, comme on fait de la programmation sous windows, alors que l’on ne fait que cliquer sur quelques boutons etc…

Les scripts responsables des options et commandes RM sont les scripts Interpreter, disponibles directement dans l’utilitaire des scripts de RM (touche F11) ! Si vous vous y connaissez un peu en ruby et que vous cherchez une commande en ruby, il suffit d’analyser dans un des 7 scripts jusqu’à trouver la portion de ruby correspondant à la commande, c’est toujours utile !
(A noter que vous pouvez utiliser l'option de recherche grâce à ctrl+f, qui est très utile lorsque l'on programme)
On va donc utiliser certaines commandes RM, mais y mettre les paramètres que l’on veut et qui ne sont pas proposées par le logiciel, afin de réaliser nos systèmes voulus.

Tout d’abord, on va s’intéresser de nouveau aux variables de RM (Et oui, comme je l'ai déjà dit, la programmation se fait essentiellement grâce aux variables!).

En script, les variables de RM sont enregistrées de la forme :
$game_variables[X] = valeur où X est l’ID de la variable, et valeur la valeur voulue.

Exemple:
Par exemple, on veut faire un système de caisse que le joueur doit déplacer sur un interrupteur. Si la caisse est sur l’interrupteur, alors on active l’interrupteur 1. Sinon, on désactive l’interrupteur.
On va dire dans cet exemple que l’interrupteur est en position 10 en x et 7 en y.
Je ne vois qu’un moyen apparant en event :

Code:


Variable 1 := position X de l’event caisse (on va dire que l’event caisse à pour ID 001)
Variable 2 := position Y de l’event caisse.
Condition : si la variable 1 = 10
>>> Condition : si la variable 2 = 7
        >>> activer l’interrupteur 1
        Sinon : désactiver l’interrupteur 1
 Sinon : désactiver l’interrupteur 1
Fin
Fin


Ca nous fait deux sinon, deux conditions, puisque la commande de condition RM ne propose de comparer qu’une valeur à une autre. Et bien maintenant, vous pourrez en comparer autant que vous voulez en même temps !
On peut entrer un script dans plusieurs commandes, dans RM, depuis la commande appeler un script, depuis déplacer/modifier un événement, et même en condition, page 4 !
Vous avez : le script :
On a vu qu’une variable, c’était $game_variables[X]
On va donc mettre si les deux variables sont égales au coordonées de l’interrupteur.

On aura cependant besoin de booléens, ne pas confondre avec le type, là je parle de connecteurs logiques : Et/Ou/Si/Alors/Fin/Sinon… => And, or, if, then, end, else…
Dans notre cas, on cherche à regarde si les deux valeurs ont une certaines valeurs. On utilisera alors un and, puisqu’on doit avoir les deux conditions remplies pour activer l’interrupteur.
Je fais cependant juste un petit cours sur les signes opératoires en programmation :

Code:


+ : addition                  - : soustraction              * : multiplier            / : diviser          = : égale


Ne vous inquiétez pas je ne vous prends pas pour des cons, j’y vais doucement c’est tout ^^ !
Voici maintenant d’autres signes :

Code:


< : strictement inférieur  <= : inférieur ou égale        > : supérieur      >= : supérieur ou égale


En voilà encore d’autre :

Code:


** : puissance                  % : modulo            != : différent            += : incrémenter        -= décrémenter


(j’expliquerais plus tard l’incrémentation et la décrémentation)
Enfin,pour comparer deux valeurs, ne surtout pas mettre =, il faut deux = pour bien dire qu’on cherche à comparer, et non rendre égal une valeur à une autre.
Petit cours donc pour la condition de l’exemple cité ci-dessus : On obtient donc :

Code:


Condition : script : $game_variables[1] ==  10 and $game_variable[2] == 7
>>> activer l’interrupteur 1
Sinon: désactiver l’interrupteur 1
Fin


Une seule condition. Vous me direz, ca parait plus dur etc, mais après l’avoir fait une ou deux fois,
Ca semble relativement simple et ça fais déjà gagner un peu de temps ^^ !
Maintenant, imaginez que vous ayez 20 caisses, un seul interrupteur, le joueur peut bouger n’importe quelle caisse, et donc n’importe qu’elle caisse peut activer l’interrupteur. Vous allez vous embêter à copier-coller l’événement et à modifier les ID lors de l’enregistrement des positions x et y de chaque caisse ?
Voici une petite astuce : Vous faites déplacer/modifier un événement : cet événement (donc une des caisse), et vous choisissez la commande insérer un script. Même principe, vous pouvez toujours utiliser le principe du $game_variables[x] ici…

C’est d’ailleurs ce qu’on va faire ! On peut enregistrer des informations depuis la commande déplacer/modifier un événement, comme sa position x ou y, son apparence, son opacité…etc
Ici, on veut seulement sa position x et y, qui sont enregistrées dans une variables @x et @y.
On insère donc le script :

Code:


$game_variables[1] = @x


On accepte, et on ré-insère :

Code:


$game_variables[2] = @y


Il ne reste plus qu’à sortir de la commande déplacer/modifier un événement, et d’y mettre la condition.
Vous pourrez ainsi copier-coller 30-100 fois l’event sans jamais avoir à changer quelque chose…

Je suis désolé, je sais, ça parait dur, mais une fois qu’on a testé, et qu’on s’entraîne une ou deux fois ça rentre ^^! J’admets que cela nécessite quand même d’être réveillé !

_______________________________________

On va donc passer à quelque chose d’un petit peu plus facile ! Depuis tout à l’heure on parle de variable de RM… Mais on ne peut pas en créer nous-même des variables ?! Et bien si !

Il suffit de mettre dans la commande insérer un script nomdelavariablequetuveux = valeur

Si on veut mettre du texte, il faudra mettre le texte entre guillemet, puisque l’on aura à faire à un type string.
Pour utiliser une variable à long terme, c’est-à-dire qui ne soit pas détruite lorsque l’on quitte l’événement ou on a initialisé la variable, on met un $ devant le nom.

Ainsi, $test1 = « Bonjour ! » pourra être utilisée quand on veut.
Pour afficher le contenu d’une variable, on peut utiliser l’instruction print(), qui sert à ouvrir une fenêtre windows pour indiquer une erreur ou une information.
Essayez donc print($test1)!

Pour afficher du texte, idem, il ne faut pas oublier de mettre des guillemets print(« Hello world ! »)
Pour concaténer plusieurs valeurs, c’est-à-dire assembler texte et valeur de variable, il suffit de séparer par des virgule :

Code:


 print(« Larcange à dit :  », $test1)


On peut donc enregistrer du texte dans une variable ! Mais ça veut donc dire que l’on peut aussi enregistrer du texte dans les variables RM ! Et bien oui =) ! $game_variables[1] = « Hey hey !», ça marche ^^ !
Ca sert moyennement à grand-chose mais ça marche !


Maintenant, voici une petite commande toute conne qui permet de changer de windowskin au cours du jeu :

Code:


$game_system .windowskin_name = « nomdunouveauwindowskin» 


Imaginez maintenant que vous voulez que le joueur choisisse son windowskin en event!
Tout simple !!

Code:


Choix :
windowskin vert : $game_system .windowskin_name = «wdsvert» 
windowskin rouge : $game_system .windowskin_name = «wdsrouge» 
windowskin bleu: $game_system .windowskin_name = «wdsbleu» 
annuler


Maintenant, légérement plus compliqué, mais j’en profite pour vous faire apprendre une nouvelle notion!
Imaginons maintenant que le windowskin change en fonction de la valeur d’une variable RM qui contient donc des nombres.

Hors, pour le nom d’un windowskin, on a besoin de chaine de caractère, puisque c’est entre guillemets.
$game_system .windowskin_name = $game_variables[1]
va donner une erreur donc, puisque l’on a deux types opposes, un type string.

On doit donc faire une « conversion » de deux type. Il existe en ruby des extensions pour dire que l’on prend une valeur non pas dans tel type mais dans celui là.
.to_s, s comme string, va indiquer que l’on transforme la valeur en type string
.to_i, i comme integer, en nombre entier donc.

On obtient donc ici :

Code:


$game_system .windowskin_name = $game_variables[1].to_s


Là ça marche! Vous manquez de place pour l’insérer dans la commande d’insertion de script? Il suffit de découper les commandes proprement !

Un truc à ne surtout pas faire serait :

Code:


$game_system .windowskin_name =
 $game_variables[1].to_s


RM ne reconnait pas les sauts de ligne comme une continuité, il va donc prendre les deux lignes comme deux commandes différentes.

En revanche, les valeurs entre crochets peuvent prendre plusieurs lignes. On peut donc avoir:

Code:


$game_system .windowskin_name = $game_variables[
1].to_s


Ou encore:

Code:


$game_system .windowskin_name = $game_variables[1
].to_s


Et à l’inverse, besoin de savoir quel windowskin le joueur utilise?

Code:


$game_variables[1] = $game_system .windowskin_name 


(N’essayez pas de mettre .to_i, mettre du texte en nombre, je ne suis pas sûr que RM apprécie xD ^^)

Une simple condition suffit après

Code:


si : le script : $game_variables[1] == « wdsvert » or « wdsrouge »
Message : « Je vois que tu aimes le vert ou le rouge ! »


Imaginez maintenant les possibilités de ce système d’enregistrement à l’aide de variable ! Vous avez besoin de changer l’apparence de votre héros, par exemple en pose de nage et vous avez besoin de le remettre en normal, mais plusieurs apparences sont possibles ?
Il suffit d’enregistrer le nom de l’apparence du héros avant, et de remettre l’apparence enregistrée une fois la scène terminée !
Vous avez besoin d’afficher une image selon la valeur d’une variable ? Même principe que pour le windowskin !
Ce système en mixte peut peut-être paraître compliqué au début, mais vous permettra tellement de choses par la suite…

Veuillez m’excuser pour les explications, je n’ai jamais été très doué pour expliquer aux gens xD. Si vous avez des questions, n’hésitez surtout pas, j’y répondrais avec plaisir…

Sur ce, bon making =) !

Excellent tuto. Quelques trucs que je connaissais, d'autres que tu m'avais appris, et le reste... à ce jour inconnu pour moi. x)
Très sympa tout ça, même si sur bien des points je ne pourrais pas utiliser cela dans Crash Lapin. =/

^^ Merci ça fais plaisir, première critique =) je suis content que t'ai arrivé à suivre, car c'est clair dans ma tête mais dès que je veux expliquer je pars en vrille ^^! Si t'as besoin d'aide pour crash lapin je suis carrément open pour aider =)

Pour l'instant je n'arrive pas à suivre faut dire je suis pas super réveillé lol
Mais après de ce que j'ai compris ça a l'air génial ^^
Après c'est surement comme quand on utilise les variables pour la 1ere fois, ça a du mal a rentrer mais une fois qu'on a le déclic tout nous semble si logique qu'on se demande comment on pouvait ne pas comprendre ^^

Du coup je reviendrais surement étudier ça quand j'aurais la forme

Oui, et je suis pas super professeur et je m'en excuse... Mais c'est dommage car ce type de système, d'utiliser du ruby en event, ça permet plein de choses!! Et malheuresement c'est pas super utilisé... Ralala... Bon je poste à l'instant un nouveau script de ma création, réalisé bah... à l'instant!

Bon tuto, ça me permet de réviser les bases.^^

.

Oui j'éditerais à l'occasion ^^! désolé mais regardez l'heure, plus la longueur du tuto ^^ J'avais la flemme de faire la mise en page!

C'est simpas d'avoir fait tout sa. (ouai je sais je suis en retard).

Mais c'est un sacré paver ce que tu nous as fait
Essaye de le ranger avec des titres et touts car on ne s'y retrouve pas xD

Pfiou !
On dit pourtant que pas mal de langages de programmation se ressemblent, moi qui viens du C, je trouve que le ruby change vraiment pas mal.
Et encore, là, comme c'est plus ce qui concerne la programmation sous RM, c'est encore pire, vu que pour les scripts RM, il suffit pas forcément de connaître le ruby, mais aussi le RGSS...

D'ailleurs, il y a certaines choses que j'ai toujours rêvé de faire avec des scripts (une jukebox, par exemple, parce que les events ça va deux minutes mais après c'est un peu lourd) mais pour l'instant, tout ce que j'arrive à faire, c'est du bidouillage...

Druyk a écrit:(ouai je sais je suis en retard)

Mais c'est un sacré paver ce que tu nous as fait
Essaye de le ranger avec des titres et touts car on ne s'y retrouve pas xD

+1 (et aussi sur le fait que je sois en retard d'ailleurs )
En fait, les explications pourraient paraître plus claires rien qu'en structurant un peu le cours (titres, utilisation du gras/italique, de la balise de code, etc.)

Par contre, si c'est une suite de cours, ça va être un peu gênant qu'ils se retrouvent dans le désordre...

Pas de soucis, j'édite le poste et en fait la mise en forme dans la semaine! Excusez moi hein, mais bon, j'avais fait le pavé une nuit, alors que j'avais pas dormi depuis 2 jours, et surtout que j'avais commencé à le taper une première fois, et à la moitié, mon ordi à planté, donc à l'heure où j'ai posté le poste, je me suis dit, "c'est bon, j'ferais la mise en forme plus tard, ils se contenteront de ça!"
Pour le jukebox, tout bête Garsim, je ferais un tuto pour en faire un si tu veux! Ca a été l'un de mes premiers script ça aussi ^^! (avec un artwork de Golden Sun (Ivan) en fond je me rappelle ^^ --' (y a 4 ans --')

Voilà voilà, je viend d'éditer enfin mon post, on va dire que vu le pavé, ça me fesais peur à moi même xD
Bon, et bien sur ce, bon making!

Bon, désolé pour le double post, simplement pour ceux qui n'auraient pas vu, j'avais fini par éditer mon post pour ceux qui n'avaient pas eu la foi de lire ce pavé sans mise en page x) e pense que c'est un peu plus clair maintenant lol =)
En espérant que ce tuto servira à certain apparement oui vu que Garsim nous a pondu un tuto sur les images etc... M'enfin bon =)
Sur ce, bon making!

Bah, pour ma part je ne relirai pas un pavé simplement parce qu'il a été mis en ordre. xD
Mais bon, c'est bien.