Jump to content
  • Advertisement
Sign in to follow this  
gentleman

Beyond Game States

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

I’m looking for an advanced game state manager. I’m currently using a single array stack-based state manager, where only the last state gets updated, input etc. But I can’t implement Command Console or Profiler Output as states, because neither should stop update for the previous state and both need to get updated. Plus Command Console must takeover input. Yes I know you can hardcore implement both. But I want to integrate without treating them as special, just as any other state. I need your help.

Share this post


Link to post
Share on other sites
Advertisement
By the very definition of state, you can only be in a single state at a given point in time, and you remain there until you move on to the next. And so, by definition, no matter how you implement a profiler as a state, you will not be able to use it simultaneously with another state.

In short, you'll have to make your profiler something that's not a state.

Share this post


Link to post
Share on other sites
Here's how I manage my 'states' (or, as ToohrVyk pointed out, calling it something different is more accurate). I call mine Processes.

Each Process has its own chunk of code which it executes per frame (or has its own method for handling events, if that's how your system is setup). Each Process can have any number of children processes, where the children have their own code that gets executed. Nothing is blocking.

When you want to "change states", as you say, you simply take the current running 'top' process and replace it with something else. If you want to stop your 'sub-states' (children processes), you remove them as children from their parent process.

I've found this method to be fairly robust, and has satisfied most of my management needs concerning game state/flow. It's not terribly hard to implement (harder than a stack-based approach, however). It also has the benefit of being relatively parallelizable if you're careful about how you write processes.

Cheers,
--Brian

Share this post


Link to post
Share on other sites
I've used a modified approach in the past where each state was responsible for deciding whether or not it would suspend itself when another state was pushed. For example, in an RPG you might be in a town and then enter a menu. If the menu isn't full-screen, its a nice effect to leave the state which represents the town running and updating the screen, because it gives the effect that the town is 'alive'. Of course, input is directed only to the menu. That would be the approach I would use to implement a command console.

The profiler should probably not be a state, because, well, its not a state at all -- the command console at least makes sense as a state. Profiler output could be handled as an additional process that happens after a round of state update(s), overlaying its output, when switched on.

You may also want to consider that states have their own internal profiler, as it makes sense that you'd likely want to profile different things during different states.


Probably the most flexible approach is to base the states around a message system, much the same way that a Window's application is. Then states can choose to process/ignore/remove messages from the top down, allowing more flexibility and easier inter-state communication.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!