State machine pattern in game architecture

[dudel]

Hello guys,
I want to implement a basic game by using the state machine pattern. It should contain at least the following states: running, paused and stopped.

Perhaps more states could make sense, but I don't know which behaviors should be modeled as single states. Example: While the game is running, the user clicks on the settings panel to change some settings. Do I need a new state here or would the game just switch to the "paused" state? Would it be a better idea to disable the settings panel while the game is running? Can every GUI view be seen as a new state or would that be overkill?

I am not sure if a concrete state should better be a subclass of an abstract state class or implement a state interface. It could also be interesting to save the game state persistently in a file so that the game can be resumed after rebooting the machine, but I don't know how complicated this is and if there is some kind of helper API out there.

[copeg]

This thread has been cross posted here:

http://www.java-forums.org/java-gaming/71378-state-machine-pattern-games.html

Although cross posting is allowed, for everyone's benefit, please read:

Java Programming Forums Cross Posting Rules

The Problems With Cross Posting

[dudel]

Ok, I understand those arguments against cross posting, but the problem here is that this topic doesn't demand simple and definite answers, but instead some opinions. Anyway, I want to apologise for my misbehavior.