I have a save game methodology I created when I was doing stuff in Unity that I want to carry over to Unreal, but I don’t see how I can do it with a single save game object going into a single save game slot. I’m wondering if I have to just forego that and do File I/O more directly.
I intend to revisit/backtrack for levels and want to persist some state for them. In my old model, when the player left a level for a new one, that level’s state would be saved into a temporary file under a cache serving like an autosave. When I wanted to actually save the game, the current level would also get saved, along with a mapping for all the levels, and finally whatever global stuff was necessary. This and the current cache would then get saved to a directory under the save folder. So each save was a folder containing basically the cache with enough information on how to reconnect it and restart the game.
Something important here is I never had to have all the save data loaded into memory at a single time. I don’t have a good handle on how fat this could even get, but I wanted to see if I can just avoid finding out if it’ll ever become a problem if there is something in UE5 I can use to not have to put all this into a single save game object.
I intend to have multiple saves, so I’d rather not just start vomiting each save-specific level into unique slots that I’d then have to scan and process. I can’t be the only one that thinks that might be janky. It sounds to me like I’d have to forego the built-in stuff for save game slots and lean on the File IO. Like, I dunno, FPlatformFileManager (I know using the standard library is generally just bad and liable to nail me if I ever targeted more than PC). I’m not sure specifically what I should use there, but File I/O is something I can nibble on my own.