使用 SaveGame 创建永久名单
为什么存储数据和FGuid而不是Actor
该博客上撰写的文章是出于教学目的而创建的。 另外,文章中的信息可能不正确,请谨慎。
将战斗 Actor 本身放入 SaveGame 并不意味着相同的角色会在下一次运行中返回。 由于Actor当前是世界上的一个对象,因此必须将其转换为可以存储的纯数据。
在 ProjectTB 中,名册角色FTBRosterUnitData将其存储为
USTRUCT(BlueprintType)
struct FTBRosterUnitData
{
GENERATED_BODY()
UPROPERTY()
FGuid UnitInstanceId;
UPROPERTY()
ETBUnitClass UnitClass;
UPROPERTY()
int32 Level = 1;
UPROPERTY()
int32 Experience = 0;
UPROPERTY()
TArray<FName> AcquiredTraitIds;
};
区分类和实例
即使剑士职业相同,每个角色的等级、装备、特性也不同。 FGuid使用 ,即使排列顺序发生变化,您也可以再次查找特定字符。
UnitClass:它是什么类型的单元?
UnitInstanceId:这个角色是谁?
当战斗开始时,使用保存数据生成一个 Actor,当战斗结束时,幸存 Actor 的状态会反映回名册数据中。
永久死亡立即拯救
在 ProjectTB 中,当盟友死亡时,他们会从名册和选择列表中删除并立即保存。 这是因为如果你只在战斗结束时保存,死亡可以通过强制退出来逆转。
相反,如果保存点太多,磁盘访问就会变得频繁。 确定重要的状态变化点并CaptureSaveGame()在路径中创建保存数据可以减少遗漏。
SaveGame 设计的关键不是按原样保存对象。 再次配置游戏所需的最少数据以稳定的 ID 存储。