스컬 모작 프로젝트 @2 도메인 시스템 개발 과정중 GPT와의 설계 논의

원래 목표는 플레이어블 캐릭터 구현이었다.
하지만 스컬 특유의 “폼 변환 + 아이템 다중 조합” 구조를 건드리다 보니 예상보다 빠르게 아이템 시스템이 필요해졌다.

문제는 아이템만 추가하면 되는 줄 알았는데,
막상 스폰·풀링·리소스 로딩·런타임 데이터 구조까지 전부 관여하게 되면서
아이템 시스템이 게임 전체 도메인 규칙을 흔드는 구조적 문제로 발전했다는 점이었다.

이 때문에 단순한 스크립트 추가가 아니라,
오브젝트의 공통 규약 자체를 정립하는 작업이 먼저 필요해졌다.

아래는 그 과정을 정리한 대화 요약이다.

---

1. 아이템 = 데이터가 아니라 View라는 점을 인지

Unity GameObject 기반 Item 클래스는
사실 “실제 아이템 데이터”를 담는 객체가 아니다.

GameObject는 다음 역할만 수행한다.

• 스프라이트 표시
• Transform 업데이트
• 풀링과 애니메이션 처리

즉, GameObject = View(표현 오브젝트)
실제 아이템 상태(위치, 효과, 활성 등)는
DOD 기반 런타임 테이블에서 관리되는 논리 데이터여야 한다.

이걸 인지하면서 기존의 아이템 구조는 ViewObject로 재정의되었다.

---

2. 모든 오브젝트에 적용할 통합 식별자(ObjectKey) 설계

아이템만 식별할 키를 만들려다 보니
결국 몬스터, 투사체, 오브젝트 등
게임 내 모든 엔티티가 통일된 규칙을 가져야 한다는 결론에 도달했다.

그래서 **4바이트(32bit), 8자리 16진수 기반의 공통 키(ObjectKey)**를 정의했다.

구조는 다음과 같다.

 

[8bit Domain][8bit Type][8bit Class][8bit Index] DD TT CC II

• Domain: Item / Monster / Projectile / WorldObject …
• Type: 세부 타입 (예: 잡몹/엘리트, 무기/방어구 등)
• Class: 속성/등급/지역
• Index: 세부 번호

이 키 하나로 정의 데이터 전체를 통일할 수 있다.

---

3. 풀러(PoolManager)는 뷰(View)만 관리하는 로컬 시스템

오브젝트 삭제/생성은 게임플레이에 영향을 주는 중요한 결정이므로
원칙적으론 “서버 권위”가 맞다.

하지만 Unity에서의 풀은
실제로는 **클라이언트 렌더링 최적화(뷰 관리)**만 한다.

즉,

• 서버/논리는 “어떤 오브젝트를 스폰할지”를 결정
• 클라이언트의 PoolManager는 “그걸 화면에 어떻게 표현할지(View Object 재사용)”만 담당

이 구조가 앞으로 이어질 DOD/RuntimeWorld 설계와 완전히 일치한다.

---

4. 뷰(View)와 논리(Runtime)를 완전 분리하는 구조로 재정립

최종적으로 다음 결론이 잡혔다.

✔ Runtime(Entity)

• 위치 / HP / 활성 상태 등 실제 게임 데이터
• DOD 배열로 관리
• 키: uint objectKey

✔ ViewObject(GameObject)

• Runtime 데이터를 화면에 표현
• 스프라이트 / 애니메이션 / Transform만 담당
• 풀러(PoolManager)로 수명 관리
• 이름도 Item → ItemView로 변경

이 구조는
스컬의 “수많은 아이템 + 다단 변형 + 빠른 스폰”을
Unity GameObject만으로는 감당할 수 없기 때문에
장기적으로 가장 안정적인 형태다.

---

5. 현실적인 점진적 리팩토링 방향

전체를 한 번에 갈아엎는 것은 위험하다.
그래서 다음의 단계적 접근을 채택했다.

1. ObjectKey만 먼저 도입 (기존 itemId 유지)
2. Item에 objectKey 필드만 추가 (아직 완전 사용 X)
3. 새로 만드는 시스템(Spawner, 풀링 구조)은 objectKey 기준으로 제작
4. 기존 itemId 기반 로직은 천천히 치환
5. 마지막에 ViewObject/RuntimeWorld 구조를 완성

이렇게 진행하면 큰 충격 없이
새 시스템을 자연스럽게 적용할 수 있다.

---

📌 최종 요약

• 아이템을 구현하려다 시스템 전체의 규칙을 재정립하게 되었음
• GameObject 아이템은 “데이터”가 아니라 “뷰(View)”임을 인식
• 모든 오브젝트의 공통 식별자(ObjectKey)를 32bit·Hex8 규칙으로 통일
• 풀러는 뷰 관리, RuntimeWorld는 논리 관리로 역할 분리
• 구조적 부담을 줄이기 위해 단계별 점진적 리팩토링 계획 수립

 

마지막으로 멋진 해원짤이나 보고가세요