[FEATURE REQUEST] Improve the SaveGame System

[JohnMakesGames]

Dear Epic Games,

I was recently evaluating the SaveGame functionality, and was distraught to learn that the system only really supports simple value types like float, int32, and structs. It will not serialize UObjects or AActors themselves, only save references to them(Which of course do not exist when loaded back in). This makes it quite limited in what it can do, as games may have more complex data structures and it would be nice to simply save all that and have the engine automatically re-instantiate the necessary objects when loading.

There are several competing products on the Marketplace that do this, which while that's great and all, it really speaks for the need of such functionality in the base engine. I hope that you will consider improving the SaveGame functionality in the future.

Thank you,
Concerned Game Developer

[DamirH]

This is not entirely true. The documentation is scarce but you can tag UPROPERTIES as "SaveGame" and stuff them into a custom FArchive. Have a look at the responses here: https://answers.unrealengine.com/que...ml?sort=oldest

[TerrorMedia]

Even so this is hidden away and barely documented so we could still use some improvements to saving overall just to make it faster and easier. Basically just some quality of life improvements that make managing save data a lot easier and more straight forward especially for anyone new to this.

[Raildex_]

This is not entirely true. The documentation is scarce but you can tag UPROPERTIES as "SaveGame" and stuff them into a custom FArchive. Have a look at the responses here: https://answers.unrealengine.com/que...ml?sort=oldest

That applies to C++ only though. In BP you are restricted to "value" types only. The SaveGame Flag doesnt help either.

[DamirH]

That applies to C++ only though. In BP you are restricted to "value" types only. The SaveGame Flag doesnt help either.

True, and I firmly believ that Epic's biggest mistake was to advertise the engine as being able to handle a serious project with BP only, because it can't. You now run into issues like OP has, where it just isn't feasible to create an entire Blueprint-exposed generic UObject serialization for convenience, when it's a horrible decision for performance. In a way the lack of this option is a good thing because you WANT your save games to only have plain old data in them to minimize save and load times as well as the memory footprint of the file.

[BrUnO XaVIeR]

Saving/Loading Actor References is a very complex thing to do. Specially when they're spawned at runtime.

FArchive system can't support that either, I had to research for a long time how to build my own archive system and implement myself serialization of Actor/Components references into properties and array/set/map of properties.

Only after I dropped FArchive behind I was able to achieve that with my plugin and I don't know of any other save plugin capable of doing that so far...

If Epic'd do things the way you suggest, save files would be the same size of the levels you saved, and that's prohibitive since a level can be several gigabytes in size.

[JohnMakesGames]

Obviously, this would need to be done on an "opt in" basis, you get the choose what in the object gets saved. For saving something like a level, you may only need the transforms of non-static objects and whatever other custom data you put in there to represent it's state.For most games, saving of assets like textures or skeletal mesh assets would not make sense. I don't think such a save would end up being gigabytes in size. The more challenging part for Epic would be determining how the user decides what gets saved, from a user experience perspective.

For my particular use case I just need to serialize a UObject which has other UObject's and arrays of UObjects all cross-referencing each other. It sounds like I need to look more into this overriding the "<<" operator, but I do wish it "just worked" out of the box, and with Blueprint.

[BrUnO XaVIeR]

If you try to use the "<<" FArchive operator to save a copy of an UObject you will reach this hardcoded crash in the engine:

virtual FArchive& operator << ( class UObject*& Res ) override
{
    // Not supported through this archive
    check(0);

    return *this;
}

This is why I don't use FArchive anymore.

[JohnMakesGames]

Another way to improve the SaveGame functionality would be to have a "Get all slots" blueprint node. I believe you currently need to use c++ to look for the appropriate files. Some have suggested saving a master save slot which contains all of the save metadata for other slots, but this seems like a workaround and is not very portable(may not work well with cloud saves).

It would also be nice you could attach some metadata to the SaveGame such as game time, player progress, ect.. and be able to retrieve that without loading the entire save(which could be quite large).