State machine - requesting advice

[Darkhog]

You know what that is a great idea. Infact that is a genious idea. I never thought about handling the game states this way.
I can see many benefits that such approach could have in comparison to most oftenly used approach where you simply have one gloval variable teling your software in which state it is and then you use case statment to determine which part of the code should execute.
Main benefit would be the ability to have seperate initialization and finalization code for each state. Theese are being caled on creation or destruction of each state.
You can also easily make each state to actually have its own substates which could also be verry handy.
Also the same way as you are handling state specific drawing you could also handle state specific input handling. And all that by simply changing one variable.

Thanks! I didn't know you're flattener . Also for this:

Also the same way as you are handling state specific drawing you could also handle state specific input handling

I think it can be done by private function in specific child class which would be called from withing TState.update. Control doesn't have be any more precise than frame rate, anyways.

I also want to thank User137 for thing with pointers. Since I don't particularly like them thanks to you I'd be able to avoid them.

For switch-case thing... Well I've considered it, but I want to produce clean code. What if I'd like later on add yet another state? Then whatever function would have those switch-cases would get long (like hundreds lines of code long) and to get to actual state code (since e.g. you wanted to change something in behavior in a game state) you'd need to scroll through it. With my approach, every state can live in its own file and would be easy to modify.

I don't just want to make a game. I want to make maintainable game.