반응형

http://blog.naver.com/doridori3510/30130730459



* 우연한 계기로. 컴포넌트 기반으로 게임을 설계하는 블로그까지 흘러갔다.

링크 : http://kiro86.egloos.com/661187

이번에 과제를 수행하면서

계속되는 상속의 상속의 상속..

그러다가 새로운 기능이 추가되면.

쓸데없는 부분까지 상속..

아. 코드가 지저분해지고 있어.

게임 개발에서도 보통 이런식의 계층적인 상속 구조로 진행해왔는데.

시간이 갈수록 점점 복잡해지는 게임의 오브젝트들.

나무가 움직이고, 돌이 깨지고.. 등등

그래서 좀더 유지보수와 개발을 편리하게 하기위한 설계의 하나의 방법인

컴포넌트 기반으로 클래스간의 관계를 정립하자.

컴포넌트가 무엇이냐.

그냥 쉽게 하나의 속성(?)으로 생각하면 될듯.

인간 이라는 오브젝트는

걸을 수 있다. ( 컴포넌트 1 )

죽을 수 있다. ( 컴포넌트 2 )

체력이 있다. ( 컴포넌트 3 )

..등등등. ...

다양한 속성을 지니고 있지 않은가.

GPG6 에 있는, 4.6 게임 객체 구성요소 시스템 에 그에 대한 설명이 나와있따.

정리를 해보자면.

GameObject. 하나의 오브젝트 ( 사람, 자동차, 몬스터.. 등등 )

class GameObject

{

map<Component_ID, *Component> 컴포넌트 자료 집합

Add_Component() // 컴포넌트 추가

Remove_Componet() // 컴포넌트 삭제

Get_Component( ID ) // 컴포넌트 ID에 대응되는 컴포넌트 리턴

}

이런식으로,

하나의 오브젝트는 여러개의 컴포넌트들을 추가하거나, 삭제, 인터페이스 Get 을 할수 있어야 겟다.

Component. 하나의 속성 ( 그려진다, 체력이 있다. 움직일 수있다.. )

class Component

{

GameObject* pOwner; // 현재 컴포넌트를 가지고 있는 오브젝트의 포인터를 가지고 있어야 한다.

// 컴포넌트끼리의 의사소통을 위해서.

// Owner 를 통해서, 또다른 컴포넌트를 얻어와야한다.

GetID() // 컴포넌트별로 식별 가능한 고유 아이디

GetFamilyID() // 비슷한 종류의 컴포넌트끼리의 그룹 아이디

}

이런식으로,

컴포넌트는 자기만의 식별 가능한 아이디를 가지고 있어야한다.

책에서는 클래스의 이름을 아이디로 하면, 서로 중복되지않는 고유 아이디를 가질 수 있다고!

패밀리 아이디가 필요한 이유도 있는데.

만약

그릴수 있는 컴포넌트가 있다.

class Component_Render

그리고 원을 그리는 컴포넌트가 있다. 어차피 그리는 컴포넌트니깐. 상위 컴포넌트를 상속 받는다.

class Component_Render_Sphere : public mponent_Render

또, 네모를 그리는 컴포넌트가 있다. 마찬가지로 상속

class Component_Render_Rect : public mponent_Render

이제.

class GameObject_A 가 있다.

근데 이놈은, 어떨경우에는 원을 그리고, 다른경우에는 네모도 그린다.

그렇다면 코드상에서

if( 원 컴포넌트 )

원 컴포넌트 -> Render()

else ( 네모 컴포넌트 )

네모 컴포넌트 -> Render()

이렇게 해야한단 말인가? 말도 안됨.

그래서 책에서는 FamilyID 를 통해서,

공통된 그룹은 그냥 상위 컴포넌트의 인터페이스를 가져와서 하면 된다고.

if( 렌더링 컴포넌트 )

렌더링 컴포넌트 -> Render() // 알아서, 현재 원이라면 원을 그리고, 네모라면 네모를 그리것지.

// 기본 코어는 끝이고.

// 책에서는 추가적으로. 템플릿 팩토리 객체. 를 통해서 컴포넌트와 오브젝트를 생성한다.

객체를 생성하는데 좀더 편하게 만들기 위해서.

각자 컴포넌트, 오브젝트를 생성하는 객체를 만들고.

이 객체들을 생성하는 팩토리 객체를 만들어서.

관리를 한다.

반응형

+ Recent posts