SaveGameで永久ロースターを作る
Actorの代わりにデータとFGuidを保存する理由
本ブログ作成文は、講義を目指して製作されました。 また、作成された文章の情報も間違っている可能性がありますので、ご注意ください。
戦闘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をSpawnし、戦闘終了後にサバイバルActorの状態を再びロースターデータに反映する。
永久死はすぐに救う
ProjectTBでは味方が死んだらロスターと選択リストから削除し、すぐに保存する。 戦闘終了時のみ保存すれば強制終了で死亡を戻すことができるからだ。
逆に、保存時間が多すぎるとディスクアクセスが頻繁になります。 重要な状態変更点を決めて、一つCaptureSaveGame()パスから保存データを作成するほうが欠落を減らします。
SaveGame設計の鍵は、オブジェクトをそのまま保存することではありません。 再びゲームを構成するのに必要な最小データを安定したIDで保存することです。