Different "types" of saving in the same game
Posted: Mon Sep 27, 2021 10:51 am
In my game, there is a time system which is based on distinct "days". Each day, the game saves all relevant objects, and the player can reload them to the exact state for that day using a calendar UI. However, after reloading a day, I don't want the player to be able to load a day after that one-- later slots should be effectively inaccessible or deleted, and the player has to play out the intervening days.
I'm using SaveSystem.SaveToSlot() and SaveSystem.LoadToSlot() for this, which the slot being the index of the day in question. Currently, this is working correctly, but I realized that some of the other use cases I'm planning will require different strategies.
For example, in addition to reloading a day once the game is already started, the player can load their saved game from the title screen. They only get one save of this kind, so there is no need to manage separate "slots" in the usual sense. However, I need a way to keep track of the most recently saved day when exiting and restarting the game. I have two possible strategies in mind:
The simplest is to use some other type of saving, like PlayerPrefs, JSON serialisation, or some method from the PixelCrushers plugin other that SaveToSlot(). This would allow me to always check the correct slot index at the start of the game and update it when the day advances or the player reloads an earlier day. One problem with this is that I'm planning to save other types of data this way in the future, such as persistent quest data that isn't altered by changing days. I imagine I would handle this with PixelCrushers savers, so I would likely end up using the same SaveSystem methods I use for calendar saves. I could solve this by always saving this data to the relevant day slot when reloading from save or saving at the end of a day, which I imagine would just mean not unloading any of this data like I do with things that are undone by reloading days.
My other strategy is similar, but involves making a special slot 0 save that doesn't include day-specific data, only data that persists across saves. I'm leaning against this idea, since it seems like having completely separate sets of data to save attached to separate savers might not be compatible with how SaveSystemMethods works.
Any recommendations for how I should handle this use case? I'm leaning most towards the JSON serialisation option combined with using the day-specific slots for PixelCrushers savers, but I'm curious if others have had similar cases with cleaner solutions.
I'm using SaveSystem.SaveToSlot() and SaveSystem.LoadToSlot() for this, which the slot being the index of the day in question. Currently, this is working correctly, but I realized that some of the other use cases I'm planning will require different strategies.
For example, in addition to reloading a day once the game is already started, the player can load their saved game from the title screen. They only get one save of this kind, so there is no need to manage separate "slots" in the usual sense. However, I need a way to keep track of the most recently saved day when exiting and restarting the game. I have two possible strategies in mind:
The simplest is to use some other type of saving, like PlayerPrefs, JSON serialisation, or some method from the PixelCrushers plugin other that SaveToSlot(). This would allow me to always check the correct slot index at the start of the game and update it when the day advances or the player reloads an earlier day. One problem with this is that I'm planning to save other types of data this way in the future, such as persistent quest data that isn't altered by changing days. I imagine I would handle this with PixelCrushers savers, so I would likely end up using the same SaveSystem methods I use for calendar saves. I could solve this by always saving this data to the relevant day slot when reloading from save or saving at the end of a day, which I imagine would just mean not unloading any of this data like I do with things that are undone by reloading days.
My other strategy is similar, but involves making a special slot 0 save that doesn't include day-specific data, only data that persists across saves. I'm leaning against this idea, since it seems like having completely separate sets of data to save attached to separate savers might not be compatible with how SaveSystemMethods works.
Any recommendations for how I should handle this use case? I'm leaning most towards the JSON serialisation option combined with using the day-specific slots for PixelCrushers savers, but I'm curious if others have had similar cases with cleaner solutions.