[Project Talisman] #4. Status 시스템 개선하기

---

Project Talisman의 개발 일지를 간만에 작성한다. 그동안 여러 사정이 겹치면서 작업을 거의 안하게 되었어서 작성할 내용이 없었다. 하지만, 언제까지 가만히 쉬고만 있을 수 없기 때문에 근래들어서 작업과 공부를 다시 하고 있다.

 

기존에 사용하고 있던 Status 시스템은 이전 대학교 프로젝트에서 지인이 작성한 시스템을 참고해서 만들었다. 하지만, 이번에는 내 방법대로 변경해보고자 한다.

---

Project Talisman에서의 Unit 오브젝트

게임에는 Unit으로 치부되는 오브젝트가 있다. 플레이어 캐릭터나 혹은 적과 같은 오브젝트들이다. 이들을 한 Group으로 묶기 위해서 Unit 스크립트를 작성하고 내부에는 Status와 Battle에 관련된 처리를 진행한다. 또, 이 스크립트가 붙은 오브젝트는 Unit임을 명시해준다.

 

그렇게 되면, Project Talisman에서 Unit 오브젝트는 FSM을 담당하는 Controller 스크립트와 Unit을 명시해주는 Unit 스크립트를 가지게 된다.

 

Controller와 Unit 스크립트를 묶으면 어떨까 생각을 했었는데, Unit은 FSM을 가지지 않을 수 있기 때문에 묶지 않기로 결정했다. 그래도, 계층을 구분하면 Controller에서 Unit을 가지고 있기 때문에 Controller가 한 계층 높은 스크립트가 된다.

 

Unit 스크립트는 앞서 말한대로 Status를 관리하고 있는데, 오늘 다룰 것이 Status를 담당하는 UnitStatus다.

 

---

UnitStatus? Status 시스템은 어떻게 사용이 되는가?

많은 게임에서 Status는 필수적으로 사용된다. 플레이어 캐릭터의 움직이는 속도, 공격 데미지, HP, MP, 등을 관리해야 하기 때문이다. 나는 프로젝트에서 2022년도부터 Status를 효과적으로 관리하기 위해서 별도 시스템을 사용하고 있다.

앞선 프로젝트에서 사용된 Status 시스템

위 사진은 2023년 대학교 졸업 프로젝트에서 사용한 Status 시스템 이미지를 가져왔다. Status 시스템은 List<> 타입을 통해서 관리된다. Dictionary<> 타입을 사용하지 않은 이유는 Key를 통해서 쉽게 값에 접근할 수 있지만, Unity에서 Serialize를 제공하고 있지 않아서 따로 SerializeDictionary 타입을 만들어야 한다.

 

실제로 구현을 하기 위해서 인터넷 서칭을 하면서 SerializeDictionary 타입을 구현했으나, 생각한 것 처럼 나타나지 않아서 그냥 List<> 타입을 통해서 개발했다.

 

Status를 한 공간에서 관리하게 된다면, 객체 수정에서 Status 시스템을 공략하면 되는 일이고 위와 같이 Inspector에 노출된 값은 기획자들이 밸런싱에서 간편하게 값을 수정하고 변경할 수 있는 이점이 있다.

 

그렇기 때문에 이번에 진행하는 Project Talisman에서도 동일한 시스템을 추가 했으나, Dictionary 타입으로 수정하면서 변경된 사항에 따라서 개선을 진행했다.

 

---

Status 시스템의 구조

UML을 작성하는 것은 귀찮은 일이다... 그래서 작성하지 않았다. (위 사진은 UML 아님!)

UnitStatus는 위 사진과 같이 Status에 관련된 스크립트의 Root 스크립트다. 내부에 StatusData, StatusDictionary를 가진다. StatusData는 ScriptableObject 타입을 상속하고 있으며, 내부에 Status 데이터가 담긴 Dictionary, StatusDictionary 타입의 인스턴스를 보유하고 있다.

 

StatusDictionary는 여러 StatusElement 타입들의 집합체다.

Notion에 정리한 Status 시스템 일부

Notion에 생각을 정리하고 각 스크립트에 대한 역할과 위치를 분배했다. 단순한 편이라 자세한 제작 과정을 담진 않을 예정이다.

 

---

UnitStatus 완성!

Odin과 함께한 Status 시스템

완전히 완성되었다고 할 수 없겠지만, 위 사진과 같은 작업물을 만들 수 있었다. Key를 통해서 추가할 수 있으므로, 해당 Unit에 맞는 Status만 선택해서 추가할 수 있다. 앞으로 float 타입으로 관리되는 Status는 UnitStatus를 통해서 처리된다.

 

---

앞으로 남은 문제점

*는 무엇을 의미하는걸까..

Odin Serialize의 숙련도가 적어서 왜 이렇게 나타나는지 잘 모르겠다... 실수로 빨간색 테두리로 되어있는 위치를 누르고 StatusElement 타입을 누르면, StatusValue가 초기화된다. 일단 나타나는 생각으로는 StatusElement 인스턴스가 변경되기 때문에 나타나는 것 같은데, 이를 확인하기 위해서 프로파일러에 대해서 자세히 알아봐야 할 것 같다.