Entity System

1. Entity System KASA 2008-08-20 이창희 (2008-06-22 C++ Componet System By김성헌 님의 발표에 계속…)

2. 키워드 • Entity • Component • SubSystem • Message • Data-Driven • Reflection • Property

3. MMOG 의 문제점 • MMORPG개발에 가장 치명적인 문제점은launch 이후에 게임 로직을 지속적으로 변경시키는 것은 어렵다는 것이다. • 마지막 이슈가 MMOG의 성공에 핵심이다. 즉, MMOG가 성공적으로 출시되었을 때, 장기간의 성공과 실패는 매 달(month) 더 나은 어떤 것을 게임에 업데이트 하는 개발 팀의 능력에 의존해야 한다. • 즉, launch 이후, 크지 않은 노력으로, 기본 게임 형태를 제한 없이 변경이 가능해야 한다는 것이다.

4. 문제의 인식 • “57U보트가 출현했을 때 연합군은 속수무책이었다. 군수뇌부들이 모여 연일 대책을 논의했다. 어느 날 장성급 간부 하나가 U보트를 퇴치할 수 있는 기상천외한 방책이 떠올랐다고 소리쳤다. 모든 시선이 그에게로 집중되었다. 그가 의기양양한 목소리로 말했다. 바닷물을 끓이면 돼. 곁에 있던 동료가 그에게 물었다. 개쉐야, 도대체 무슨 방법으로 바닷물을 끓이겠다는 거니. 그러자 개쉐가 대답했다. 나는 기획자일 뿐이야. 끓이는 건 엔지니어들이 할 일이지.“ – 이외수님의 하악하악 中 • 게임이 어떻게 진행될지는 개발 단계에서는 아무도 장담할 수 없다.

5. 문제의 인식 • 개발 단계 • 몬스터는 개, 새 종류로 설정하기로 합니다. • Launch 후, 1년 후… • 개새를 만들어줘요.. 쓰벌.. -_-; • 개발 후에는 개, 새, 개새가 존재한다. 슬슬 정체성이 무너지기 시작… • 1년, 2년 후에는 BaseCharacter 클래스 엄청 커지게 될 것이고, 최하위 클래스는 불필요한 메써드와 맴버 변수를 한 아름 가지고 있게 될 것이다. • 이런 불필요한 것들이 시간이 점점 지나게 됨에 따라, 추가적인 작업에 제한을 두게 되고, 변경에 추가비용이 많이 들게 되며, 시스템의 속도를 저하시키게 된다.

6. Entity System • GDC2002에서 Scot Bilas에 의해 Dungeon Siege에 사용된 Data-Driven 방법과 Game Object 소개로 인해 알려지기 시작 • 전통적인 OOP의 문제점과 확장성을 고려해서, 조합형 객체 시스템(Component Object …), Component System, Entity System 등으로 불리게 되며 각광을 받기 시작. • 목표는 Source Code에서, 게임 로직과 변수들을 분리 • Component(구성요소) 접근법은 다른 구성요소에 거의 독립적으로 기능별로 분류한다. 전통적인 객체 계층 구조을 없애고, 객체는 독립적인 구성요소들의 집합으로 생성된다. • 각 객체(object)는 오직 필요한 기능성만 가지게 된다. 어떤 다른 새로운 기능성은 구성요소(component)를 추가됨으로 구현된다.

7. Inheritance vs. Aggregation • Inheritance • The Diamond of Death. • Pass-Thru Enforcement. • Unintended Consequences. • Dependencies. • Difficulty in Comprehension. • Interface Bloat. • Compile-time에 기능 변경. 구현된 디자인에 종속적. • Component-based • Run-time에 기능 변경이 가능.

