Create a permanent roster with SaveGame

The articles written on this blog were created with the goal of teaching. Also, the information in the article may be incorrect, so please be careful.

Putting the combat Actor itself into SaveGame does not mean that the same character will return in the next run. Since the Actor is currently an object in the world, it must be converted to pure data that can be stored.

In ProjectTB, roster charactersFTBRosterUnitDataStore it as

USTRUCT(BlueprintType)
struct FTBRosterUnitData
{
    GENERATED_BODY()

    UPROPERTY()
    FGuid UnitInstanceId;

    UPROPERTY()
    ETBUnitClass UnitClass;

    UPROPERTY()
    int32 Level = 1;

    UPROPERTY()
    int32 Experience = 0;

    UPROPERTY()
    TArray<FName> AcquiredTraitIds;
};

Distinguish between classes and instances

Even if the swordsman class is the same, each character's level, equipment, and characteristics are different. FGuidUsing , you can find a specific character again even if the arrangement order changes.

UnitClass: What type of unit is it?
UnitInstanceId: Who is this character?

When a battle begins, an Actor is spawned using save data, and when the battle ends, the status of the surviving Actor is reflected back into the roster data.

Permanent Death Saves Instantly

In ProjectTB, when an ally dies, they are removed from the roster and selection list and saved immediately. This is because if you save only at the end of the battle, death can be reversed by force quitting.

Conversely, if there are too many save points, disk access becomes frequent. Determine important state change points andCaptureSaveGame()Creating save data in the path reduces omissions.

The key to SaveGame's design is not to save the object as is. The minimum data required to configure the game again is stored with a stable ID.