Améliorer la fléxibilité des évènement

1: mettre un genre de goto pour aller a un evenement présis (pour en sauter par exemple)

2:faire un genre de gosub = aller as un evenement et quand il rencontre un return, il revient la ou il s’étais arreter

3:pour les fonction, mettre plusieurs choix possible:

normale = pas de changement
attendre la fin = attend que la fonction soit terminer avent de continuer
éxecuter en paralèlle = éxecute la fonction en paralèlle du code courent

4: attendre X temps avent de continuer (sera du “environ”) sert juste a dire a game develop d’attendre un peut avent de continuer
peut être utile par exemple dans les boucles pour ne pas boucler trop vite

5: faire une selection multiple et des drag end drop

Beuuark !
Comme dit Wikipédia :

Plus généralement, les goto sont par exemple possible en C++, mais ultra déconseillés, il n’y en a par exemple pas un seul dans le code source de Game Develop.
La dernière fois où j’ai du utiliser goto, c’était en basic il y a bien longtemps. Et encore, je pari que j’aurai pu faire autrement à l’époque.

Ca s’appelle une fonction, ça accepte en plus des paramètres, et c’est dispo sous GD sous le nom d’évènement fonction. :slight_smile:

Pas facile à coder du tout.
Ça peut perturber la logique de tes évènements, et puis, as tu déjà vu un langage de programmation qui execute une ligne de code, attends 5 secondes avant de faire la suivante, mais en même temps continue celles d’après ?.. Bonjour le casse tête.
Mais c’est pas totalement idiot non plus j’admets.

GD attend déjà la fin de la fonction avant de continuer ( enfin, je dis “attendre” mais je vois même pas comment faire autrement que d’attendre ).

Ça serait intéressant.

Ba tu voi par exemple dans RPG Maker tu as un truc comme sa ou quand tu veut déplacer un évenement (je sais rien a voir ici)
mais tu as un truc comme sa

Bref quoi qu’il en soit il serais bien d’aumoins éxecuter des evènement en paralèlle (thread) par exemple
4ian je vais te dire pourquoi notament je voudrait sa

Dans mon exemple (a tu regarder au moins) ou je me suis pris la tête
comment je dit moi au perso d’aller de méton 3 case en bas puis 2 a gauche, 5 en haut et 1 a droite, comment je fait sa
comment je dit a game develop, d’éplace le perso de une case dans teklle direction, quand il a fini éxecute la suite
donc en groos sa ferais sa:

1 en bas (attend la fin)
1 en bas (attend la fin)
1 en bas (attend la fin)

1 a gauche (attend la fin)
1 a gauche (attend la fin)

1 en haut (attend la fin)
1 en haut (attend la fin)
1 en haut (attend la fin)
1 en haut (attend la fin)
1 en haut (attend la fin)

1 a droite (attend la fin)

Tu comprends ce que je veut dire au moins ?

D’accord, mais les évènements de Game Develop se rapprochent beaucoup plus d’un véritable langage de programmation que les évènements de RPG Maker.
Je le redis :
As tu déjà vu un langage de programmation qui execute une ligne de code, attends 5 secondes avant de faire la suivante, mais qui en même temps continue celles d’après ?..
Et pour les thread, as tu vu un jeu qui utilise plus d’un thread pour gérer le déplacement de ses personnages ? A part pour une intelligence artificielle où on a au pire besoin d’un thread supplémentaire pour profiter éventuellement d’un second coeur du processeur de la machine, ça court pas les rues.
Et puis troisième point, si au final j’utilise les thread, imaginons que tu ait pas mal de personnage, genre 50, qui se déplace en faisant des pauses. Je fais quoi, je créé 50 thread pour chaque perso qui fait une pause ? Et si il y a beaucoup de pauses dans les évènements, j’en créé encore plus ? Bof bof bof bof, c’est pas fait pour. Ce qui est fait pour c’est les chronomètre, même si c’est moins flexible.

Alors please HELP :cry:
As tu tester mon jeu, je t’avais demander de m’aider mais tu doit être déborder mais comme tu dit rien

Et sinon j’ai effectivement jamais vue un programme attendre 5 seconde tout 'en continuent la suite
moi j’ai pas dit sa, j’ai juste dit d’attendre avent de continuer la suite :slight_smile:

Et oui je comprend de ne pas crée de tread car sa sert a rien sauf pour les fonction non ?
ya rien qui est intéressent donc ?

A quoi ça servirait d’exécuter plusieurs choses en même temps ?
Si c’est pour agir sur des objets, ça ne sert à rien car ils sont affichés à la fin de la boucle principale (au temps tout exécuter à la suite). Sauf peut-être dans le cas d’un téléchargement de fichier. Mais, c’est très rare.

Là où davyid veut en venir, c’est que la logique des évènements entre RPG maker et GD est assez différente.