8. Data-Driven • Meaning: “No Engineer required” • Game Designer가 새로운 객체를 추가할 수 있도록 한다. • Compile-time에서 프로그래머가 개입해서, 작업되는 기존 작업 시스템에서, Data 기반으로 Run-time에 객체와 데이터를 수정할 수 있어야 한다. • Engineer is slow • Engineer가 개입하게 되면, 객체를 추가하고, 확인하는 절차가 늘어남에 따라, 개발 시간이 많이 소요된다. • Run-time에 객체를 수정할 수 있어야 한다. • Causes designers to hack around missing functionality • Goal: remove C/C++ from game • Line between engine and content is always moving : Scot Bilas- A Data-Driven Game Object System에서 인용 http://lisa.siegenetwork.com/elves/scripts/aura/

9. Entity • Game Entity는 Game World 안에 존재하는 어떤 객체이다. 일반적으로 객체는 눈에 보이는 플레이어이고, 주변을 움직일 수 있다. • 게임 월드 상에서 모든 식별 할 수 있는 “thing”에 대해서, 하나의 Entity로 본다. • 만약 100개의 똑같은 탱크들이 있다면, entity는 100이다. 1이 아니다. • Entities has no data and no methods. • 행동은 하나 이상의 component를 이용해서, class와 같이 사용이 가능하다.

10. Component • 게임 안에서 item은 다양한 단면을 가진다. 전통적인 OOP로는 단일 클래스로는 다양한 단면을 하드코딩으로 처리하거나, 작은 단위의 unit객체를 다중 상속하여 처리를 해야 한다. • Entity System에서는 하나의 단면을 Component로 구현하고, Entity가 다른 단면들을 서로 다른 성격의 component들을 가지게 된다. • Component는 실제로 중요한 일 하나를 한다. • 개개의 aspect들을 소유함으로 entity들이 분류된다. • 전통 시스템과 유사해 보이지만, 한 상속 계통을 따라 내려오는 클래스들은 강한 내부 응집성을 가지고 되므로, 문제점이 해결된다. [Gpg5권 1.3.4]

11. SubSystem • Entity/Component 영역 밖의 처리를 위해 SubSystem이라는 개념을 도입 • Entity가 가지고 있는 같은 특성의 구성요소를 전역적 행동(global action)을 수행한다. • 각 System은 지속적으로 돌아간다. • 하나의 System을 하나의 Thread로 이용해도 된다. • System과 이용 가능한 특성(Component의 타입) 사이에 1:1 관계가 된다. • 모든 Entity가 가지고 있는 component들 중에 같은 타입의 component들을 모아서 하나의 system에서 처리한다. • System은 본래 주어진 특성의 Component에 대해 method-구현을 제공한다. • 한번에 하나씩 각 다른 Component들에 대해 Component들 자신의 내부 함수들을 수행하도록 지속적을 running system을 가지고 있다. • Ex) Rendering System, Animation System, Input System, etc • Ex) Rendering System은 16milliseconds 마다 깨어나고, 각 Entity들의 RenderableComponents들을 가지고 화면에 출력하고 다시 sleep…

12. 대충 이런 모습으로 작동하게 된다. • 가로: entity가 가지고 있는 Component • 세로: System, entity들의 같은 type의 component들을 처리한다.

13. 객체간 통신 • 구성요소들 사이의 의사소통 방법 • 알고자 하는 또는 알려주고자 하는 어떤 것에 대한 구체적인 인터페이스를 알고 있는 경우에는, Component 관리자에게 그 인터페이스의 포인터를 요구하고, 그 인터페이스 포인터를 통해서 특정 구성요소의 메서드를 호출하면 된다. • 메시지(Message)를 이용. 이는 어떤 구성요소가 뭔가 말할 것이 있지만, 딱히 어떤 구성요소에게 말해야 할 지 모르는 경우에 해당한다. • 객체 간의 의존성 문제를 해결하기 위해서는 메시지 시스템을 이용해서, 각 구성요소에서 연관된 구성요소에게 event(메시지)를 전달하는 방식을 고려해 보는 것이 좋다. 그래야 추후 component가 제거 되거나, 수정되었을 경우, 다른 component에 영향을 최소화 할 수 있다.

