Jump to content
  • Advertisement
Sign in to follow this  
PolyVox

Design question - Communicating between states.

This topic is 4024 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
Advertisement
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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!