Game State Design

In my experience, there aren't more than about four "main application" states. I've done the OO approach, and it worked okay but it didn't really gain me anything. These days, I just use enumerations and switch statements. My code works just as well as it did before, with a tenth of the coding.

The whole point of finite state machine is to get rid of switch statments. If you are making a complicated game with many different states, a switch statment can get rather long and hard to manage. Encapsulating them inside classes can make your code more manageable.

It all depends on your project, if you have lots of states, then I suggest FSM. Otherwise if you only have a couple states, a switch statment would do fine.

Quote:

The whole point of finite state machine is to get rid of switch statments.

"Finite state machine" is a behavioral description of a machine; it can refer to an OO-heavy implementation or a simple switch statement. But yes, the "lots and lots and lots of classes" approach is to get rid of switch statements.

Quote:

Original post by GamerYZ a switch statment can get rather long and hard to manage.

As a matter of fact it can't; the worst you can do is have one line per case (consisting of the case, the function call, and the break statement). If you have more of these cases than can fit on a page of text, you REALLY need to refactor into something more flexible than a FSM. Anyway, the OO pattern is not particularly useful for managing code length, since you end up with so much more code. It's more useful for managing object lifespans. But the states and transitions in this particular instance are so simple that there's really no reason for the ten-ton approach.

It is true that OO approch require more coding, and of course every programmer have his or her own coding style.

I've used state classes in a game project I did. Each character state was in its own class. This way if, for example, the character is not climbing the wall correctly, I know exactly where to look for problems. Also this way enabled us to easily add more functionalities to the character if needed.

Could I use a switch statment to handle this project? Yes, I could have. But to me the OO aproch was more suited for this project.

Quote:

Original post by GamerYZ I've used state classes in a game project I did. Each character state was in its own class....the OO aproch was more suited for this project.

Of course it was. I use an OO FSM for exactly the same thing. I don't want to give the impression that an OO design is never the right approach; only that it rarely is for the main application FSM.

I've used a switch statement before, but the problem I run into is that I need to put a switch statement for each function called every frame.
The render function needs a state switch
The key input function needs a state switch
The update function needs a state switch
Each of these would need different results for each state. I just found it to be kinda messy, and hard to add new states. Could I make a new function for each state? like for KeyInputIntro(), KeyInputGame(), etc.

The codeproject article is a bit odd. It seems like it would encourage duplication between the various states. In reality, game states have a lot in common at the code level, and the different states listed here are better represented at a data level. The actual states are more closely defined by the concrete objects that are active, and the event listeners and scripts.

It's a pretty little pattern for toy projects, but I don't think it will scale very well.

The Nebula Device uses this pattern, so you can check that out for an implementation (here, specifically the "App" and "StateHandler" classes).

Seems like a decent design to me. Shared code can stay in your main loop (in Nebula/Mangalore's case the "App" class), while differing code can move out into the state handler.