Please explain to me what these actually do, because obviously they don’t actually save or load the game, because you still have to get and set the variables manually (like player stats, inventory, opened doors etc.) in order to store and use them, and it doesn’t actually reset the current play session when you “load” the game, as far as i know you still have to reopen the map and manually set every single variable that has changed when the game was “saved”, otherwise the current play session continues running as if nothing happened.
So what’s the point of these nodes? And isn’t there a more efficient way of saving and loading besides manually getting and setting every single variable in the game one by one? What if i want to save a hundred different player stats or objects that have been moved/modified during a play session and load all of them in a new play session? Please help me understand, my brain is about to explode trying to grasp this concept.
If these nodes could magically know what you wanted to save, that would be amazing.
in the meantime, what they do is write ( and read ) the save game object to disk.
It’s up to you what you want to put in that object, there’s no way the system could know that. It might seem obvious to you, but it’s not.
If you want something that just writes everything in a massive lump to a huge file on the hard drive, there are plenty of plugins on the marketplace for that…
2 Likes
I try to avoid using too many marketplace assets at least for blueprints because i want to learn how to make my own stuff rather than copying, but i constantly run into roadblocks like this. But thanks for the suggestion.
Well, then you’re stuck with writing everything out I’m afraid… 
Having said that, once you know this is how it works, a lot of stuff then needs to be in the save game, can just be stored there rather than in the game instance etc.
Look into Blueprints equivalent of structs. A single struct variable can hold a LOT of user defined data - everything there is to know about the player, for example. Then you save / load just that one variable.
Conversely, everything there is to know about an enemy could be held in the Enemy struct, and if you need to save / load a whole bunch of those, you add them to an array - still only one variable to load / save. Unless you have arrays of arrays of arrays of… - which you will almost always have anyway 
There is some upfront work to be done, of course, and working with structs will be finicky - they’re fussy at times.
Operating on structs is often done with SetMembers node:
You expose what’s needed, modify it, and that particular float spends its life inside the struct rather than as a separate variable. And you can nest structs inside of structs (it does complicate iteration, though):
Technically speaking, you could save the entire game inside a single struct. But that’s not really feasible for anything beyond tiny in scope.
When it comes to displaying stats, widgets take advantage of structs:
Above, a widget’s text block fetches values from a nested struct. This would also work if you provided the widget with a reference to the player - this way you do not need to manually copy / update the struct. Blueprints copy enough data as is.
The native system is as straightforward as it is limited. That’s why such plugins exist:
4 Likes
And also, savegame objects are still blueprints, so you can add variables, functions, event dispatchers, etc. to them:
You can even use an event dispatcher to make all game objects put their data in the savegame object, then the savegame object saves itself. That way, you don’t have to manually save everything yourself.
3 Likes
Thank you all for the detailed explanations! I’ll look into those!
