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.
Partager