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와 함께 저장하는 것이다.