Les jauges en event

Citation :

Avant propos:
J'ai décidé de poster l'ensemble de mes tutoriaux sur l'ensemble des forums où j'ai participé pour permettre aux makers de toutes les communautés de profiter d'une base de tutoriels identiques.
Oui, ce sont des copier/coller de tutoriels que j'ai réalisé et posté par le passé ailleurs.
Merci de votre compréhension

Pour ceux qui peuvent utiliser google Doc:
Google doc: Les jauges en event
Vu que l’affichage d’Iframe pose problème, je reposte le tutoriel en version classique:

Les jauges en event

Il existe deux méthodes principales pour afficher rapidement et facilement une jauge. Il en existe certainement d’autres, mais je vais vous exposer les deux plus simples et rapides à faire (ça inclus 100 lignes de condition dans la méthode 1, mais c’est pas non plus long à faire car c’est que du copier coller et de la modification partielle)

Avant propos: Calculer le pourcentage
Pour calculer un pourcentage, il suffit de suivre la formule suivante:
[Valeur réelle de la jauge] X 100 / [Valeur maximale de la jauge]
Là, soit on garde [Valeur maximale de la jauge] dans une variable, soit on la remet à chaque fois dans le calcul, mais la première méthode est plus rapide et pratique.

Méthode 1: Pourcentage de l’image
Pour faire une jauge, il faut afficher une image, et dans [Déplacer] ou [Afficher] une image, vous avez en bas à gauche l’agrandissement en pourcentage.



Il suffit donc de faire une condition par pourcent en plaçant l’image en haut gauche (sauf cas particuliers) en indiquant sa position (encadré vert) et modifiant sa Longueur ou sa Hauteur suivant le sens de la jauge (encadré rouge). La plupart du temps, sur une jauge de RPG classique, le visuel est en horizontal, alors on modifie la longueur uniquement. Ce qui donne pour la première ligne conditionnelle:



Et il suffit de faire une incrémentation du pourcentage de la longueur pour chaque incrémentation de la variable pourcentage.

C’est une méthode assez longue, mais elle permet de mettre la jauge n’importe où. Elle peut faire laguer votre jeu et donc pensez à l’actualiser uniquement que quand cela est nécessaire et la laisser en silence quand cela ne l’est pas. Pour cela une condition d’interrupteur peut suffire.

Sachez qu’il est aussi possible d’utiliser une image différente par condition. L'intérêt est de permettre visuellement de faire des transitions sans incrémenter le pourcentage de la longueur, dans certains cas ça peut se révéler plus pratique.


Réduire le nombe de conditions: Deux façons de faire principales
Vous pouvez réduire le nombre de conditions en ne prenant en compte que les dizaines si vous le souhaitez. Visuellement, la barre réduira moins souvent, mais elle divisera par 10 le nombre de conditions.

Pour récupérer les dizaines uniquement sans pour autant faire des fourchettes de conditions alambiquées nous pouvons utiliser cette méthode:



Ceci n’est ni plus ni moins qu’un calcul permettant de séparer les unités des dizaines. Vous aurez donc un nombre d’un chiffre sur chaque variable. Par exemple pour 12 vous aurez 1 et 2 dans deux variables différentes.
Dans ce cas, vous n’aurez pas le pourcentage mais le chiffre réél coupé

L'intérêt est que, du coup vous avez maintenant des variables qui définissent les unitées et les dizaines qui vous permettront d’afficher des chiffres en image si vous le désirez.
Sous le même principe général, vous pouvez évidement calculer les centaines et les milliers si ils existent
Le calcul suivant vous permet de couper vos nombres jusqu'à 9999:



Il suffit donc ensuite de faires les lignes de condition en fonction: Si pour des PV basés sur des dixaines et des unités, si vous prenez que par tranche de 10%:
Si Dizaines = 1 Alors largueur de l’image = 10%





