MOHAWK: RIVEN: Autosave doesn’t test against game state at time of exit call.

[macca8]

This is a change from previous behaviour, caused by one of the changes in commit 40cb2f8 in resolving #11399, which affects the handling of autosaves when exiting during a cutscene.

Current Daily Build: 2.2.0git4606-g900b86ff7f (21 April 2020)
Game Version: English, 5-CD (contains v1.02 patch files)
Platform: Intel Mac (OS X 10.6.8, 10.11.6)

For the record, when exiting during a cutscene, the game state transitions from non-interactive (when the player makes the exit call) to interactive (after skipping to the next available fully-interactive frame), before exiting.

Confirmation of this can be observed by the disabled Save/Load buttons in the GMM, and the brief display of the next fully-interactive frame before the game exits. Cutscenes containing an embedded interactive element (Gehn visits) differ slightly in that they briefly pause the current frame, instead of displaying the next available frame, but still complete the transition to interactive before exit.

Understanding this exit behaviour makes predicting autosave-on-exit performance reliable, regardless of game state… if non-interactive, no save is performed, and if interactive, a save is performed (except where autosaving is disabled by default, such as the Start Menu).

The role of autosaving is to track the player’s progress. That progress stops when the player elects to exit the game, so autosaving should test against the prevailing game state when that call is made.

There’s also an expectation that if manual saving is disabled, then autosaving is also disabled.

Current autosave-on-exit behaviour confirms that the game completes its transition to an interactive state before it’s called. This behaviour should be corrected, since it skips gameplay not experienced by the player prior to the exit call.

Player’s expectations aside, for those dependent on autosaving, this unexpected overwrite can make some cutscenes inaccessible upon restart (for example, if interacting with Gehn).

Fortunately, this issue can be resolved by moving the saveAutosaveIfEnabled() method to where it can be called while the game is still in a non-interactive state.

We already know that, prior to the fix applied in #11399, Quit/RTL calls from keyboard & GMM (via Ctrl+F5) were handled correctly by saveAutosaveIfEnabled() when called from within the processInput() method, inside doFrame().

Now positioned outside the doFrame() method, saveAutosaveIfEnabled() is not called until after the game has transitioned to an interactive state, before exiting. As a result, canSaveAutosaveCurrently() returns true, instead of the expected false, prompting the unwanted autosave.

Would repositioning saveAutosaveIfEnabled() back inside the doFrame() method, but placing it immediately after processInput() and contained within an if hasGameEnded() statement - completing the autosave call before doFrame() continues, as was the case previously - possibly fix this issue?