• Advertisement
Sign in to follow this  

How to "reset" a singleton?

This topic is 1429 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This may come off as rather vague but I've been awake too long, and will post more info later if needed.

 

I have a state machine that deals with an abstract State class. Inherited from this are several Singleton gamestate classes. However, players will be able to transition back to certain states, and when they do I want the state to be totally reset - as if it were refreshed.

 

How would I go about doing this?

 

Thanks a ton!

Share this post


Link to post
Share on other sites
Advertisement

Rather than resetting a singleton and potentially breaking something that depends on it, it could be better to keep two of them - a previousState and a currentState.

Making your class able to deal with states changes like this so you won't have to worry about re-building the previous state if you're going back and wants things to be exactly as they were.

 

If that doesn't work for you, you can implement a function in the abstract class that the states resets themselves. So if the inherited states are very different in their core somehow they'll need to know how to reset.

 

But if I may suggest another approach... I would suggest to avoid using Singletons at all.

There's a bunch of topics on why they're bad (and the good bits as well) that you can look up, but generally, there's no reason at all to keep a singleton. With a good code design you shouldn't need to.

Share this post


Link to post
Share on other sites

I have to agree with Danicco, this does not sound like a good use case for Singletons.  Maybe your gamestate manager might be a singleton, but the individual game states probably shouldn't be.  

 

Your gamestates probably should inherit an abstract base class with the following functions (pseudo code follows)

class AbstractGameState
{
  void onEnter() =0;
  void onTick(Time dt)=0;
  void onExit()=0;
};

Now your derived classes implement these functions and as you transition between states, you call onExit() of the state you're leaving and then onEnter() on the state you're going in to.  OnExit() will give your states the opportunity to either save state for when you come back to that particular state, if thats what you want. OnEnter() will give your states the opportunity to either reload a saved state, or reset the state, again depending on what you want.

 

Inside your game state manager, you can have a transition function to manage this for you:

void transition(AbstractGameState* toState)
{
   myCurrentState->onExit();
   toState->onEnter();
   myCurrentState=toState;
}

Cheers, 

 

Bob

Edited by Scourage

Share this post


Link to post
Share on other sites

I think the OP means that e.g. each time the GameMenuState state is entered, it should show the main menu regardless of at which level the menu was left in a potential previous call. This would have nothing to do with reconstruction of a former runtime value after resetting it to an initial value. If I want the runtime value to persists I just need to do nothing!

 

That said, if the state objects have enter/exit handlers like Scourage has mentioned, implementing the enter handler of the respective states so that they initialize all of their internal values will do the trick. Other states, like e.g. the GameplayState state, will not do so (or they do so only on their first enter) and hence simply continue when being re-entered.

 

However, whether implementing game states as singletons is a good idea is a totally other question. Personally I agree with Danicco and would not implement them as singletons.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement