[📜일지] 유니트레인 개발일지 #3. GameObject 관리 모듈

[로코복실한(dovecreative)]

저번 시간에는 그림을 이용해서 프로그램을 좀더 쉽게 설명하는 방법에 대해 알아봤어.

이번 시간에는 원래 저장에 대해 다루려고 했는데, 보다 정확한 구현을 위해 먼저 오브젝트 관리를 만든 후에 그 부분을 만드는 게 더 나을 것 같아서 오늘은 게임오브젝트 관리에 대해서 우선 설명할께.

게임오브젝트 관리도 역시 저번에 알아봤던 방식인 모듈 방식을 이용해서 구현했어. 다만 이건 다른 클래스와의 연결이 그리 큰 비중을 차지하진 않기 때문에 UMesh보단 단순하게 만들 수 있었어.

이제부터 클래스 내에서 게임오브젝트 관리를 담당하는 UBody에 대해 설명할께.

UBody는 클래스 내의 게임오브젝트들을 총괄하는 클래스야.

쉽게 말하자면, 기존의 유니티가 게임오브젝트 안에 MonoBehavior 형태의 클래스가 있는 형태였다면, 반대로 이 개념은 클래스 안에 게임오브젝트가 있는 형태야.

이렇게 함으로써 클래스가 게임오브젝트에 종속되지 않을 수 있고 한 클래스가 여러 게임오브젝트들을 가질 수 있으며, 게임오브젝트를 바꾸거나 삭제하는 데도 용이해게 돼.

아래는 UMesh를 이용해서 게임오브젝트를 얻는 방법이야.

여기서 prefeb는 enum으로 게임오브젝트의 유형을 정리해둔 거야.

게임오브젝트를 얻을 때, Master 클래스에서 자신의 uBody에게 특정 prefeb 유형의 게임오브젝트를 달라고 요청해.

그러면 uBody는 미리 만들어 둔 오브젝트 풀에서 해당하는 prefeb의 오브젝트를 가져와서 반환하고, 게임오브젝트와 prefeb을 딕셔너리 형태로 저장해.

여기서 uBody가 게임오브젝트를 저정하는 이유는, 오브젝트 풀에 반납할 때는 반납할 gameObject의 prefeb을 알아야 하기 때문이야.

Master는 prefeb을 모르고, Master의 gameObject는 Pool에서 나와버렸기 때문에 gameObject로 prefeb을 역추적하는 건 불가능해.

그래서 gameObject를 받아올 때 자신이 뭘 받아왔는지를 기억하기 위해 uBody에서 따로 저장하는 거야.

[게임오브젝트를 받아서 Prefeb - GameObject 딕셔너리에 저장한다.]

아래 그림은 게임오브젝트를 반납하는 과정이야.

게임오브젝트를 반환할 때 앞에서 말한 uBody의 GameObject(Key) - Prefeb(Value) 쌍으로 이루어진 딕셔너리를 통해 이 게임오브젝트의 prefeb을 알아내고, 그 prefeb을 통해 게임오브젝트를 pool에 반환해.

사실 여기까지는 굳이 uBody를 따로 만들지 않아도 오브젝트 풀 클래스에서 구현 가능한 부분이야.

그럼에도 굳이 uBody를 만들어 오브젝트를 관리하는 이유는, 한 마스터 클래스의 오브젝트를 한번에 관리할 수 있기 때문이야.

만약 Master가 그냥 삭제된다면, Master에 있던 GameObject들은 참조를 잃고 인게임에서 삭제되지 않게 될 거야.

이 현상을 막기 위해, 원래는 Master가 Dispose될 때 안에 있는 GameObject들을 일일히 Destroy했어.

하지만 클래스가 복잡해지게 되면 개발자가 놓지는 부분이 생길 수 있고, 오브젝트를 지우는 코드도 길어지게 돼.

이때 자신의 모든 GameObject를 모아둔 리스트가 있다면, 그냥 그 리스트에 있는 GameObject들을 Destroy하면 되겠지.

Master은 파괴될 거니깐 어차피 Master에 있는 GameObject들의 참조는 신경쓸 필요 없고.

이렇게 UMesh 클래스에서 pools에 있는 GameObject들을 전부 풀에 반환하는 함수를 만들어 두면

Master는 삭제될 때 그냥 uBody의 함수를 호출하는 것만으로도 자신의 GameObject들을 모두 풀에 반환할 수 있어!

오늘은 GameObject를 관리하는 방법에 대해 알아봤어.

다음 시간에는 지금까지 한 것들을 이용해서 도로를 만들어 볼께. 담에 봐!