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.

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

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.