Get answers to all your basic programming questions. No Ogre questions, please!
3 posts • Page 1 of 1
- Posts: 3
- Joined: Fri Apr 08, 2011 10:40 pm
First I must say that yes I have done my research on this subject. I have read countless articles on state management. What I am trying to do is avoid using the singleton pattern for my game states in order to preserve the ability to have two states running at the same time. ( ex. Having a menu open while the game continues to run in the background ) Normally, I would create each state as a singleton and have the main engine class manage said states. Here is where I run into problems. One is the singleton issue stated previously. The other is that with the engine class managing the game states, in order to change states I must pass the changeState function two parameters, one that identifies the desired state and another which is a pointer to the engine class, thus needing the engine class to be a singleton. ( Say the IntroState state is currently running and I wish to change to the MenuState. If the state is not a singleton then the call would be changeState( Engine::getSingleton(), MenuState ) due to the engine class having to be a singleton in order to be accessable from IntroState ( Which I would like to prevent for encapsulation reasons ). Or with the state being a singleton, the call would be changeState( MenuState::getInstance() ). Either way one of them must be a singleton. I would much rather have a singleton StateManager class. )