Thread: State machine pattern in game architecture

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.

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.