Is it appropriate to nest Finite State Machines?

I'm looking to build a relatively in depth game for learning experiences. I'm taking a crack at building extensible state machines.

Now my game breakdown is roughly as you'd expect, Menus, world editor, game itself, etc...

Now when looking at my game design, would it make sense for each state, say World Editor, GamePlay, and Menu to contain their own FSMs? Or would it be more appropriate to have one FSM that encompasses all the states and uses transitions instead? I can see some things like a Load/Save function being transitions of bigger states (Say World Editor to Gameplay), but for others, it feels like it'd be absurdly clunky for the GameManager to contain all the states of all the various "main states".

Alternatively, would it make sense for one master UI/Audio FSM to encompass each individual state, or just have them reference more basic "controller" classes, like inputs, music playback and the like, as opposed to being embedded in the state machine?

 

The appropriate way would be to use simplest solution possible, removing features unless those are absolutely necessary. In your situation it means killing most of the state machine. See KISS principle and YAGNI on the web.

UI, in general, does not need separate state machines. Any menu and button has singular function when clicked, and it contains its own state. Once window's function is performed, usually window closes itself. There's no real reason to stick separate FMS in there. You're simply making it more complicated than necessary.

 

Nesting state machines is a great way to simplify things.

 

Combine what @BoredMormon said with what @neginfinity said

Perfectly fine to nest an FSM but only use them where they provide value.

Intuitively enough they are useful when there's a clear mapping between the problem and finite states (e.g. the state of a turn based game, Enemy AI) or when what happened before directly affects what happens next (e.g. parsing a simple grammar). They are particularly useful when one of the previous applies and there's a need to visualise the states/transitions.

 

Adding on to what the kthers said...

It's very easy to doodle some FSMs on a sheet of paper or two or three as needed. Try a few different iterations to expand being sure you are covering all of the cases. Then try a few iterations to clean and simplify.

What you end up with here is a good starting point that ideally won't need to be changed much during implementation. Don't worry about getting it perfect on paper. The important thing is just to spend a lite time say 10 to 15 minutes thinking about it and going through a few iterations improving the design before you being implementing.

 

I have a UI that is a big mess and portions of it depend on state of other portions of it and had I of created a series of state machines it would have made management and extension of the UI much easier as well as Inventory Management and Game progress management.

 

I agree with this statement. Sometimes creating software is like plugging a bunch of things into a power-strip. No matter how well you try to organize it, you get a tangled mess of wires. So keep simplicity in mind from the get go.

 

Just a warning on interacting state machines.

Be very careful so that you don't end up with a deadlock where one machine waits for another, that is waiting for the first one.
"Been there, done that"