I am adding a Save/Load game feature to my game, that will save the players score/time/health/position at the time they pass through a checkpoint.
My query or concern is about any previous items that player may have already collected.
If these weren’t registered at the point of the save/load state, does this effectively mean everything else in the world will remain, even if at the point of saving those items had already been collected?
The items I am referring to are:
Actors that are destroyed once passed through eg. adding to the score.
Health Pickups.
A couple of game items needed for the player progression.
Before I got too far ahead on creating this blueprint I wanted to query this.
Is there a feature or record within the blueprint that can read the current level state and recall if any actors have been destroyed/collected?
I want to make sure that all items/actors previous collected or destroyed, are also remembered at the point of save/load.
After loading the level - it will be as you made it in the editor. Everything you did during the game - is not initially taken into account.
Your save system should keep track of what world items are in your inventory and remove them from the level after loading if they are collected to prevent them from being cloned.
No, all that is there initially in blueprint is a “Save Game” flag for variables (which initially has no effect on anything).
With it you mark which variables need to be serialized, then you add this data to the save file.
This is described here in maximum detail.
I have probably 18 pickups or so, along with 15 score actors that are destroyed on collision.
Ideally, I’d like the system to remember which actors/objects have been destroyed, so that when the player reaches a checkpoint, that information is remembered, preventing duplicate items from reappearing on load.
If you make a generic pickup parent, that knows how to save itself ( and destroy itself on next play if need be ), then your other pickups can derive from that class.
It sounds like a lot of work, but to be honest, using the save flag and serialization ( as outlined by @PREDALIEN ) sounds worse
Unfortunately you are right, but the “Save Game” flag was definitely a good solution (but not fully implemented).
“My” solution is revealed after you want to save the item after you dropped it in the level in a new place.
Thanks to serialization, you will load ALL (the ones you need) its parameters by calling one universal function, without thinking about the fact that the classes of objects are different.
But this is only PART of the save system. The part that monitors whether the level object has been collected is not directly related to serialization.
In the save file, you need to store the path of the object that we have collected. For actors that are initially on the level, this is a reliable identifier that does not change when the level is reloaded.
After loading the level, you need to check which of the collected items are on the level (ActorSoftObjectReference->Resolve->IsValid) and remove them from the level.
With dynamic objects, things are more complicated.
It is necessary to create your own system of reliable identifiers that will be assigned to unique spawning objects in a particular case.
The standard Unreal ID system cannot provide this.
Upon implementing my save/load feature, the system automatically remembered which actors were destroyed at the point the game was saved, such as a few actors that affect the score mechanic!
