For my game projects in Unity I have been using coroutines quite a bit instead of the normal types of state machines.
It's a lot easier to read and write, BUT it comes with the downside that its not easy to save or load, which makes it only usable in certain game types and/or actions.
I'd venture that since part of the state is stored in the coroutine stack, and that you cannot extract it automatically it's hard to have a save feature that doesn't miss any thing. Eg loading a saved game won't have the exact same outcome as original play.
That's my take too. You'd have to preserve the entire execution state at that moment in time, including the coroutine scheduler. That's probably easier with some virtual execution model (VM) instead of native threads, stacks, etc.
The whole mess also has to be deterministic too, or as you say, it won't have the same outcome across save/load.
Exactly. Usually in the most basic enum/int state machine you can just save the step and all related data to save and load.
With a coroutine the data can be made global to be saved, but there's usually no flag to indicate what step we're on. On a load the data can be used but its really hard to get back to the exact step in the coroutine stack without building in a lot of conditional logic, which then voids using it in the first place.
Comments
For my game projects in Unity I have been using coroutines quite a bit instead of the normal types of state machines.
It's a lot easier to read and write, BUT it comes with the downside that its not easy to save or load, which makes it only usable in certain game types and/or actions.
Can you expand a bit on that?
I'd venture that since part of the state is stored in the coroutine stack, and that you cannot extract it automatically it's hard to have a save feature that doesn't miss any thing. Eg loading a saved game won't have the exact same outcome as original play.
That's my take too. You'd have to preserve the entire execution state at that moment in time, including the coroutine scheduler. That's probably easier with some virtual execution model (VM) instead of native threads, stacks, etc.
The whole mess also has to be deterministic too, or as you say, it won't have the same outcome across save/load.
Exactly. Usually in the most basic enum/int state machine you can just save the step and all related data to save and load.
With a coroutine the data can be made global to be saved, but there's usually no flag to indicate what step we're on. On a load the data can be used but its really hard to get back to the exact step in the coroutine stack without building in a lot of conditional logic, which then voids using it in the first place.