We've reviewed code via Mumble and git.
WillLem had the factoring practically right even before I looked at it. There were already no bugs with the rewind-or-restart message.
We found and fixed the overshooting. The overshooting came from leftover caching information from end-of-game considerations at the start of each physics update. Such end-of-game tests must either happen at the end of a physics update, or outside the physics update. We still have to reconcile the nuke with this; the nuke shall ignore the unplayable state and continue into nuking zombies, then exit. Because of this, we'd rather not tie these decisions to the physics update -- after all, activating the nuke to continue is UI, not physics, and only then it adds the nuke entry to the replay and nuke in the physics.
NL's 2023 architecture tied the exiting to the start of a new physics update. In light of our feature -- stop updating, but don't exit on losing all lemmings -- it looks necessary to change the exiting architecture in
some way; still, we should review it with namida on a high level. For now, we renamed
CheckForGameFinished to
MaybeExitToPostview, to distinguish it clearly from the new end-of-game behaviors that don't exit, and moved it out of the physics update, into the window's main loop, as a public method call to LemGame.
WillLem has tested the interactive game and found no problems with the moved exit-to-postview decision. We haven't yet tested mass replay verification, we'll still have to do that. Likely, it will work because the verification carries its own exiting logic.
Thus, to do:
- Reconcile nuke-to-exit with the moved exiting logic.
- Test mass replay verification. Most likely, it's fine.
- Test other ways to exit LemGame, e.g., pressing Esc, Hyper Speed into death/win.
- Fix my observed mismatch between default option and game exiting.
- Stream more playtesting!
- Review the high-level achitecture of the feature with namida.
-- Simon