📚 오늘은….

팀 프로젝트를 마무리하면서 회고를 진행해본다.

내가 잘한 점이 무엇인지, 무엇이 부족했는지, 그리고 팀 협업에 있어서 나는 어떤 점을 성장시켜야 할 지 고민하는 시간을 가져보고자 한다.

💡팀 프로젝트를 마무리하며

KPT 회고를 작성해보았다.

1. Keep (잘했던 점 / 유지하고 싶은 것)

✅ 개인적인 성과:

• 무기 데이터 구조를 통해 확장성 있는 근/원거리 무기 개발한 점
• 오브젝트풀링 시스템을 바탕으로 투사체에 적용한 점

✅ 팀의 성과:

• 공격 로직은 무기에서, 공격에 대한 처리는 피격 대상 처리로 한 책임 분리 구현
• 몬스터, 플레이어, 무기 상호작용을 실시간 소통을 통해 개발한 점
• 에러 발생 시 실시간 소통을 통해 해결하려고 한 점

---

2. Problem (개선이 필요하거나 아쉬웠던 점)

⚠️ 개인적인 아쉬움:

• 무기가 플레이어/몬스터가 사용한다는 점에서 좀 더 데이터 구조를 확장성 있게 설계하지 못한 점
• 설계에 시간을 많이 사용한점, 일단 구현해보면서 더 적합한 구조를 직접 보았어야 함
• 파티클 효과를 넣지 못한 점
• 무기 입장에서만 플립 상태를 고려한 점

⚠️ 팀 차원의 문제:

• 플레이어, 몬스터 체력바를 표시하는 UI의 부재
• 초기 개발 파트 담당을 통한 개발 파이프라인 → 프로젝트 미완성의 원인
  • 게임 기본 기능을 만들었지만, 테스트할 수 있는 공간이 없었음
  • 이게 지속되면서 각 기능이 독집적으로 작동 여부만 가진 상태로
  • 이후 유기적인 작동에서 많은 문제를 야기

---

3. Try (이제, 무엇을 채워야 하는가)

🌟 Problem에 대한 피드백:

• 초기 개발 파트 담당을 통한 개발 파이프라인 → 프로젝트 미완성의 원인

  • main에서 크게 2가지 브랜치로 워크플로우 설정
    • 플레이어/몬스터/무기
    • 던전 씬 / UI
    • 위 두 브랜치에서 다시 역할 분담
    • 브랜치 명도 다르게
      • 플레이어면 featureEntity/Player, 몬스터는 featureEntity/Monster, 무기는 featureEntity/Weapon
      • 위 3개의 브랜치는 origin/featureEntity브랜치를 임시 메인 브랜치로 설정하여 개발 중 병합
      • 던전 / UI는 origin/feature를 기반으로 2개 브랜치로 작업 진행?
    • 이를 통해 플레이어/몬스터/무기가 구현이 되면 던전에서 바로 테스트 진행할 수 있도록
    • 어떤 브랜치 전략이 이번 프로젝트에서 바람직했을까?
    • 다음부터는 이런 상황이 발생하지 않기 위해서는 어떤 부분이 필요할까?
    • 예를 들어 역할은 총괄 - 기능 구현1,2,3..- UI로 설정하였을때,
      • 기능 구현1 구현 완료 → 바로 main에 구현한 사람이 merge
      • 아니면 총괄 담당자가 merge
  • 즉 더욱 명확한 브랜치 전략으로 접근

• 유니티에 대표적인 컴포넌트들의 세부동작을 이해할 필요를 느낌

  • ex) Rigidbody의 body Type, Mass, Angular등등 세부 옵션에 대한 사용목적을 정확하게 알고 있어야..