Serait-il possible de mettre une action “rejouer la scène” 
ça permettrait de mettre dans la scène “moteur” des événements du genre “si on clique sur rejouer, alors …” plutôt que de répéter cet événement sur chaque scène.
Si ce n’est pas possible, ce n’est pas gênant.
On peut déjà le faire, il s’agit de mettre une action “aller à la scène <>” si tu es déjà dans cette scène pour que tout recommence 
Je croyais que tu faisait comme ça pour tes jeux 
Oui, bien sûr, mais il faut le faire pour chaque scène en donnant son nom.
Si l’action “rejouer la scène” existait, on n’aurait pas besoin de mettre le nom de la scène et on pourrait mettre l’événement une fois pour toutes, et se contenter d’un lien pour les autres scènes. (Ce que je fais pour “aller à la scène menu”.) Ce serait plus logique d’utiliser le maximum d’événements dans une scène “moteur”.
Mais ça n’a pas beaucoup d’importance, ajouter un événement n’est pas compliqué. 
Ben c’est simple
Au lancement de la scène tu met ta variable globale scène a la nom de ta scène
Et a la fin tu envoie vers la scène redirection sur laquelle a lancement de la scène tu as aller a la scène TXT"GBL(scène[])"
Donc tu n’as besoin que de modifier que la variable du lancement de la scène et tu ne te fait pas ch^** a chercher ton évènement contenant aller a machin
Crone123 : Mouaif, là on passe carrément à deux évènement au lieu d’un seul, tu multiplie les chances d’introduire des bugs dans ton jeu par 2 ou 3 ( Oubli de mettre à jour la variable globale, risque de modification de la variable globale, risque d’oubli d’insertion du lien… ) 
Je ne pense pas ajouter l’action. Il y en a déjà une qui peut remplir ce rôle de façon correcte donc bon…
Oui j’ai l’esprit compliqué
Mais rien qu’en voyant ça je ne vous dit as le nombre de truc de ce genre que j’ai mis dans le jeu
De manière générale, il est recommandé de faire “KISS” : Keep it Simple, Stupid. ( « Fais simple, stupide » en français ).
Réfléchis sur la manière la plus simple de faire, avec tout ce que tu as à ta disposition : Groupes, sous évènements, lien si tu as des choses répétitives, commentaires appropriés…
Par exemple, dans ton cas, il faut se demander si mettre une variable globale, un évènement et un lien, plus une scène supplémentaire, en vaut bien la chandelle par rapport à ce que tu gagne. Dans ce cas, autant garder une action simple à mon avis.
Fais gaffe, parce qu’à la fin, tu va arriver à un jeu impossible à gérer.
Oui c’est compliqué mais c’est de la pure logique et la structure est bonne donc pas de problemes
Oh oh ! 4ian est d’humeur à faire des bisous… 
Ceci dit, c’est parfaitement exact ; dans la mesure du possible, il faut essayer de simplifier sa programmation au maximum, parce que, dès qu’un jeu est un peu plus sophistiqué que le shoot ou la plateforme, la programmation se complexifie en proportion. Et donc, si on fait compliqué même dans les fonctions simples, on risque de se perdre rapidement ou de ne plus parvenir à détecter les sources potentielles de bugs.
Je suis bien placé pour le savoir, parce que j’ai bien avancé dans la programmation de jeux basés sur le tour par tour. Avant, je pensais qu’un jeu de ce type devait fonctionner à partir de boucles (dans le genre “tant que”) ; en fait je pensais qu’un jeu au déroulement en tour par tour n’était qu’une sorte d’énorme boucle qui répétait les phases de jeu jusqu’à ce que les conditions de victoire (ou de défaite) soient remplies. C’est à peu près ça, en fait, sauf que ce n’est pas une bonne idée d’utiliser “tant que”. J’ai compris en expérimentant que l’on pouvait (devait) travailler avec des variables, et que les différentes phases du jeu s’enchaînaient suivant la valeur de ces variables. Naturellement, s’il se passe beaucoup de choses (plusieurs phases) pendant un tour de jeu (et s’il y a plusieurs joueurs ou plusieurs factions avec leur tour de jeu respectif), cela fait au final beaucoup de variables à gérer. Et si on travaille “à l’arrache”, sans une vraie cohérence dans le raisonnement, on risque fort de ne pas en voir le bout.
Je suis tout à fait d’accord avec cela. En compliquant inutilement la programmation on augmente le risque d’erreurs, et ces erreurs deviennent plus difficiles à localiser.
Dans certains cas cela peut aussi ralentir le jeu.
Je crois que la fameuse maxime Shadock “pourquoi faire simple quand on peut faire compliqué ?” n’est pas adaptée à la programmation.
D’ailleurs, on a souvent tendance à se dire qu’un morceau de code/d’évènement est parfaitement compréhensible au moment où on le fait, vu qu’on est plongé dedans. Cependant, il ne faut pas oublier que plus tard, quelqu’un pourrait devoir modifier ce code/évènements, par exemple le créateur du jeu même qui vient retravailler sur son jeu après une pause de quelques jours/semaines/mois.
Aussi il ne faut pas hésiter à bien regarder si le but du code/évènement est bien clair aux yeux d’un “créateur extérieur”, si il n’y a pas moyen de faire plus élégant ( Variables bien nommées par exemple ) et si c’est un peu compliqué, mettre un commentaire pour expliquer brièvement le but et le fonctionnement.
Au niveau de l’optimisation, un bouquin de programmation en C++ donne ces deux règles :
Ne soyez pas prématurément optimiste et ne soyez pas prématurément pessimiste.
La première signifie qu’il faut éviter de se lancer directement dans quelque chose de compliqué en espérant faire plus efficace que la version simple à laquelle tout le monde aurait pensée. Privilégier simplicité et sureté du code, et optimiser ensuite si nécessaire, en ajoutant par exemple si nécessaire un commentaire sur une partie de code un peu compliqué pour signifier qu’elle aurait pû être plus simple mais qu’elle a été optimisée.
La seconde signifie qu’il faut éviter tout de même les mauvaises pratiques qui vont dégrader les performances du jeu, alors qu’on aurait pu faire simple et efficace. Exemple tout bête avec Game Develop : Si un évènement possède deux conditions, une vérifiant la collision entre deux objets et l’autre l’appui sur une touche. Mettez l’appui sur une touche en premier. Cette condition est très légère, et si Game Develop voit qu’elle est fausse, alors il zappera la deuxième.
A propos de variable bien nommée, y a-t-il un moyen simple de changer un nom de variable ? Parfois on s’aperçoit, un peu trop tard, qu’il aurait mieux valu nommer la variable autrement.
(Je me demande s’il ne vaudrait pas mieux changer le titre de ce fil…)
Non, pas vraiment…
Il faudrait que j’essaie de mettre sur pied une fonctionnalité qui puisse identifier et renommer une variable, pareil pour les objets.
Il y a toujours la solution d’éditer en mode texte le fichier .gdg et d’utiliser la fonction remplacer du bloc notes mais j’imagine que c’est très risqué… 
Oui on peut, je l’ai déjà fait pour supprimer 500 image d’un projet.
Le fichier est codé en xml :
Ca ressemble à ça : (à peu près)
Disons qu’il faut bien faire une copie de son jeu avant, et vérifier que tout marche bien après la modification.
J’aime l’idée de Clique-Mulot, mais pas seulement pour la recharge de la scène. La scène “moteur” pourrait renfermer toutes actions qui se retrouve dans toutes autres scènes du jeu. En d’autre terme, inclure les évènements et actions d’une autre scène qui est répété et répété. 
Oui, c’est le principe pour créer plusieurs niveaux au sein d’un jeu par exemple. Il y a un petit paragraphe là dessus dans l’aide ( Rubrique Résolution de problème et FAQ )
Ah ! Bien, merci de l’information 
… Moi qui recopiait les scènes au complet 
. Je vais de ce pas faire les corrections qui s’imposent