Prenons un exemple : deux personnages sur une carte qui se baladent chacun de son coté, mais à des rythmes différents.

Dans RPG Maker :
Perso1 →
Tourner aléatoirement
attendre 5 images
avancer d’une case
Recommencer

Perso2 →
Tourner aléatoirement
attendre 12 images
avancer d’une case
Recommencer

Les évènements sont visuellement séparés, et fonctionnent en parallèle.

Dans GD, faudra gérer ça dans la même page d’évènements, avec deux chronos différents, en plus de gérer le déplacement case par case (temps à attendre avant que le perso arrive à destination, vérifier son arrivée à destination, puis enchainer la suite des instructions).

C’est plus compliqué, et moins intuitif.
Probablement parce GD est d’abord conçu pour les jeux d’action, où le déplacement “case par case” est moins central.

Dans GD, tous les évènements sont en Parallèle.
Dans RPG Maker, on peut choisir entre Parallèle, Autorun (évènement bloquant le joueur jusqu’à la fin de l’exécution), Appui touche (le joueur appuie sur une touche au contact de l’évènement et exécuté son code) et Contact Evènement (l’évènement touche le héros et exécute son code).
Ca donne pas mal de flexibilité dans l’organisation des cartes, et la manière par exemple de concevoir des cinématiques.

Notons également que pour GD, il n’y a pas d’unité de temps indivisible.
Dans RPG Maker, l’unité de temps indivisible, c’est l’image/seconde.
Ce qui permet de rythmer implicitement tous les évènements entre eux, tout en laissant assez de temps au processeur pour les instructions machines.

Le problème de l’image par seconde, c’est qu’elle peut varier d’un ordi à un autre. :wink:

Le principe de RPG Maker doit donc de fixer le nombre d’images par seconde, ce qui est très contestable.

Sur RPG Maker XP (et probablement les autres versions aussi), on peut choisir un framerate de 20 ips ou 40 ips.
On peut aussi le hardcoder dans les scripts ruby.
Je pense que c’est ce qui permet de cadencer l’ensemble des évènements au même rythme, et donc de permettre des gestions particulières de ces derniers.
Dans GD, il faut créer un chronomètre pour tout, et unique pour chaque utilisation.
Peut être qu’un chronomètre global de cadençage, fixable en début de jeu, résoudrait ce recours systématique à ces chrono faits main.

Mais comme je l’ai dit plus haut, GD n’est pas dans la même logique de programmation que RM.
C’est d’abord à l’utilisateur de s’adapter à cette nouvelle manière de faire, avec ses avantages et ses limitations.

Le problème est que:
Imaginons un vieux PC, si on fixe le nombre d’images par seconde, le vieil ordi risque de ne pas réussir à calculer le nombre demandé d’images en une seconde, l’ordi et tout le jeu va ralentir. :wink:

Ca veut juste dire que le jeu lui même est mal optimisé, avec pleins de calculs redondants et de vérifications inutiles.
Ou que le PC est tout simplement trop vieux.
Les RM ont 5 ans de retard sur les config PC (et je suis gentil, VX tourne sur un PC de début 2000).

Je teste des jeux RM sur pas mal de config, et ça reste jouable la plupart du temps.
Pour que ça rame, c’est souvent qu’on en demande trop au moteur, pas à cause d’un frame rate trop élevé.

Ce qu’il faut comprendre, c’est qu’entre deux images, le processeur continue de tourner pour gérer le reste.
Moins on met d’images par secondes, plus le jeu a de ressources pour tout ce qui n’est pas graphique.
Et comme l’oeil humain est limité à 24 ips, pas besoin de charger le bouzin en 60 ips.

Ce cadençage forcé permettrait aussi de résoudre le problème des chrono jamais égaux à une valeur donnée.
Puisque le temps écoulé se calcule en images, et non plus en fraction de seconde.
C’est pour cette raison qu’il n’y a pas de chronomètre dans RPG Maker, et qu’il arrive pourtant à gérer des jeux très complexes dans la gestion du temps, voir des A-RPG.

Mais je crois aussi que GD doit suivre sa propre méthode, afin de proposer d’autres manières de faire, voir des manières uniques qui aboutiront sur des jeux uniques.

Ca veut pas dire que les calculs sont redondants.
GD est, en plus, plus consommateur que RPG maker car plus récent.
Donc, autant laisser le framerate libre, comme ça l’ordinateur se mets à la vitesse qu’il PEUT maintenir, car si les calculs sont importants et que le processeur est vieux, le nombre d’images par secondes va baisser. Et si on utilise cette cadence au lieu des chronomètres, le jeu va ralentir, alors qu’il pourrait garder la même vitesse (dans le cas des chronos) avec un peu moins de fluidité.

