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.
Different "types" of saving in the same game
-
- Posts: 27
- Joined: Mon Sep 13, 2021 6:55 pm
Re: Different "types" of saving in the same game
Hi,
All of the info is already available in the save system, so no need for a separate JSON subsystem.
When the player loads a day's save slot, I recommend deleting all of the later slots. Example:
From the title menu, you can load the highest slot that's available. Example:
All of the info is already available in the save system, so no need for a separate JSON subsystem.
When the player loads a day's save slot, I recommend deleting all of the later slots. Example:
Code: Select all
int day = 3; // Player wants to load day 3.
SaveSystem.LoadFromSlot(day);
// Delete later days:
for (int i = (day + 1); i < 100; i++) // (I arbitrarily assumed max 100 days here.)
{
if (SaveSystem.HasSavedGameInSlot(i)) SaveSystem.DeleteSavedGameInSlot(i);
}
From the title menu, you can load the highest slot that's available. Example:
Code: Select all
for (int i = 100; i >= 0; i--) // Count down from highest slot number.
{
if (SaveSystem.HasSavedGameInSlot(i))
{
SaveSystem.LoadFromSlot(i);
break;
}
}
-
- Posts: 27
- Joined: Mon Sep 13, 2021 6:55 pm
Re: Different "types" of saving in the same game
Thanks! That turned out to be quite an elegant solution, as the date the player should load was the only thing currently in my game that I thought I'd need a separate system to save.
Re: Different "types" of saving in the same game
Glad to help!