2025. 12. 23. 23:25ㆍ본 캠프

현재 프로젝트의 Action Map은 총 3개로 플레이어의 움직임을 담당하는 Player와
상세보기 기능을 위한 Inspection, 그리고 UI로 나누어져있는 상태다.
문제는 상세보기 기능 특성상 플레이어의 입력값을 받지 않아야 하고 (카메라 회전,움직임 등)
그렇다고 해서 UI와 동일한 액션을 쓰지는 않는다.
UI적인 기능을 쓰고 실제로 상세보기의 RawImage는 UIScene에 있는 캔버스를 투사해서 사용하는 방식이지만 UI가 아니다.
이 Input이 여러개일 때 통합하는 과정에서 상당히 많은 문제를 겪었다.
문제는 게임이 페이즈단위로 구성되어있고 UI패널들도 페이즈에 따라 활성화/비활성화를 구성해놨었고
플레이어 프리펩도 추후에 특정 페이즈에서 생성이 될 예정이기 때문에
통합 인풋을 관리할 매니저를 만들어야 했다.

EventBus 구조를 선택했기 때문에 필연적인 결과중 하나였다.

그러다보니 UI입력은 플레이어가 있든 없든, 상세보기 모드여도 항상 활성화가 되어있어야 하기 때문에
별도의 상태를 가지도록 분리했었다. 이전에는 각각의 Player, UI, Inspection에서 각각 Enable,Disable 을 했기에
각각 나 입력 받아야돼 너 입력차단 이벤트가 계속 흩뿌려져서 ESC키가 먹통이되고 커서 숨기는 책임이 누군 활성화되고 누군 없고 이런 상태가 계속해서 일어나게 되었다.
또한 InputManager는 싱글턴 + DDOL로 다룰 수 밖에 없는 이유 중 하나는 씬 전환과 무관해야하며 플레이어가 없어도 입력값 자체는 존재해야 한다. 플레이어가 생성이되면 플레이어의 입력값에 대해 InputManager가 전달하는 방식이어야 했었다.
처음부터 이렇게 구조를 잡아갈 줄 몰랐기에 디버깅에 더 시간이걸리게 됐다.
Additive Scene에 대한 개념을 내가 혼동하고 있었던 부분도 위의 문제를 야기하기도 했다.
UI를 담당하고 있기에 별도의 신에서 작업한 걸 바로 적용할 수 있다는 부분이 매력적이어서 선택했고
지금과정에서도 좋은 선택이었다고 생각했지만
나는 다른신이 로딩됐을 때도 이 UIScene 자체를 계속 들고간다고 생각을 했었다.
하지만 결국 전역적인 UI컨트롤을 하기위해 그리고 기존의 데이터들이 신을 옮겨갈 때마다 깨지지 않기 위해서는
UI Canvas 단위로 DDOL화 되어서 같이 다뤄지게 되야한다는 방식을 듣고 조금 당황했다.
Additive Scene의 의도는 알고 있었지만 명확한 사용방법을 몰랐기에 UI입력도 별개고 Inspection 입력도 별개여도 괜찮다고 생각했지만 결국 하나의 입력을 받아 분리시켜야하는건 필연적인 일이고 신 전환과정에서 데이터연결도
결국 UI에서도 유지가 되야하기에 DDOL을 통해 관리하는 수 밖에 없었다.


아마 작업을 좀 더 진행해봐야 알겠지만 Additive Scene 처리를 어떻게 나눠야 할지 조금 더 고민해볼 여지가 있다.
지금 단계에서 IntroScene 진입단계에서는 필요하지만 PlayScene에서는 사실상 DDOL의 UIRoot에 모든 UI관련 오브젝트가 들어가있어서 무의미한 신 로딩이나 마찬가지다.
'본 캠프' 카테고리의 다른 글
| [내일배움캠프 본 캠프 63일차] 플레이루프 및 상세보기 테스트 (0) | 2025.12.26 |
|---|---|
| [내일배움캠프 본 캠프 62일차] EventBus 디버깅 (0) | 2025.12.24 |
| [내일배움캠프 본 캠프 60일차] 같은 오브젝트, 다른 상태 (0) | 2025.12.22 |
| [내일배움캠프 본 캠프 59일차] 사물을 확대해서 돌려보기_2 (0) | 2025.12.19 |
| [내일배움캠프 본 캠프 58일차] UI작업_RawImage 기반 상호작용 (0) | 2025.12.18 |