De plus, l’utilisation de secondes avec le terme “chronomètre” est rapidement compris par un utilisateur débutant.
Alors que si on part tout de suite dans un chrono avec Fps, il va falloir lui expliquer que 1 image = (1 / le fps du jeu)secondes.

D’où l’intêret des options pour fixer le nombre maximum d’images par secondes dans Game Develop.
( A 60 par défaut, car même si on dit que l’oeil humain voit à 24 ips, c’est pas aussi simple que ça, et plus il y aura d’images, mieux ce sera. A 60 c’est largement bon sans pour autant mettre à genou les PC ).

Non. Un jeu qui tourne à 1500 images par secondes tournera à cette vitesse car l’ordinateur aura suffisamment de puissance pour gérer et les ressources et l’affichage.
Si un jeu tourne à 10 images par seconde, c’est parce que l’affichage ou les autres ressources demandent trop de temps de calculs : Les FPS sont juste une mesure, qui inclus combien d’images le jeu a pu générer en une seconde, mais quand on dit “image” on parle de l’ensemble des calculs nécessaires pour créer cette image, ce qui inclue évidemment l’avancement du reste du jeu. Sinon, ça ne servira à rien d’afficher deux fois la même image.

Plus il y a d’images par seconde, mieux c’est.

En fait, c’est même pas la méthode de GD, c’est la méthode de tous les jeux du commerce ( à part peut être de rare exceptions ).
Grâce à cette méthode qui consiste à faire tourner le jeu le plus vite possible et à utiliser le temps écoulé entre chaque image pour faire avancer le jeu, on exploite au mieux les capacités du PC, tout en permettant aux PC plus anciens de faire tourner le jeu, mais sans ralentir le jeu. Si le PC est vraiment trop ancien ou le jeu trop consommateur, alors on va voir l’apparition de lags.
Maintenant, pour les inquiétudes relatives au fait que le jeu bouffe toutes les ressources du PC, il suffit de fixer un maximum de FPS, et hop, on est tranquille.

Même pas !
RPG maker ne gère pas l’accélération matérielle.
Tout passe par la puissance brute du processeur central.
Ce qui le rend très inférieur à GD en terme de traitement.
Deux images en rotation suffisent pour faire ramer le moteur (et donc le jeu).
Ca oblige le makeur à optimiser ses évènements pour ne pas surcharger son projet. Mais ça limite aussi la débauche visuelle.

Faut voir … :sunglasses:

C’est plus simple de faire :

Action 1
Attendre 50 frames
Action 2
Effacer évènement

que de passer par :

Si Action1Faite == 0
Action 1
Action1Faite = 1
fin si
si variable action2Faite == 0
Si chrono > 2.5 secondes
action2
action2Faite = 1
fin si
fin si

Je trouve le premier plus intuitif pour forcer les évènements à s’enchainer.
Dans GD, la seule fonction qui s’en approche, c’est “au lancement de la scène” qui oblige GD à traiter d’abord ce qu’il y a dedans.
Le reste du temps, il faut créer des dizaines de variables de scène pour gérer l’enchainement des évènements (exécute celui-ci une fois, celui-là tout le temps, celui-là en priorité, etc. ).

Je suis bien d’accord que ce coté là est moins pratique. Peut être y aurait cependant moyen de créer une sorte d’évènement “Attente x secondes” qui marcherait comme un chronomètre automatique attendant un certain nombre de secondes avant de réaliser ses conditions/actions.
Ça simplifierait les choses, tout en étant possible à faire car il ne s’agirait que d’un évènement avec un “chrono intégré”, de quoi réconcilier le monde des chronomètres et le monde des “attendre x temps”.

Bien bien bien, c’est bien beau tous sa mais sa ne résous pas mon problème a moi :wink:
comment je fait sa moi, en plus GD boucle toujours donc comment tu fait
a part mettre 50 variable et 800 chronomètre (j’exagère)

voila l’intérêt des fonction avec tous ce que j’ai dit ici:

pour les fonction, mettre plusieurs choix possible:

normale = pas de changement
attendre la fin = attend que la fonction soit terminer avent de continuer
exécuter en parallèle = exécute la fonction en parallèle du code courent

Je pense que sa pourrais fonctionner comme ça non ?

Ba sinon comment je fais moi pour dire par exemple un autre perso que le mien
d’avancer de tans de case mais d’attendre bien entre chaque déplacement ou sinon il fait tous d’un coup

Avenser 8 de case en haut
Avenser 5 de case a gauche
Avenser 3 de case en haut
Avenser 6 de case a droite
Avenser 4 de case en bas

Pour comprendre ce serais bien de voir mon exemple aussi :wink:

Faire des déplacements a la RPG Maker est bien moi car sa fait plus propre je trouve
mais va gérer les déplacement toi

