Automatically deleting specific persistent variable data
Currently, the player can reset all data. And the creator can "reset" a persistent variable (which as far as I know just sets it to the initial value?)... but for larger, long-term projects (eg. Trip's Voyage) it would be much more useful to be able to automatically delete specific old variables from a player's storage to make room for new ones that are actually used by the current version of the game.
Perhaps a delete switch on variables could do this. Then the creator could add keep the old variable around, and simply mark it as "delete." This would mean keeping that variable gadget around, using a little thermo, in exchange for making sure the game is stable and won't bug out when more variables are stored. So it's up to the creator from there.
-
Of your two suggestions for managing situations where the persistent variable limit is exceeded, I prefer this one. The creators choice of variable to delete is always going to be more accurate than simply choosing the one that hasn't been written for longest.
To give creators even more control over this, perhaps the Variable gadget could also have a "Loaded" output that would emit a pulse at the start of the scene if and only if there was a saved value to load. This would allow creators to manage situations where for example, there are three versions of a game with different formats for saved data in the variables, and migrating data to version 3 requires different logic depending on whether the current version is version 1 or version 2.
And if the creator puts all of this logic in a scene that doesn't do anything else and sends players on a detour to that scene when resuming the game, the extra thermo used won't be a problem. This would work something like this:
- Player resumes game and the last scene they were in loads.
- "Version Check Needed" variable doesn't load a value.
- Absence of "loaded" pulse from "Version Check Needed" variable triggers logic that sends player to "Version Check" scene.
- "Version Check" scene loads.
- "Version Check" scene migrates data if needed.
- "Version Check" scene writes a persistent value to "Version Check Needed" variable.
- "Version Check" scene sends player back to scene they came from.
- This time, that scene's "Version Check Needed" variable does load a value.
- Detour to "Version Check" scene logic doesn't get triggered.
- Scene uses "delete" input of "Version Check Needed" variable to delete its value, because we want to do all of this again if the player exits the dream.
- At the next regular scene transition, the value of the "Version Check Needed" variable is written to the save file.
- The next scene finds that value, and doesn't repeat all of the version check detour logic - which we don't need to do in this case, because the player didn't reach the start of the scene by quitting and resuming later.
-
Yes, I'd say this is ideal. But would take UI work and testing, so more work for Mm.
Also the bonus of the other method is that it automatically works for all dreams, and retroactively fixes problems with old dreams as well. No work on the part of the creator, and it would fix a load of problems immediately.
Of course, I'd like both.
-
Regarding handling "version clashes" for the variables... I'd recommend creators simply store a version persistent variable. Then if they detect it's too old, they can trigger logic to sort things out, before updating the version variable to the latest version. Something like that.
So then, all of the logic you detailed would be doable without a new feature being required from Mm. (If I understood your outline properly at least.)
Iniciar sesión para dejar un comentario.