2025.05.08 / 아이템 시스템 개발 회고 및 트러블슈팅

🧩 오늘의 역할 및 작업

• 클래스 다이어그램 팀 작업: 전체 구조 설계 참여 (역할 분담 포함)
• 스토리 및 컨셉 작성 담당:
  • 《도트 아처: 낙서 세상의 화살 》 전체 세계관과 흐름 구상 및 작성
  • "낙서화된 세상" + "도트 궁수"의 시각 대비를 중심으로 한 Archero형 로그라이크 게임 기획
• 아이템 시스템 주요 클래스 직접 개발:
  • Inventory.cs / Item.cs / ItemData.cs / ItemManager.cs

---

⚙️ 구현한 주요 시스템

• 아이템 분류: Weapon, Armor + 세부 타입(활, 검, 낫 / 투구, 갑옷, 신발)
• 등급 시스템: Common → Uncommon → Rare → Epic
• 장비 장착 시스템: 장착 여부에 따라 공격력/방어력 스탯 계산 자동 반영
• UI 연동: 인벤토리 및 장비창 On/Off 기능 포함 (ToggleInventoryUI, ToggleEquipmentUI)
• 아이템 생성 시스템:
  • ItemManager에서 Resources 폴더 기반 아이콘 로드
  • 다양한 아이템 자동 생성 및 itemDataDict에 등록
  • SpawnItem() / SpawnRandomItem() 사용하여 적 드롭 구현 가능

---

🧠 트러블슈팅: 싱글톤 남용 이슈

❗문제 상황

• 아이템 획득 시 Player 참조를 위해 Player 클래스 싱글톤화
   
• 단순 편의성 때문에 싱글톤을 적용했으나, 프로젝트 규모 확장 시 다음 문제가 발생할 수 있음:
  • 테스트 코드 작성이 어려워짐
  • 멀티플레이어/코루틴 환경에서 데이터 충돌 위험
  • UI/Scene 분리 시 참조 끊김 문제 발생

✅ 해결 방향

• Item.Pickup(Player player) 메서드처럼, 외부에서 Player 인스턴스를 명시적으로 전달하는 방식 유지
• 의존성 주입(Dependency Injection) 개념 적용 권장

---

✏️ 회고: 배운 점 & 다음 과제

🔍 배운 점

• 실제로 Item → Inventory → UI 업데이트 → PlayerStats 반영 까지의 흐름을 체험하며, 클래스 간 책임 분리의 중요성 체득
• 장비를 카테고리 + 타입 이중으로 관리함으로써, 나중에 새로운 장비 종류 추가가 확장성 있게 설계됨을 확인
• UI/게임 로직/데이터 분리가 잘 되었을 때 디버깅과 유지보수가 쉬워진다는 것 실감

🧨 힘들었던 점

• 구조를 먼저 짜고 시작했음에도, 중복 코드가 많고 흐름이 꼬였음
• 특히 초기에는 ItemManager, Inventory, Item 간의 데이터 흐름이 불명확해서 디버깅에 시간이 소요됨
• 아직 만들어지지 않은 코드를 위해 따로 맞춰두어야 하는 부분이 쉽지 않았음.

🎯 다음엔 이렇게 하고 싶다

• 먼저 클래스 다이어그램 + 간단한 시퀀스 다이어그램을 먼저 그리고 기능을 나누는 연습이 필요
• 싱글톤은 정말 필요한 곳 (예: ItemManager)에서만 제한적으로 사용하고, 되도록이면 의존성 주입이나 메서드 인자 전달 방식을 사용할 것

---

💡 보너스: 현재 구조에서의 개선 포인트

개선 대상제안 내용

Inventory.cs	UI 관련 로직을 분리하여 InventoryUIManager.cs와 같은 전담 클래스로 이전
Item.cs	ItemPickupRange 또는 ItemTriggerZone 등을 통해 플레이어와 충돌 기반 획득 기능 추가 고려
ItemManager.cs	아이템 생성과 등록을 ScriptableObject로 전환하여 관리 효율 향상 가능