[내일배움캠프 본 캠프 59일차] 사물을 확대해서 돌려보기_2

 

 

 

상세보기 프로토타입의 구현이 어느정도 끝났다.

 

필드 오브젝트에 상호작용 했을 때 피드백을 줄 InteractionOutline 기능을 맡은 팀원의 도움을 받아서

상세보기상에서의 특정 오브젝트에 닿았을 때 마찬가지로 Outline이 생겨서 UX적으로 확 다가올 수 있게 됐다.

 

그리고 상세보기에서 상호작용을 통해 사라진 오브젝트가 월드 오브젝트에도 그대로 반영되는 것까지 마쳤다.

 

이제 고려해야할 건, 앞으로 생길 여러 오브젝트들이 공용으로 쓸 수 있도록 스크립트를 수정하고 SO나 데이터를 통해 값이나 물건들만 바꿔서 쓸 수 있도록 구성해야 한다.

 

 

나이프를 찾았는지 아닌지에 대한 상태를 저장하는 SO파일을 만들고 해당 상태를 Action형태로 수신할 수 있게 한다

 

 

이후 월드오브젝트에 '상태SO'를 담을 Hidden Item Holder 스크립트를 붙여주고 이를 상호작용을 통해 없애면

상세보기용 오브젝트와 월드 오브젝트가 동일한 상태를 갖게 된다.

 

이 과정 중에 플레이어 프리펩하위의 '모드'로서 상세보기 기능을 프리펩화를 같이 진행했더니

기존의 참조와 라이프사이클이 전부 깨져서 처음부터 하나씩 찾아가면서 디버깅을 진행했더니 생각보다 너무 오래걸렸다.

 

처음부터 기능이나 시스템을 만들 때 라이프사이클을 고려해서 항상 생각하는 습관을 들여야겠다.

지금으로서의 디버깅의 약 8할은 라이프사이클에서 오는 거 같다.

 

항상 매니저 클래스를 만들 때마다 드는 생각이지만 SRP를 생각했을 때 어디까지 관리하는 게 맞을까라는 의문이 든다.

어느새 InspectionManager 코드길이만 300줄이라서 매니저로서 너무 길지 않나 라는 생각도 든다.

하지만 지금 단계에서는 정말 너무 많은 기능만 넣지말고 구현을 우선시하자라는 마인드로 하고 있기 때문에..

 

구현->분리->최적화 순의 사고방식을 갖춰야 마음도 편하고 실력도 더 늘 것이라고 생각한다.

 

오늘 결과물을 합쳐서 전체 라이프사이클을 한번 확인해보려고 했는데 팀원과 생각하는 게임흐름이 다르다 보니

전역적으로 어떻게 신호를 주고 받을 것인지에 대해 정해서 결국 EventBus를 활용하기로 결정됐다.

 

잘 굴러가야 할텐데 걱정이 많다.. EventBus를 써보려고 만든건데

이렇게 게임 전체구조가 이걸 활용하게 될 줄은 전혀 상상을 못해서..

 

<WeakReference> 클래스가 솔직히 걱정이 많이 된다. 이게 AI에 의하면 규칙만 잘지키면 좋은 라이브러리클래스라고 생각해서 썼는데.. 막상 게임에서 이게 얼마나 메모리누수를 막아주고 문제가 안생길지 걱정이 태산이다.

 

차라리 초반에 많이 터졌으면 좋겠다. 뒤로 갈수록 점점 디버깅이니 찾기가 힘들어지다 보니..