14. 객체 간의 통신 • 하지만, 실제로는… • “이상적인 상황에서, component들은 서로를 알 필요가 없다. 하지만, 실제로는 특정 component들은 의존적이 된다. 성능적인 측면에서 다른 component들에 빠르게 접근하는 것이 가능해야 한다. 초기에는 component manager를 통해서, 모든 component들을 참조하였지만, CPU time의 5% 이상을 사용하였다. 그래서, component들이 다른 component들의 포인터를 저장하도록 하였고, 다른 컴포넌트들의 Methods를 직접 호출하도록 하였다.” – Tony Hawk 개발자 Blog 中[4]

15. Scripting… • Game Designer가 외부에서 객체를 수정할 수 있도록 지원해줘야 한다. • Nebula Device2의 mangalore 시스템에서는 sqlite database를 이용하여, content, data를 db를 이용하여, 외부에서 설정을 할 수 있도록 지원하고 있다.

16. GPG5 1.3 구성요소 기반 객체 관리자.

17. ETC • Template • 같은 Entity를 생성한다면, Entity를 구워 낼 수 있는 틀을 만들어야 한다. • Reflection • Property • Property를 이용하여, 외부에서 내부의 데이터를 조작할 수 있다. • Ex) FarCry 스타일의 World Editor • GPG6권 Property를 이용한 Editor

18. 다른 고민들… • 만약 프로젝트에 사용하고자 한다면, 결국 가장 큰 문제는 • 저항 • 다른 프로그래머한테, system을 설명하고, 설득시키기는 것부터 고난의 시작… • 적용에 대한 아티클http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ • 적용 • OOP의 너무나 익숙해진 탓에, 객체를 구현할 때, 어떻게 Component를 구성해야 하는지, System을 어떻게 구현해야 하는 지, 통신은 어떤 식으로 해야 하는 지에 대해, 생각보다 쉽지 않다. • 특히, Component를 구분 짓는 생각보다 어렵다. • 성능 • 문서를 보면, 기본 시스템보다 약간의 성능 저하가 벌어질 수도 있음. (아무래도 그렇게 보이지요…) 하지만, 관리와 확장성 issue와 trade-off 일 듯.

19. 앞으로… • Nebula Device2에서는 mangalore라는 서브 시스템으로 entity system을 지원한다. • Gamebryo에서는 NiEntity라는 서브 시스템으로 entity system을 지원한다. • Unreal Engine에서 강력한 스크립트를 지원하여, 게임 개발의 편의를 제공해주듯이, Data-Driven이라는 측면에서 봤을 때에는, Entity System에 대한 평가를 떠나서 한번 정도는 고민을 해봐야 할 내용임. • 게임의 복잡도를 고려해 볼 때, 특히 MMO의 경우에나, 한번에 통시에 여러 가지의 게임을 생상하고 있는 상황이라면, 이런 시스템을 고려해보는 추세인 듯…(http://www.gamedev.net의 Forum 참고)

20. Reference • [1]C++ Component System 발표자료http://www.dev3d.net/bbs/view.php?id=pds&no=106 • [2]Game Object Structure: Inheritance vs. Aggregation http://www.gamearchitect.net/Articles/GameObjects1.html • [3]GDC02 - A Data-Driven Game Object System http://www.drizzle.com/~scottb/gdc/game-objects_files/frame.htm • [4]Evolve Your Hierarchy http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ • Game Programming Gems 2권 - 범용 C++ 멤버 접근을 위한 속성 클래스Game Programming Gems 4권 1.8장 게임 개체 관리를 위한 시스템Game Programming Gems 4권 1.11장 유연한 즉석 객체 관리자Game Programming Gems 5권1.3장 구성요소 기반 객체 관리Game Programming Gems 5권 1.4장 템플릿을 이용한 C++ 반영 기능 구현Game Programming Gems 6권 1.1장

21. 끝 – Q&A