Discussion :

[Azharis]

Bonjour à tous,

Dans le cadre d'un moteur de jeu qui gère une pile de GameState, dans la pratique les state vont s'auto-détruire.
Par exemple, le state menu va dire au moteur de jeu de changer d'état pour passer sur le jeu lui-même. Après cette action, l'état menu devra donc être détruit.

J'aurais tendance à mettre dans la méthode changerEtat du moteur de jeu l'instruction pour détruite l'état, mais dans le cas ou c'est l'état qui fait appelle à cette méthode, ça pose un gros problème.
Certains règlent le problème en utilisant des singletons, donc pas de destruction manuelle, d'autres en renvoyant le nouvel état et c’est le moteur qui détruit ensuite l'ancien état.

Ces deux solutions ne me plaisent pas trop, la première créant des variables globales, la seconde forçant à adapter tout le code pour gérer l'état de retour (méthode update, gestion des évènements...).

J'aurais plutôt envie que le moteur de jeu stocke l'état à détruire, et le fasse une fois qu'on sort de la méthode de l'état.
Voici un scénario :
- le moteur appelle state->update
- l'état appelle moteur->changeEtat(nouvel état)
- le moteur remplace l'état et garde le précédent en mémoire
- au retour dans la méthode update de l'état, il fini ce qu'il a à faire
- au retour au moteur de jeu, dans la boucle principale, si il y a un état à supprimer, il le supprime (delete)

De cette manière, quel que soit l'objet ou le moment où un changement d'état à lieu, on a pas à se soucier de la destruction.

Pouvez-vous me faire des commentaires sur le fonctionnement que je propose par rapport aux autres solutions.
Ou encore mieux, m'en proposer une autre.

Merci.

[LittleWhite]

Bonjour,

En orienté objet, tout dépend de qui a la responsabilité de la mémoire (propriétariat) de votre GameState. De plus, je pense aussi que la destruction de chaque GameState à chaque changement peut être un peu overkill, car il est nécessaire de tout recharger par la suite.

Je n'arrive pas à voir les avantages de votre méthode, car la destruction du GameState est retardée (on dirait que vous allez placé le GameState à détruire d'un seau, pour le détruire plus tard).
Je suis aussi contre le Singleton. La méthode de tout gérer dans changerEtat, ne me semblait pas si mauvaise. Mais pour moi, c'est le chef orchestre de GameState qui doit gérer les transitions de GameState et donc appeler cette méthode (qui est une méthode membre du chef orchestre).

[Azharis]

C'est ça, dans mon exemple je retarde la destruction de l'objet.

Celui qui gère les états est le moteur de jeu.
Mais ceux qui décident du changement d'état sont les états (l'état d'intro va appeler l'état du menu, l'état du menu va appeler l'état de jeu...).
Le problème est que cet appel d'un autre état par un état, provoque la destruction de celui actuel dans le cas d'un remplacement, donc si il y a destruction immédiate (ce qui devrait être le cas), on détruit un objet en train d'être utilisé.

Du coup le chef d'orchestre remplace l'état, mais retarde la destruction le temps qu'il finisse.

Je pense qu'il y a mieux comme gestion, d'où ma question.

[LittleWhite]

Dans mon esprit, celui qui change l'état cela devrait être le moteur et non directement un état. Pour cela, l'état retourne ce qu'il pense qui devrait être l'état suivant (ou même lui même).

[Azharis]

Je ne vois pas comment autre chose qu'un état pourrait décider de l'état suivant.

Dans un cas concret, l'état du menu, quand le joueur click sur le bouton démarrer, l'état du menu fait appel à l'état de jeu.

[LittleWhite]

Dans le cas où, l'état retourne au moteur, l'état suivant à mettre en place.