Core Reboot:Four Seasons - #1 스테이터스 관리용 데이터 유형 결정 (Data Table vs. Data Asset)

Data Table

엑셀처럼 Row&Column 형식으로 데이터를 관리하는 방식

장점

• 대량의 데이터를 통합 관리하기 용이 → 일괄 수정 용이
• csv, json 파일을 외부에서 만들어 엔진에 임포트하여 사용 가능 → 엑셀과 같은 외부 프로그램으로 작성 가능
• 구조체 기반(FTableRowBase)  → 오버헤드가 거의 없음 →  순수 데이터 필드 크기만큼 저장 → 메모리 사용량이 적음
• 데이터를 직렬화된 형태로 저장
  ex) TArray<uint8> 
• 에디터에서 수정 가능

단점

• 런타임 수정 불가 
• 데이터 간 연결 구조 만들기 어려움 →  복잡한 데이터 구조 관리 어려움
• 데이터가 복잡해지면 csv보다 json을 직접 작성해야 함
• Hard Reference 가능 → But, 데이터 테이블은 로드 시점에 모든 참조 에셋이 메모리에 적재 → 데이터를 개별적으로 로드, 언로드 불가 → 메모리 사용량 조절이 유연하지 못함 → Soft Reference 권장

요약

• 대량의 정적 데이터를 효율적으로 관리 가능
• But, 동적 처리나 복잡한 참조 구조는 제한적

Data Asset

객체 단위로 데이터를 관리하는 방식

장점

• 런타임 수정 가능
• 객체 지향적 설계 가능(클래스 기반) → 상속, 인터페이스 활용 가능
• 강력한 모듈화 → 데이터와 로직을 묶어서 사용 가능
  ex) 무기 데이터 + 발사 방식 함수
• Primary Data Asset 및 에셋 매니저 사용하면 Hard Reference 사용해도 에셋 단위로 개별적 수동 로드 및 즉시 언로드 가능
  → 메모리 사용량 조절 가능
• 에디터에서 수정 가능

단점

• 대량의 데이터 관리 어려움
• 일괄 수정 어려움
• UObject 기반의 클래스로 오버헤드 발생 ㅡ> 메모리 사용량이 데이터 테이블의 Row 한개와 비교했을 때, 훨씬 큼
  ㅡ> UObject의 경우 가비지 컬렉션용 포인터, 리플렉션 테이블과 같은 런타임 오버헤드가 발생 

요약

• 런타임 동적 처리에 유연하고 객체지향 설계에 적합
• But, 대규모 데이터 관리에는 부적절

대표적 사용처

Data Table

• 다이얼로그, 퀘스트 시스템
• 언어팩
• 세팅
• 레벨 및 진행 시스템

Data Asset

• 단일 정보
  ex) Enemy A, Enemy B, Enemy C, etc.
• 작은 그룹의 정보
  ex) Enemies[], Weapons[], Potions[], Items[], etc.

결정

• 현재 관리할 데이터는 캐릭터와 플레이어블 로봇의 스테이터스 관련 변수들
  ex) 배고픔, HP, 에너지 등
• 게임에서 캐릭터, 로봇은 종류가 많지 않음 (캐릭 1개, 로봇도 많지 않음)
  → 모두 같은 데이터를 쓰는 형태
• 런타임에 수정되어야 하는 데이터
  ex) HP 및 배고픔 감소, 증가
• 대량의 데이터를 관리할 필요 없이 단일 데이터만 관리하면 되는 형태

→ 데이터 에셋을 사용하기로 결정

 

 

---

참고자료

https://www.youtube.com/shorts/AfA1PPtjv4w

https://dev.epicgames.com/documentation/ko-kr/unreal-engine/data-assets-in-unreal-engine

https://dong-grae.tistory.com/138

데이터 에셋과 데이터 테이블

https://blog.naver.com/PostView.naver?blogId=uss425&logNo=223208321236&parentCategoryNo=&categoryNo=112&viewDate=&isShowPopularPosts=true&from=search

[UE5] 데이터테이블 기반의 액터/에셋 관리 방법

https://dev.epicgames.com/community/learning/courses/19G/unreal-engine-c/jO8J/unreal-engine-vs