[Tyr42]

You might queue up events which cause it to transition to another state. If you hit the hibernate button, it might finish rendering the current frame before checking to see if the button was pressed, then hibernate. So it's the same state machine just with a larger input space.

[ones_and_zeros]

Sure but how does that work with the provided implementation where all states can only transition to a single state, this is ensured at compile time. What does the code look like that allows a state to transition to one of several other states?

[skrtskrt]

No Rust, but here's a Python implementation that I have built on top of before: https://github.com/pytransitions/transitions

You add the concept of finite "triggers", where [state i] + [trigger result j] always takes you to [new state](which could be the same state if you want)

Triggers are just functions where anything could be happening - coin flip, API call, but they return one of an enumerated set of results so the machine can always use their result to go to another state.

[ones_and_zeros]

Ah ok. I don't write Rust either but maybe it'd look like:

  impl State<Running> {
    pub fn next(self, Trigger<Hibernate>) -> State<Hibernate> {
        State { _inner: Hibernate {} }
    }

    pub fn next(self, Trigger<Terminate>) -> State<Terminate> {
        State { _inner: Terminate {} }
    }
  }

[imtringued]

Usually you would just call your functions hibernate() and terminate(). That way you can call hibernate() on State<Running> but not on State<Terminated> or State<Hibernate>.