[完] 인벤토리, 아이템 제작 요약

이번에 팀 프로젝트 동안 만든 것 중 인벤토리에 관한 것만 구조도로 따로 정리해보자. 정리하면서 아쉬웠던 점도 같이.

먼저 만들어낸 가장 기초적인 Item Slot이다.

 

슬롯의 정보 세팅, 변경과 마우스에 관련된 이벤트들이 있다.

아이템 슬롯을 드래그해 옮기는 것으로 드랍, 교체 등이 가능하고 정보를 확인할 수 있다.

이 Item Slot에서 파생되는 것으로는 CreateSlot, QuickSlot이 있다.

각자 ItemSlot에서 기능이 조금 빠지기도 하고, 더해지기도 했다. 이 부분이 살짝 아쉬운데, Slot 자체로 할 수 있는 역할을 맨 위에 놓고, 그 맨 위에서 따로 상속을 받아왔으면 좋겠다는 생각이 든다.

현재 구조

끝나고 나서 생각해보니 좋을 것 같은 구조

ItemSlot을 베이스로 QuickSlot과 CreateSlot을 만들다보니, 몇몇은 깡통으로 재선언해서 바꿔줘야 하기도 했고, ItemSlot 자체가 MonoBehaviour로 되어있어서 Instantiate로 소환하면 에러가 떴다.(가상으로 슬롯 소환해서 바꿔주는게 안되서, 다른 방법을 고안해야했음. 아마 부가적으로 선언되어있는 인자들 때문이었던 것 같다.)

 

 

어쨌거나, 그렇게 만들어진 ItemSlot은 List 형태로 구성되어서 Inventory가 된다. QuickSlot이 모이면 QuickSlot Inventory가 된다.

 

이 부분도 아쉬운 부분이 좀 있는데, 바로 Inventory 내에서 바로 아이템 끼리의 교환 등등을 구현하지 못한 것이다. 정확히는 유연하지 못하다고 해야할까. 인벤토리와 퀵슬롯 인벤토리를 별개처럼 선언해버린 나머지, 둘 사이의 교류를 더 상위에 있는 Item Manager에서 관리해줘야했다.

이 부분이 좀 아쉬운데, 아마 위처럼 슬롯 구조를 바꾸고 List<Slot> Slots로 인벤토리를 만들고서 맨 몸, 퀵슬롯, 가방과 상자 등을 또 다시 List<Inventory> Inventorys로 바꾸면 되지 않을까 싶다. 0번부터 채워서 0번 크기를 초과하면 1번으로, 1번이 초과하면 2번으로 보내는 식으로 만들면 가능하지 않을까?

 

다음은 Create Table이다. 기본적인 골자는 위처럼 재료 아이템들을 사용해서 타겟 아이템을 만드는 방식이다. 

게임을 해봤으면 알겠지만, 재료 아이템이 인벤토리에 있는 것인지 확인하여 타겟을 만들어내는 것으로, 조금 더 자세히는 아래와 같다.

이것 하나가 Create Table이고, 이 Create Table가 모여서 Create Inventory를 형성한다.

그럼 이제 Inventory라고 정의할만한 것은 총 3개가 된다.

 

1. 가방 역할을 하는 인벤토리.

2. 특정 조건(손에 쥘 수 있는 Grap 속성이 있는 아이템만을 등록가능한) 퀵슬롯형 인벤토리.

3. 가지고 있지 않지만, 미리 정해놓은 조합식에 따라 아이템을 제작하는 인벤토리.

 

3번의 경우 인벤토리라고 부르기 애매하지만, 아이템 슬롯이 모여져 만들어졌으니 이번 설계상 인벤토리라고 부르자.

그렇게 만든 Inventory들이 합쳐진 UI는 다음과 같다.(I 키를 눌렀을 때 보이는 구조)

탭키를 눌렀을 때는 인벤토리 UI와 제작창 UI가 감춰져 퀵슬롯 UI와 마우스로 선택하는 옵션이 켜진다. Tab키와 I키는 UI를 공유한다.

 

이상이 캐릭터가 가지고 다니는 인벤토리들이다. 그러니까 이걸 Character Inventory라고 부르자.

그리고 캐릭터에 없는, 아이템이 들어가 있는 장소들은 크게 두가지로 분류할 수 있다.

 

하나는 Field Item. 월드에 오브젝트 형태로 구현되어 있는 아이템들이다. 이건 슬롯 형태가 아니므로 인벤토리라고 부르기에 애매하다.

 

두 번째는 상자와 같이 슬롯들이 모여있는 인벤토리처럼 구현되어 있지만, 그게 다른 캐릭터-오브젝트 내부에 같이 끼워져 있는 인벤토리. 시체나 바닥에 떨어져 있는 가방이 여기에 포함된다.

 

이렇게만 구현해놓아도 처음 설계한 게임의 아이템과 인벤토리 기능은 전부 구현할 수 있었다. 상점 관련 NPC 역시 같은 원리로 만들 수 있었다. 그래서 최종적인 저 3개의 분류와 아이템 베이스를 연결하면 아래와 같다.

