undefined | Better HN

0 pointstuyiown2y ago0 comments

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.

0 comments

2 comments · 2 top-level

pragma_x2y ago

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.

animal5312y ago

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.

j / k navigate · click thread line to collapse