# Applications > Dveloppement 2D, 3D et Jeux > Moteurs de jeux vido >  GameState auto destruction

## Azharis

Bonjour  tous,

Dans le cadre d'un moteur de jeu qui gre une pile de GameState, dans la pratique les state vont s'auto-dtruire.
Par exemple, le state menu va dire au moteur de jeu de changer d'tat pour passer sur le jeu lui-mme. Aprs cette action, l'tat menu devra donc tre dtruit.

J'aurais tendance  mettre dans la mthode changerEtat du moteur de jeu l'instruction pour dtruite l'tat, mais dans le cas ou c'est l'tat qui fait appelle  cette mthode, a pose un gros problme.
Certains rglent le problme en utilisant des singletons, donc pas de destruction manuelle, d'autres en renvoyant le nouvel tat et cest le moteur qui dtruit ensuite l'ancien tat.

Ces deux solutions ne me plaisent pas trop, la premire crant des variables globales, la seconde forant  adapter tout le code pour grer l'tat de retour (mthode update, gestion des vnements...).

J'aurais plutt envie que le moteur de jeu stocke l'tat  dtruire, et le fasse une fois qu'on sort de la mthode de l'tat.
Voici un scnario :
 - le moteur appelle state->update
 - l'tat appelle moteur->changeEtat(nouvel tat)
 - le moteur remplace l'tat et garde le prcdent en mmoire
 - au retour dans la mthode 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 manire, 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 dpend de qui a la responsabilit de la mmoire (propritariat) de votre GameState. De plus, je pense aussi que la destruction de chaque GameState  chaque changement peut tre un peu overkill, car il est ncessaire de tout recharger par la suite.

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

----------


## Azharis

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

Celui qui gre les tats est le moteur de jeu.
Mais ceux qui dcident 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 problme 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 immdiate (ce qui devrait tre le cas), on dtruit 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 mme lui mme).

----------


## Azharis

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

Dans un cas concret, l'tat du menu, quand le joueur click sur le bouton dmarrer, 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.

----------