Slot끼리의 상호작용은 아이템 매니저를 거치지 않는 것이 좋다.)

 

이렇게 팀 프로젝트의 정리가 끝났다.

자잘하게는 사운드, 이펙트, 동물(사냥용)의 행동과 애니메이션 등을 손대기는 했지만, 다른 사람들을 보조해준 것에 불과했기 때문에 여기서는 정리하지 않고 나중에 따로 해 볼 기회가 있다면 정리하겠다. (특히 애니메이션 관련은 꼭 해봐야겠다고 느꼈다.)

 

애니메이션이 모든 3D 게임에 나오니까 필수. 그리고 직접 모션캡처를 해 본 경험이 재미있었다. 다만 이번에 몇몇 동작 빼고는 아예 쓸 수도 없었다. 세세한 부분에서 부자연스러워서 어쩔 수 없었다. 그래도 각각 관절의 가동범위의 최소치, 최대치를 정하면서 자연스럽게 만들어본 몇몇 동작은 잘 적용이 되었다. 

 

이펙트는 모닥불을 같이 만들어보긴 했는데, 만들기 굉장히 힘들었다. VFX랑 같이 공부할 필요성을 더 느꼈다.

 

라이트는 정말로 꼭! 해야한다고 느꼈다. 라이트 프로브를 대충이나마 얼기설기 넣는 것만으로도 확실히 게임의 퀄리티가 달라진다. (시연때는 그걸 몰라서 동굴 안이 너무 안보였다. 광원을 넣는게 아니라 주변광을 넣어줬어야 했는데.)

 

아쉬운 점이 있다면 각 함수와 매니저 기능이 뚜렷하게 구분되지 않았던 것. 그리고 슬롯과 인벤토리의 기초형을 만들고 거기서 파생시켜가면 재활용이 쉬웠을텐데, 그러지 못하고 그때 그때 만든 느낌이 있어서 아쉬웠다.(중복되는 코드가 꽤 있었음.)

 

아이템 매니저는 정리 마지막에 썼듯이 오브젝트 형태 아이템 <-> 슬롯 형태 아이템과 데이터 베이스 읽어오기에만 사용하고, 슬롯과 슬롯 사이의 이동은 인벤토리나 슬롯 선에서 해결하도록 수정 할 수 있었다.

 

 

***

 

팀 프로젝트 후기

 

혼자 만들 때보다 많은 내용을 넣을 수 있고, 처음 기획과 중간중간 회의가 얼마나 중요한지 알게되는 계기가 되었다. 완전한 분업이 가능하다면 다른 사람의 작업물을 이해할 필요가 없겠으나, 그게 현실적으로 가능할 것이라는 생각이 들진 않는다.

그렇다면 결국 일종의 가이드가 있어야 했는데, 다들 빨리 작업에 들어가고 싶어해서 정교하지 못한 가이드로 진행한 것이 너무 아쉬웠다. 이번 프로젝트야 서로 비슷하게 배우고, 규모가 크지 않다 보니 코드같은 것은 주석과 간단한 질문을 통해 코드적으로는 오해되는 부분이 없었다지만, 더 큰 프로젝트에서는 확실히 컨벤션을 포함하여 회의가 주기적으로 필요해보인다.

 

이것이 제일 두드러지게 나타났던 곳이 바로 애니메이션 파트. 애니메이션과 동작, 캐릭터를 맡아주기로 한 팀원이 중간에 제외하기로 한 동작을 넣는 등의 일. 그리고 카메라와 플레이어의 시점 불일치, 모델링 안쪽으로 파고들어가는 캐릭터 애니메이션 등이 의견의 불일치로 중요한 부분은 갈아엎고 몇몇 부분은 어색한 상태 그대로 내야했다. 

 

제일 안타까웠던 것은 위의 일이 GitHub의 숙련도 이슈로 일어났다는 점이다. 작업 파일과 모델링을 서로 공유하고 불러오는 것이 미숙하여 자신이 가지고 있는 별개의 캐릭터 모델링과 별개의 맵으로 실험했고, 그 결과 원 애니메이션 골격과 캐릭터 위치, 피벗 등이 사소하게 꼬이면서 수정을 위해 많은 시간이 소요되었다. 가지고 있는 툴의 숙련도가 올라가는 것도 정말 중요하다. 

 

완성된 게임의 모습은 솔직히 '재미있게 만들기'라는 점에서는 100점 만점에 30점도 못 줄 모양새였지만(특히 조작감같은 부분이 끔찍했다), 기틀을 어느정도 잡았다는 점에서 나름 만족할 수 있었다. 3D 게임이 역시 2D보다는 만들기 어렵구나~라고 생각하는 계기가 되기도 했다. 

 

워낙 사람 좋은 팀원들을 만나서인지 다음에 게임 잼같은걸 할 기회가 있다면 신청해보고 싶기도 했다.