0.들어가기에 앞서
대사고가 났다. 지금까지 구현해 놨던 인벤토리 시스템이 아무래도 여러모로 코드상 문제가 많았는데, 결국 심각한 버그가 터졌다.
1. 금일 한 업무 정리, 구현 내용
인벤토리 관련 심각한 문제 발생으로, 오늘은 거의 작업하지 못하고 버그만 찾아보고 있었다. 결국 강사님들한테도 보여줘서 디버깅을 시작했는데, 3시간 가까이 버그를 같이 잡았는데도 불구하고 결국 잡지 못했다.
원인은 계속해서 슬롯을 지우고 업데이트하는 방식 때문에, 어디쯤에서 데이터가 날아가는지 정확히 잡을 수가 없다는 것이었다.
결국 구조상으로 문제가 있는 현상황에서 구동방식을 뒤엎고 인벤토리 작업을 다시 하기로 결정했다.
2. 문제의 발생과 배운 점
인벤토리의 문제점을 파악하기 위해서 별의별 짓을 다 했고, 심지어 이와 같이 간단하게나마 구조를 정리했다.
분명 이와 같이 봤을 때 UI가 데이터 쪽에 침범하는 과정이 없다고 판별했지만, UI가 계속 지워졌다 업데이트되는 방식에서 문제가 생겼다고 보고 있다.
사실은 어느정도 튜토리얼을 참고하면서도 이걸 이렇게까지 해야 하나 싶은 부분이 좀 있었지만, 여러 가지 방법을 섞어보기에는 금방 꼬이기가 쉬운 코드였다.
결과적으로 여기에서 더 고쳐보는 것보다는 차라리 좀 더 합리적인 구조로 다시 만드는 것이 좋다고 판단을 받았고, 그 중에서도 추천한 방법은 인벤토리 데이터를 싱글톤으로 처리하는 방식이었다.
게임의 컨셉 상 생존 게임이라는 컨셉은, 인벤토리의 중요성이 높기 때문에 이를 싱글톤으로 처리하는 것도 나쁘지 않은 방식이다.
따라서 데이터를 싱글톤으로 선언한 InventoryManager로 만들고, UI에서 해당 고정 데이터를 읽기만 가능한 방식으로 반영하는 것이 나쁘지 않은 선택이 될 수도 있다는 것이다.
이에 따라 이와 같은 방식으로 저녁 이후에 작업을 시작했다.
솔직히 지금까지 만든 작업물을 전부 엎어야 한다는 것이 꽤 뼈아프고 눈물이 찔끔 나기도 했지만, 여기서 포기할 수는 없었다.
조금 진정의 시간을 가지고 다시 인벤토리 작업을 시작하자.
3. 개선점 및 과제
- 인벤토리의 구조 개편
사실상 처음부터 다시 짜야 하는 상황이다. 정말 다행인건 그래도 한 번 구현해봤다고 다른 구조로 고민하면서 구현하는 과정은 생각보다 시간이 덜 걸린 것 같다. 로직을 이전에 만들었던 것보다 효율성은 미세하게 떨어지더라도 어렵지는 않게 만들었다. 현재 아이템이 실시간으로 UI에 반영되고, 크래프팅 UI에도 정상적으로 반영되는 것까지 작업했다.
이렇게 작업하면서 아이템 조작 방식에 대해서도 고민이 필요해보인다.
- 아이템 사용에 대한 구현
아이템에 대한 데이터 테이블을 만드는 과정에서, 사용 가능한 아이템에 대한 변수를 만든 것을 확인했다. 다만 이걸 이렇게 변수로 받아도 되는 건가라는 의문점과, (사용 가능한 아이템은 수치 입력, 불가능한 아이템은 0 입력) 이런 변수로 Use를 어떻게 구현할 것인가에 대한 문제가 남았다.
이 부분에 대해서는 조금 더 고민해보겠다고 기획팀장님께 말씀드렸고 빠른 시일 내에 완성해야 할 것이다.
- 아이템 크래프팅, 아이템 분해에 관한 구현
이 부분이 원래 오늘 들어가야 하는 작업이었지만, 버그 잡는 걸로 하루를 날린 바람에 결국 제대로 작업하지 못했다. 이 부분에 대해서도 빠른 구현이 필요하다.
