20241210 / Unity_6차 14주차 화요일
지금까지는 ObjectPool을 사용하면서 같은 유형의 Object는 하나의 Pool을 공유하게 만들었었다.
몬스터를 예로 들자면 모든 몬스터의 공통 부분을 하나의 프리팹으로 만들어 Pooling하고
모델링이나 애니메이션같이 서로 다른 부분은 공통 부분의 자식 오브젝트로 그때그때 할당하는 방식이다.
몬스터가 활성화/비활성화 될 때마다 오브젝트를 생성/소멸시키는 과정이 들어갔으니
사실 ObjectPool의 장점을 반만 사용하고 있었다고 볼 수도 있다.
그럼에도 불구하고 이런 방식을 쓴 이유는 이전 프로젝트에서의 좋은 경험 때문이었다.
비슷한 프리팹들을 위해 ObjectPool을 따로따로 만든 다는 것이 비효율적으로 느껴졌었고
그 때는 부모 오브젝트와 자식 오브젝트의 역할 분담이 확실했었다.
1. 공통 부분을 분리하여 오브젝트 풀링하는 경우
장점
- 메모리 절약
- 공통된 부분을 하나의 오브젝트 풀에서 재사용하기 때문에, 동일한 부분을 여러 번 생성하지 않아 메모리를 절약할 수 있습니다.
- 수정 용이성
- 공통 부분을 업데이트하거나 수정해야 할 경우, 모든 프리팹에 일괄적으로 적용됩니다.
- 유지보수성이 높아지고 관리가 편리해집니다.
- 로드 시간 단축
- 공통 오브젝트를 미리 풀링해 두면, 필요한 순간에 빠르게 활성화/비활성화만 하면 되므로 로드 시간이 줄어듭니다.
단점
- 추가적인 코드 복잡성
- 비활성화/활성화 시 공통 부분과 개별적인 자식 오브젝트를 동적으로 연결해야 하므로 구현이 복잡해질 수 있습니다.
- 예: 새 자식 오브젝트를 붙이거나 데이터를 초기화하는 과정에서 오류가 발생할 가능성.
- 실행 시간 증가
- 오브젝트를 활성화/비활성화할 때 공통 부분과 다른 부분을 동적으로 연결하는 작업이 빈번히 일어나면 성능에 부정적인 영향을 줄 수 있습니다.
- 유지보수 복잡성
- 공통 부분과 개별 부분 간의 의존성이 강해질 수 있어, 구조 변경 시 관리가 까다로워질 수 있습니다.
2. 각 프리팹을 개별적으로 풀링하는 경우
장점
- 단순한 코드 구조
- 각 프리팹이 독립적으로 관리되므로, 활성화/비활성화 시 추가 작업이 필요 없습니다.
- 오브젝트 풀링 관리가 간단하고 직관적입니다.
- 빠른 실행 속도
- 오브젝트 풀에서 활성화 시 공통 부분과 자식 부분을 연결할 필요가 없으므로, 실행 속도가 빠릅니다.
- 유연성 증가
- 프리팹이 서로 다른 구조를 가지더라도 관리가 용이하며, 개별 프리팹에 맞는 특화된 기능 추가가 간단합니다.
단점
- 메모리 사용량 증가
- 비슷한 공통 부분을 프리팹마다 별도로 가지므로, 동일한 데이터가 중복되어 메모리 사용량이 늘어날 수 있습니다.
- 수정 어려움
- 공통된 부분을 수정해야 할 때, 모든 프리팹을 개별적으로 수정해야 합니다.
- 유지보수성이 낮아지고 실수 가능성이 증가합니다.
- 로드 시간 증가
- 각각의 프리팹을 풀링하거나 로드해야 하므로 초기 로드 시간이나 메모리 부담이 커질 수 있습니다.
정확히 1. 공통 부분을 분리하여 오브젝트 풀링하는 경우의 장점은 확실히 취하고
단점이 두드러지지 않는 상황이었다.
하지만 이번 프로젝트에서 투사체에도 분리를 적용하고 난 뒤엔 돌이켜야 겠다는 생각이 들었다.
어지간한 물량으론 성능 하락이 체감되는 않았지만,
투사체 같이 생성/파괴가 굉장히 자주 일어나는 오브젝트를 일부라도 Instantiate 해서 쓴다는게
넌센스로 느껴졌기 때문이다.
NPC의 경우에도 공통부분보다 개별부분이 점점 많아지는 등 한계점이 명확했다.
결국 이는 리팩터링이 필요한 부분이다.
그리하여 오늘 투사체에 관하여는 변경을 마쳤다.
몬스터에 대해서도 같은 작업이 필요하며,
최종적으로는 플레이어 진영의 NPC도 리팩터링 되어야 한다.