[1]. Prototype_Manager 클래스를 마저 작성한다.

• Client 프로젝트의 Level 갯수를 바탕으로 관리하는 Engine 프로젝트 속 Prototype_Manager 클래스가 될 수 있게 인자에 _uint 타입으로 Level의 갯수를 받는 Create함수를 작성한다. Create 되면서, Initialize 함수에서도 Level 갯수를 받게 작성한다. - 이 갯수 만큼 Map 컨테이너를 배열만큼 예약하는 작업이다.

• 이제, Prototype_Manager 클래스에서

  • 원형 객체들을 추가하는 Add_Prototype 함수

  • “어떤 레벨 속의, 어떤 키값을 받는” 원형 객체, 즉 GameObject or Component 인지 찾는 Find_Prototype함수.

  • Find_Prototype 함수에서 반환된 객체들이 GameObject 인지, Component인지 체크해서 원형 객체를 복사 (Clone 함수 호출) 하는 Clone_Prototype 함수

[2]. Utitlity 프로젝트에, Game Object 필터를 만들고, Object_Manager 클래스를 추가한다.

• 이 Object_Manager 클래스는,

• prototype_Manager에 추가한 원형 객체들을 복제해, 이 오브젝트 매니져에 보관한다.

• 보관할 때, 객체들은 각 레이어들에 분류해서 저장해 놓는다.

• 보관하고 있는 객체들을, 반복적으로 Update 호출한다.

• 모아놓은 객체들의 렌더함수를 호출하는 것은 추후, Renderer 클래스에서 하겠다.

[3]. Object_Manager 클래스에서, 직접 Render 기능까지 담당하지 않는 이유는, 깊이 버퍼 값에 의한 그리기 순서를 고려했기 때문이다. 나중에 추가할 Layer 클래스들에 객체들을 분류도 하고 싶고,

분류는 왜 할 까, 집단에 대한 검색을 필요로 해서 (ex. 플레이어가 광역스킬을 사용했는데, 적군 집단들만 모아놓은, 리스트를 순회하면서 처리를 하면 좋겠다)

그리는 순서를 지켜서 관리를 하고 싶은데, 이것을 Object_Manager에서 분류하고 싶은대로 하고, Renderer 클래스에서는 그 그리는 순서대로 관리를 하겠다. 스카이박스를 생각해보자. 그리고, UI관련 객체들의 그리는 순서에 따라 고려사항도 있다.

[4]. Object_Manager 는 결국 복제한 사본 객체를 저장하는 클래스인데, 이 사본 객체들도 Level 별로 구분이 되어야 하기 때문에, Level의 갯수를 받아오는 Create함수를 작성할 것이다.

[5]. Layer 안에, 객체들을 List 형태로 보관해 놓을 것이기 때문에, Object_Manager 클래스에, map 컨테이너로 Layer* (이게 list 형태) 를 받는 형태로.

[6]. Update를 Priority_Update / Update / Late_Update 로 나누어서, 각각의 Update 를 쫘악 다 끝나고 다음 Update로 들어가게 한다. 추후에 각 Update 사이에 작업해야할 일이 있다. 카메라 같은.

[7]. Layer 클래스를 만든다.

[8]. Layer는 사본객체들을 분류해놓은 한 묶음 이라고 보면되는데, 이제 Client 프로젝트에서 사용할 객체의 부모 클래스를 Engine 프로젝트에서 만든다 → GameObejct 부모클래스

[9]. GameObject를 담는 list를 Layer 클래스에 만들어준다.

[10]. AddGameObject 함수를 추가해서, GameObjeect를 list에 push_back 해준다.

[11]. 나머지 함수들을 작성하고, Object_Manager 클래스에 Clone 하는 기능의 함수를 만들자.