Méthode 2: Coordonnées de l’image et bord de l’écran ou cache
Placer sa jauge peut être un moyen efficace de donner une impression de réduction de celle ci. Si vous la placez au bord de votre écran par exemple, si elle recule, son visuel sera donc dépendant d’une variable de déplacement et non de taille comme la méthode précédente.

Pour cela il suffit alors de placer la jauge selon deux variables



[Jauge X ] et [Jauge Y]
Il suffit alors d’inclure la taille de la jauge dans le calcul du positionnement de l’image. Pour une barre de jauge de 100 pixels de long(se trouvant en haut à gauche en 0/0 dans cet exemple), on aura donc [Jauge X ]= [Valeur réelle de la jauge] - 100 et [Jauge Y] = 0 (qui ne changera pas dans le cas présent)

Et là une seule chose à faire:



Pas de condition, puisse que le rafraîchissement d’image se fait tout seul.

Ce qui donne dans notre exemple:



La contrainte est d’avoir une barre de jauge 100 pixels de long ou de calculer les modifications à apporter à la variable [Jauge X ] pour qu’elle se décale correctement en fonction du pourcentage. Là, j’ai choisi une jauge de 200 pixels de long pour montrer que ça marche aussi.

L’autre contrainte est d’utiliser une image en temps que masque au dessus de ou des jauges affichées. Cela sous entend que c’est une image au dessus des jauges et aura donc une ID forcément supérieure. Dans ce cas, vous ne pourrez pas utiliser de visuel transparent sur la partie qui affiche les jauges ou vous devrez ruser avec le bord de l’écran le cas échéant.

L’avantage est évident: on a un lag largement moins grand et une rapidité d’evenementing très grande puisse qu’aucune condition n’est à vérifier.

Souvent, les events makers préfèrent ou ont le réflexe d’utiliser la première méthode pour des raisons de souplesse mais aussi par logique immédiate, mais cette solution peut très bien s’appliquer à votre affichage de jauge.

Il existe une façon bien moins prise de tête ! Cela dit, tout dépend du style de jauge et des statistiques évolutives du/des personnages pour savoir quelle méthode choisir =]

Merci d'avoir partagé les tiennes en tout cas, ça reste très propre !

N'hésites pas à partager tes solutions, l’intérêt d'un google doc est justement de pouvoir le modifier facilement et de garder son contenu valide.

Pour l'instant je n'ai pas trop le temps mais ce sera avec plaisir =]

Un rendu in game aurait été un petit ajout très utile, je trouve. ^^
Mais, ça a l'air bien sinon, j'utilisais moi aussi cette manière quand j'avais du faire des jauges custom.

Ouep, le fait de ne pas pouvoir entrer la valeur d'une variable comme indice de grossissement est réellement handicapant. Sur RM2k3 il y a le PicPointer de Cherry et j'imagine que sur XP un script pas trop compliqué devrait également assurer cette fonction mais c'est dommage qu'elle ne soit pas native.

lidenvice a écrit:

Elle peut faire laguer votre jeu et donc pensez à l’actualiser uniquement que quand cela est nécessaire et la laisser en silence quand cela ne l’est pas.

Non, une centaine de conditions aussi simples que ça c'est rien du tout, un simple "Wait" suffit, pas besoin de se prendre la tête.

Ton idée de réduire le % au chiffre des dizaines est bonne, mais tu peux en plus afficher le petit bout restant correspondant aux unités après celui correspondant aux dizaines. De cette manière tu auras le même rendu que pour la première méthode avec seulement 20 conditions (10 pour les dizaines, 10 pour les unités) + une micro fonction déterminant la position de la jauge des unités fonction de celle des dizaines.

lidenvice a écrit:

La contrainte est d’avoir une barre de jauge 100 pixels de long ou de calculer les modifications à apporter à la variable [Jauge X ] pour qu’elle se décale correctement en fonction du pourcentage.

Oui, ou tu peux carrément remplacer le "*100" de ton calcul du % par un "*[longueur de la barre]", ça limite la marge d'erreur liée au tronquage des valeurs par RM. Attention également à bien mettre le "/[Vie max]" après, pour les mêmes raisons.

A noter également que le pourcentage peut être utilisé de manière brut comme coordonnée pour une barre horizontale classique mais on peut également le tarabiscoter pour en faire un HUD un peu plus fantaisiste (barre en diagonale ou en biais par exemple). Soyez créatifs !

Merci pour ces précisions Manderr.
J'ai voulu surtout faire un tutoriel pour débuter dans les jauges car la manipulation de variable n'est pas toujours évidente pour tous.
J’espère avoir le temps de faire un tutoriel plus avancé dans le domaine par la suite. Mais il reste tellement à faire pour aider les makers...

Manderr a écrit:

Non, une centaine de conditions aussi simples que ça c'est rien du tout, un simple "Wait" suffit, pas besoin de se prendre la tête.

Relm m'a prouvé par A+B qu'ill vallait en effet mieux acualiser la jauge de vie que lorsque cela est nécessaire. Pour preuve, chez moi, mon projet ne lag pas mais sur le PC (visiblement moins bon que le mien) de Relm, c'était à peine jouable ! Tout ça à cause d'un taux de rafraichissement de ma jauge de life en continu (j'ai pourtant veillé à inclure autant de wait d'une frame que possible pour éviter les lags mais ce n'est pas suffisant pour toutes les configs).

Enfin, c'est surtout vrai pour cette méthode ci:

"

livendice a écrit:

Sachez qu’il est aussi possible d’utiliser une image différente par condition.

"

L'affichage d'image (la fonction "afficher une image") est ce qui cause les plus gros lags sous Rm2k(3) !
Pour le reste, si les images sont déjà affichées (en transparence ou quoi) et qu'il suffit de les "déplacer", ça ne devrait pas poser de problème.

Mais bon je remarque qu'il est toujours préférable de rafraichir un code en faisant un appel d'evenement commun (contenant toutes les conditions) au moment opportun plutôt que de ré-actualiser sans cesse le code dans un processus parallèle !

En effet... Déplacer une image ne coute presque rien alors qu'afficher une image est l'une des choses qui coûte le plus. Afficher une image toutes les frame ou presque est une chose a éviter si vous voulez que votre jeu soit fluide sur tous les PC. De plus ce sera plus propre de voir une jauge bouger.

Et, c'est vrai que rafraîchir une chose tout le temps est souvent inutile.

Si on rafraichit tout le temps un déplacer image (comme dans la seconde manière de faire), ça ne laggue pas

Oui, mais ça reste inutile bien souvent et une succession de divers calculs du même genre pourraient faire lagguer des PC moins puissants.

AristA: Tu as testé sur un P2 300mhrz avec 32mega de ram ?

Ca me fait penser que j'ai plein de vieux ordis pourraves chez moi qui pourraient me servir à définir si oui ou non mon code est bien optimisé =]

J'essaierai sur ma calculette pour voir si ça laggue pas alors, histoire que les gens qui joueraient sur ce support ne soient pas défavorisés.

Aristroll... Je connais pas mal de gens qui ont encore des configs pourries, tu sais :/ Moi-même ma config ne me permet pas de faire de l'excès de zèle niveau processus parallèles.

On a tous des PC différents, le miens à pas mal de problème avec les battle anim et les picture alors que le précédent, moins puissant, n'en avait pas.

Je plussoie KoZzY: Mon win 2000 n'est pas super puissant mais beaucoup de chose ne lag pas dessus...

KoZzY a écrit:

Relm m'a prouvé par A+B qu'ill vallait en effet mieux acualiser la jauge de vie que lorsque cela est nécessaire. Pour preuve, chez moi, mon projet ne lag pas mais sur le PC (visiblement moins bon que le mien) de Relm, c'était à peine jouable ! Tout ça à cause d'un taux de rafraichissement de ma jauge de life en continu (j'ai pourtant veillé à inclure autant de wait d'une frame que possible pour éviter les lags mais ce n'est pas suffisant pour toutes les configs).

Pas si tu as utilisé la technique de Lidenvice. Parce que dans ce cas, n'importe quel jeu même le plus classique deviendrait un massacre. Cherche bien, tu as surement fait une erreur quelque part (autre boucle déficiente par exemple), mais ce n'est pas possible que ce soit ça. Contrairement à la plupart des langages, RM prends en charge et stabilise son code et à moins de le spammer (boucles ou chargement de picture sans wait), on arrive rarement à ses limites.
Je sais d'ailleurs de quoi je parle, lorsque j'ai automatisé la gestion des ennemis de notre projet de plateforme, il n'a montré des signes de faiblesse que lorsqu'il devait en gérer 10+, soit plus de 100.000 conditions par frame (oui, oui, j'ai compté approximativement), la plupart beaucoup plus complexes (et c'est un euphémisme) qu'un simple déplacement d'image, alors que mon ordi est un vrai tracteur.

Je ne sais pas pour la technique de livendice, je dis simplement qu'il est toujours préférable de faire un appel d'evenement commun lorsque c'est possible/nécessaire/opportun plutôt que de réactualiser le code en boucle dans un processus parallèle oO
Ca, tu ne peux pas ne pas être d'accord

Tout dépend de ce que tu qualifie de "moment opportun".
Si tu entends par la la technique de ne réafficher la barre que lorsque la variable change (truc de Joke), alors non, je ne suis pas d'accord, cette histoire de comparer deux variables identiques à la différence que l'une possède un temps de retard est beaucoup plus lourde que sa cascade de conditions.
Si tu entends appeler l'event après les lignes où tu modifie la variable (contact avec un monstre par exemple), alors oui ça peut éventuellement être un chouïa plus rapide mais c'est une vraie source de bug (oubli de mettre la ligne partout par exemple), tandis qu'avec un rafraîchissement régulier (pas nécessairement tous les frames, seulement tous les 1/10s suffit), on est sûr que ça correspond bien.

Mais on devrait parler de ça dans le Blabla parce qu'on flood un peu le topic là, même si ça reste en lien avec le making c'est une toute autre question.

Citation :

Si tu entends appeler l'event après les lignes où tu modifie la variable (contact avec un monstre par exemple), alors oui ça peut éventuellement être un chouïa plus rapide mais c'est une vraie source de bug (oubli de mettre la ligne partout par exemple)

c'est de ça que je parlais
C'est la technique que j'utilise, et comme je "copie colle" le code des ennemis, je ne risque pas d'oublier d'intégrer l'appel d'évènement =]

Citation :

une vraie source de bug (oubli de mettre la ligne partout par exemple

Dès que tu es organisé ça ne l'est pas, et même si tu oublies c'est très simple à retracer, justement. Alors que des process qui tournent en continue sans raison ça c'est une source de bug (et bien plus chiant à dépister).

Le système de KoZzY était simple : afficher une image suivant les HP, avec une boucle ça aisait lagguer mon PC à mort, avec un Call event ça passe niquel, rien de plus rien de moins.

Quand on affiche une image, un call event est mieux. Quand on déplace une image, on s'en fiche.


Je vois même pas pourquoi on discute alors qu'on est d'accord

En fait, c'est pas tant que ça la picture qui est le sujet mais le call event. Dans le sens que peut importe ce qui est dans une boucle, si elle est mise à jour constamment ça n'a souvent pas d'intérêt. Et ça peut être source de lag sur des PC moins performant. C'est tout ce que je voulais ajouter.

KoZzY a écrit:

Je ne sais pas pour la technique de livendice, je dis simplement qu'il est toujours préférable de faire un appel d'evenement commun lorsque c'est possible/nécessaire/opportun plutôt que de réactualiser le code en boucle dans un processus parallèle oO
Ca, tu ne peux pas ne pas être d'accord

Pourquoi livendice, dites moi? Lol => Liden Vice
Sinon, vos remarques sont très intéressantes.