it seems to me that that would only serve to make more code to write. personly i use a single class to handle the game state. i keep it tidy and havent had any problems with my state manager class yet.

I think that tutorials are terrible abominations, and tutorials written by people who are not experts or masters in the particular problem domain are even worse. Then there's the fact that most tutorial authors aren't necessarily all that great at communication to begin with, except in code, so all that tutorials end up being is code dumps, which aren't helpful.

Now, all of the above may or may not apply to you at all -- I don't know you; but statistically speaking its likely that you fall somewhere in the category of "not quite experienced enough to write a tutorial," but who knows. I won't assume.

That's less of an issue, however, than the fact that I don't think the concept you're trying to impart is particularly useful. It sounds like you're advocating the construction of large, monolithic hard-coded classes (one for each "state"), possibly with a lot of duplicate functionality, which is brittle, hard to maintain, and doesn't scale well. It might be ideal for quick, small games, but it really isn't a scalable system, especially the way you describe how transitions might work.

Basically, you seem to be advocating a state machine that is hard-coded and monolithic, versus a state machine that is designed to be generic and reusable. Have I misunderstood you? I don't see any advantage to your suggestion as I currently understand it and think that a tutorial on the subject would only serve to increase the spread of bad or misinformation.

Quote:
I do not "advocate" a state machine at all. An example of the technique could be a menu. Say there is a MAIN_MENU object that displays the main menu to the user. It has its own program loop and its own message handler. WinMain calls that program loop. The user goes through the displayed menu and presses ENTER. The MAIN_MENU object recieves that message and calls the program loop of a CHILD_MENU object which displays it's contents using it's own draw function. When the user is done with the submenu he/she can select "Back" in order to go back to the main menu. When the CHILD_MENU gets this message it simple exits its program loop and the program has suddenly returned to the main menu.

That is a state machine. It is very nearly the textbook example of a state machine.

That kind of high level overview isn't enough to dissuade me from thinking that the concept still seems brittle -- consider drawing, for example, which is a decently well-structured medium-to-large scale product will be the exact same process regardless of current state, with only minor variations. You seem to imply that each state object will duplicate the render loop. This is wasteful except in the rare instances where your rendering functionality is completely different from state-to-state. There's just a lot of implementation details that you're not covering here that, based on what you've written and how you've written it, could be implemented in extremely poor ways.

Perhaps you should construct a first draft of this article, which would help us get a better handle on what you are going for.

Quote:Original post by space warp
Really? I though state machines where when you had a enum or similar structure to describe the game state and then a ... don't know what to call it ... "router-function" decides what functions to call based on the game state and I'm definetly not doing that.

No, that's simply one of many idioms used to implement a state machine.