J’ai aussi divers projet comme déplacer le perso a la souris mais la va me
falloir du pachi machin truc et va falloir en plus gérer tous les déplacement
en plus la gestion du chronomètre c’est bien beaux mais sa ne marche pas toujours
et en plus tu peut pas en mettre en parallèle car comme GD exécute tous du début a la fin

Ba ya une raiponce toute faite pour sa, va voir ailleurs et utilise RPG Maker
OUI MAIS TU PEUX PAS TOUS FAIRE AVEC RPG MAKER

bref moi la je déprime car je voie pas comment faire, surtout que la c’est du gros bouleau pour moi
d’avoir fait sa mais vu ce qui m’attend, je vais surement mettre la clé sous la porte

Alors surtout si quelqu’un veut m’aider hein surtout qu’il lève sa main bien haute
Et 4ian si tu peux me dire comment je peux faire, je t’en serais reconnaissant, merci

Et sinon, comment il marche le chronomètre, c’est quoi comme unité de temps qu’il utilise
image par seconde ?

car dans c’est cas la c’est pas térrible hien comme truc :frowning:

4ian a déjà répondu à cette possibilité, qui est d’ailleurs impossible.
Car, ça poserait des problèmes au niveau de la logique du jeu.

Oui, mais ça fait longtemps que les déplacements cases par cases sont dépassés. Ca remonte quasi à l’Antiquité (exagération).
Le problème, c’est que ça ne serait utile qu’à toi… :wink:

On ne doit pas jouer aux mêmes jeux, alors.
Rien que les T-RPG, si t’as pas de case par case, t’es vite coincé.

Mais le problème n’est pas à ce niveau.
C’est tout simplement faire en sorte qu’un évènement ne soit traité qu’une fois, et effacer ensuite.
A la vitesse où GD traite les informations, c’est très difficile de repérer les traitements en double (à moins de blinder son code de boite de dialogue de la section Interface).
Il faut donc pour chaque évènement à usage unique créer une variable de scène exprès pour en désactiver le traitement après.
Et bien sûr, il faut que cette variable soit unique, sinon elle risque d’être réutilisée pour un autre évènement, et bonjour les bugs …

La question de Dayvid est basique : comment réaliser une cinématique ingame dans GD ?
Sans une fonction “Attendre x unité de temps avant de poursuivre la suite du traitement”, c’est malheureusement assez complexe. :ugeek:

Les secondes évidemment, c’est marqué un peu partout. Cherche avant de dire que c’est pas terrible, les chronomètres de ce type sont utilisés dans pleins de jeux pour vérifier que des durées suffisantes s’écoulent.

Ça n’empêche rien, tous les jeux exécutent leurs actions une après les autres, tous les logiciels, tous les systèmes d’exploitations font un truc après l’autre.
Il faut arrêter de comparer avec RPG Maker, c’est plus de l’inspiration que ça donne j’ai l’impression, mais ça fait presque des dégats. :wink:

Les chronomètres marchent très bien, c’est juste que leur utilisation dans ton cas n’est pas des plus simples.

Pour le reste, j’ai déjà répondu, ça ne concorde PAS DE TOUT avec le système de Game Develop, car Game Develop est basé sur les structures d’un langage de programmation et un langage de programmation ne permet PAS d’attendre qu’une ligne se finisse tout en continuant les autres.
Par contre, il y a PEUT ETRE possibilité que je créé un évènement spécial à retardement. En attendant, il faut faire sans, comme ceci par exemple :

[code]Conditions : Le chronomètre est supérieur à 1 secondes.
Actions : Remettre à zéro le chronomètre
Faire +1 à la variable Etat
Conditions : Variable Etat est >= à 4
Actions : Mettre la variable Etat à 0

Conditions : La variable Etat est = à 0
Actions : Faire bouger Perso1 vers le bas
Conditions : La variable Etat est = à 1
Actions : Faire bouger Perso1 vers la gauche
Conditions : La variable Etat est = à 2
Actions : Faire bouger Perso1 vers le haut
Conditions : La variable Etat est = à 3
Actions : Faire bouger Perso1 vers la droite[/code]

Dans ce que j’ai fait, les objets Perso1 vont bouger de façon continue en faisant un carré. Il est alors facilement d’ajouter d’autre mouvement pour les autres personnages.

En effet, il faut passer par un système d’état comme décrit plus haut.
Cependant, on y arrive avec un peu d’organisation.
Je suis d’accord qu’un “Attendre X secondes” serait appréciable, j’ai d’ailleurs dis que je pourrais peut être le faire. Mais en attendant, Game Develop propose la base de ce que nécessite tout jeu afin de gérer le temps, des chronomètres.
Et ne pas proposer les chronomètres mais juste des “Attendre x secondes” aurait été la pire des erreurs. Donc je gère dans l’ordre des priorités.