Page 0: Page 1: 20100221 이창희 In kasa Blog: cagetu.egloos.com E-mail: cagetu79@gmail.com Page 2: Introduction Data-Driven의 의미를 알아보자.  결국 게임 엔진의 전체 아키텍처와 발전 방향  2008년도에 KASA 모임에서도 EntityComponent에 대해서 이야기 한 적이 있 지만, 여전히 어려운 이야기!  특히, 국내 엔진에서는…  Page 3: Introduction  Game Engine Architecture 책에 나와 있는 내용을 통하 여, Game Engine에서 지원 하는 Game Play System에 대해서, 알아본다. Page 4: Contents Game Object Models  Data-Driven Game Engines  Runtime GamePlay System      Runtime game object model Real-time object model updating Messaging and event handling Scripting Page 5: Game Object   여기서의 Game Object는 개념적인 의미  C++ 등에서 말하는 Object와는 약간 다르다. Object-Oriented Design로 비춰보면, Game Object는 본질적으로 attribute들과 behavior들의 모음이다.   Attribute : object의 현재 상태 Behavior : 시간에 따라 어떻게 상태가 변하고 이벤트들에 대해 반응하는가? Attribute들의 schema와 Behavior들. (behavior는 script code를 통해서 혹은 이벤트들에 대한 반응, 역시 instance 마다 다 양)   Game Object는 Type으로 정의   Type들의 instance들은 attriute들의 value들이 다르다. Page 6: Data Driven Game Engine Game의 behavior가 programmer들에 의해 독점적으 로 생산된 software보다는 artist들이나 designer들에 의해 제공되는 data에 의해 전체 혹은 일부분이 컨트 롤될 수 있을 때, data-driven이라고 말한다.  Iteration times를 향상 시킬 수 있다.  World Editor나 Tool의 형태로 반드시, Designer나 Artist들에게 제공 되어야 한다.  Page 7: Tool Architecture Data Run-Time Engine Tools and World Editor Core System  일반적인 형태  Run-Time Engine을 다루는 사람은 Programmer, Tools/World Editor를 다루는 사람은 Artist/Designer. Page 8: Tool Architecture Data Type Run-Time Engine Tools and World Editor Data Type Core System  새로운 Data를 추가하고 싶다면, Programmer가 Game과 World Editor에 모두 새로운 Data에 대한 Type과 기능을 추가해주어야 한다.  Game에서 사용하는 Data Type과 World Editor에서 사용하는 Data Type은 같지만, 다르다. Programmer의 도움이 항상 필요하다.  병목 발생!!!  Page 9: Tool Architecture World Editor Run-Time Engine Tools Core System    Run-Time Engine을 기반으로 World Editor를 만든다면, Run-Time Engine에서 Data의 Type을 정의하면, World Editor에서 사용이 가능하다. 새로운 Data의 Type을 추가할 필요가 있더라고 하더라도, Run-time Engine에 추 가하면, World Editor에서 바로 사용이 가능. Runtime engine 위에 Editor가 있기 때문에, 수정된 결과를 바로 게임 플레이가 가능하고, Editor가 Game의 일부가 될 수 있다. Page 10: Data Driven 결국 Data-Driven을 구현 한다는 것은 Run-time Engine 안에 Data Type의 추가 /제거를 통해서, Game Object의 Type을 정의하는 것을 말한다.  어떻게?   Unreal의 사례 Page 11: Data Driven  문제점  많은 팀들은 자신들의 게임에 필요한 특화된 feature들의 개발과 연구를 멈추고, data-driven architecture로 미친듯이 달려들게 만 들었다. 하지만, 이런 급함이, 복잡한 tool과 engine system을 만 들게 되고, 결국, hard-coded 방법들보다도 더 낮은 생산성이 발 생!   즉, 모든 game engine은 Data-driven component들을 가져 야 하지만, data-drive하기 위한 engine의 면을 선택하고자 할 때, 매우 주의깊게 처리해야 한다. 사례?! Page 12: Runtime Object Model Architectures    결국 Data라고 하는 것은 게임 안에서는 Class로 봤을 때, attribute 즉, 변수를 의미. World Editor에서, game designer는 추상적인 game object model로 게임에 존재할 수 있는 다양한 종류의 타입을 정의하고, 어떻게 행동하고, 어떤 종류의 attribute을 가질 것 인가를 표현한다. 두 가지 Style  Object-centric ○ ○ 각 tool-side game object는 runtime시에 class의 instance를 통해서 표현된다. 즉, class를 통해서, attribute와 behavior를 정의 Ex) Unreal’s 각 tool-side game object는 오직 unique id에 의해 표현된다. Game object의 property들은 object id를 Key로 하고 property type 하나를 많은 data table에 대해 분산 되어 있다. Property : data + behavior Ex) Nebula Device, Naughty Dog,  Property-centric ○ ○ ○ ○ Page 13: Object-Centric    Game Object를 하나의 Class(Object)로 표현 일반적으로 사용하는 형태 문제점   다중 상속의 문제점 Bubble-Up Effect 상속관계를 하나의 기능 Component로 만들고, Game Object는 여러 개의 Component들을 가질 수 있다.  계층으로 단순화 하기 위해서, “Is-A”를 “Has-A”로…    Unreal’s Actor Class 통신  객체 단위의 통신은 특정 객체의 메써드를 직접 호출 하는 것이 가능하기 때문에, 주 로 함수 호출 형태로 이루어 진다. Page 14: Property-Centric  Game Object는 unique id!!!   Game Object는 실체가 없다. Game Object들이 가질 수 있는 Property들을 정의한다.   Property 안에 data + behavior가 숨겨져 있다. Attributes    각 Game Object들에 대한 property들의 값들을 포함하는 하나의 테이블을 만들고, object의 id를 키로 한다. 즉, object 보다 attribute(data)를 중심으로 생각한다. 이 design은 마치 관계형 데이터와 더 유사하다. 각 attribute는 Object의 id를 primary key처럼 가지고, database table안에 하나의 column와 같다. Nebula3 참고 각 property의 각 type은 property class로 구현할 수 있고, 각 property class는 hard-coded methods로 behavior를 제공할 수 있다. 또한, Script code를 통하여, game world 내에 발생하는 이벤트들에 대해 game object가 반응 할 수 있도록 사 용될 수 있다.  Behaviors    통신  객체 단위가 없기 때문에, 설사 Game Object 내부에서 Property 대 Property 간의 통신이라고 할 경우라도, 직 접 호출 (함수 호출) 형태가 불가능 하다. 즉, Message를 이용한 호출이 일반적!!! Page 15: Object Type Schema    Game Object의 attribute들과 behavior들은 G.O의 type에 의해 정의된다. game world editor에서, game object type은 attribute 들의 모음을 정의한 data-driven schema에 의해 표현된다. Type schema들은 world editor에 의해 사용되기 위해 단순하게 는 text file 로 저장될 수도 있고, Script등 여러 형태로 저장할 수 있다. 사용자에 의해 편집되고 Inspection… Data management 관점에서 보면, serialized object format 이나 정의된 pointer를 가지는 binary object image로 관리되는 것보다 key-value의 table로 처리되는 것이 훨씬 심플하다. Page 16: 간단한 예 enum LightType { Ambient, Directional, Point, Spot } Type Light { String UniqueId; LightType Type; Vector Quaternion Float 사용 } Pos; Rot; Intensity : min(0.0), max(1.0); // 초기값 및 meta data. Tool에서 Page 17: 간단한 예  Object-centric은 Object Type을 Class를 통해서, 정의.  Property-centric은 Object Type은 Object Type Id 와 Data의 Table로 정의 되기 때문에, 관계 형 데 이터베이스의 형태로 표현 Page 18: Scripting Game Object의 Behavior를 정의  Game Scripting language들을 일반적으 로 아래 두 가지로 잘 사용됨   Data-definition languages  Runtime scripting languages Page 19: Interface with the Native Programming Language Script와 native code의 쌍방향 통신을 가능. 대부분의 scripting language는 native code 가 script에 의해 invoke되는 것이 가능.  기본적으로 특정 script function들은 script language 안에서 보다 native language안에 서 구현되는 것이 일반적이다.  Page 20: Game Object Handles    Script function들은 engine의 native language에서 구현된 Game Object와 상호작용이 필요하다. Native language의 referencing object들에 대한 mechanism(pointer등)은 Scripting language에서는 사용할 수 없다. Handle을 사용(Numeric, String) Script는 매개변수로 object의 handle을 넘겨서 native function을 호출함으로서 game object에서 operation을 수 행할 수 있다. Native code에서는 handle을 다시 native object로 변환하여 처리. Page 21: Receiving and Handing Events 엔진의 성격에 따라, Object Type 별로 scripted event handler들을 가지거나, Object Instance들 별로 scripted event handler를 가진다.  각 script는 여러 상태를 가질 수 있다. (Uncharted engine에서는 script들은 FSM들이다.) 각 상태는 하나 이상의 event handler들을 가질 수 있다. Game Object가 이벤트를 받았을 때, 각 상태는 native C++ 에서 선택적으로 event를 처리할 수 있다.  Page 22: Script의 사례 gdc09-statescripting-uncharted2.pdf 문서를 통해서, Uncharted의 스크립트 사용 사례를 볼 수 있다.  Unreal’s Script의 사례   Script는 Game Object의 하나의 Component 혹은 Property로 연결할 수 있으며, Game Object 안의 한 부분으로 Update 및 Event 처리가 가능하다. Page 23: 정리 Data-Driven  Game Object      Attributes Behaviors Object-centric Property-centric  World Editor Page 24: More…   결국 Game Engine에서 Game Play Foundation이 어떻게 만들어 졌느냐가 게임의 성격을 판가름. 아니, 어떤 게임의 성격을 가졌느냐에 따라, Game Play System을 만드는가? Ex) Unreal의 성격  소수의 Game Designer/Artist가 게임을 제작하고, 테  스트하는데 강력한 느낌. Page 25: MMORPG   위의 내용 및 사례는 콘솔 게임 MMORPG의 특징  대규모의 Game Data ○ ○ 다수의 Artist 다수의 Designer : Excel을 많이 사용   게임 Logic이 Server/Client에 분산 정교함보다는 다수의 처리 많은 수의 Designer들이 데이터를 만들고, 게임에 넣어보고 테스트 해보려면, 결국 Data-Driven으로… ○ ○  그렇다면, 다수의 Game Object를 제작, 수정, 확장을 하기 위해서는  Object-centric으로 처리한다면, Designer가 객체(Class)를 정의한다. Property-centric으로 처리한다면, Designer는 Data Table을 정의한다. Object-centric으로 처리한다면, Server/Client에서 사용할 모든 attribute들과 behavior들을 모두 정의해야 한다.    Server/Client의 로직이 분산된다?! 즉, Behavior가 나뉜다. ○ 서버용 객체와 클라용 객체를 따로 정의?! 물론 Component를 통해서, 선택적으로 가질 수는 있겠다. ○ Property-centric으로 처리한다면, Server/Client가 사용할 모든 attribute들을 Data Table안에 모두 집어 넣고, Server/Client용 Property를 구분하여, Data Table에서 Data를 선택적으로 사용한다. Page 26: Next Generation  아직은 게임 엔진에서 Game Play System은 하나의 게임의 성격으로 표현된다. 결국, 게임 엔진에서 Game Play System과 Scripting 은 좀 더 범용적으로 다양한 게임의 성격을 표현할 수 있고, Artist/Designer들은 이런 기반 위에서 다양한 게임 데이터를 빠른 속도로 뽑아낼 수 있도록 발전할 것이다.  C#과 .Net  Page 27: 결국은  여전히 랜더링 엔진, 물리 엔진, 사운드 엔진, 네트워크 엔진 등의 SubSystem은 매우 중요하다. 거기에 Game Play System을 어떻게 쌓을 것인가도 매우 중요.  Data-Driven은 반드시 기반이 되어야 하지만, 어떤 부분을 Data-Drive할  것인지 선택이 중요.  결국, 어떻게 하면 팀 간 혹은 영역간의 병목을 없앨 수 있을 것인가? 가 중요. (반드시 기술이 필요한 것은 아니다.)  즉, Pipeline을 어떻게 설계하느냐도 매우 중요.  좋은 게임 엔진을 만들려면? Page 28: Reference www.gameenginebook.com 2. www.udk.com 3. gdc09-statescripting-uncharted2.pdf 4. http://flohofwoe.blogspot.com/(Nebula3) 1. Page 29: Q&A Page 30: