Sign in to follow this  

Design question - Communicating between states.

This topic is 3829 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

Ok, I'm having some design issues with my engine. I've implemented the State pattern and currently I have two states - 'play' and 'menu'. I also have a class 'Application' which holds the current state and a set of 'MenuPages' for loading, saving, level selection, etc. But how do I tie it all together? Let's take a simple example, imagine the user navigates to a MenuPage and presses a button to load a level or change the way something is rendered. Eventually the SceneManager neds to know about this, and the SceneManager is in the 'Play' state. At the moment the chain of funtions calls goes up one side of the tree (MenuPage tells MenuState which tells Application) and down the otherside (Application tells PlayState which tells SceneManager). But is there a better way? One option is to give the MenuPage or MenuState more direct access - maybe it has a pointer to the Application, to the PlayState, or even to the SceneManager. Though this seems slightly messy? Otherwse, I'm using boost so maybe signals/slots? But who sets this up? The Application object maybe could but doesn't have immediate access to either the MenuPage (as this is created via the MeuState) or to the SceneManager (as this is in the PlayState). Maybe some sort of message passing and message processng loop? Any thoughts appriciated!

Share this post


Link to post
Share on other sites
How about having the app contain a RequestSceneChange()? Then instead of passing a message up from the button to the menu to the app, just have the bottom level button call App.RequestSceneChange(), and when the app is ready to change it could call SceneManager.SetScene(PLAY).

Share this post


Link to post
Share on other sites
Right off the bat, I can tell you that you should not keep the triggering mechanism wrapped inside the GUI code. Instead, you should make a generic GUI "button" class that effectively wraps around an action trigger. The MenuPage would simply serve as a container for those buttons. So now the action triggers are owned directly by the MenuState.

At this point, the question is, how does the MenuState know which action triggers to create? One way to handle this is to make the PlayState a Facade for its internal components (like the SceneManager). Another way is to make the PlayState create the MenuState, which would make MenuState a much more abstract class.

Let me know what you think of these ideas. I'd be happy to help you more.

- Rob

Share this post


Link to post
Share on other sites

This topic is 3829 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this