1. 20100221 이창희 In kasa
Blog: cagetu.egloos.com
E-mail: cagetu79@gmail.com

2. Introduction
 Data-Driven의 의미를 알아보자.
 결국 게임 엔진의 전체 아키텍처와 발전
방향
 2008년도에 KASA 모임에서도 Entity-
Component에 대해서 이야기 한 적이 있
지만, 여전히 어려운 이야기!
 특히, 국내 엔진에서는…

3. Introduction
 Game Engine Architecture
책에 나와 있는 내용을 통하
여, Game Engine에서 지원
하는 Game Play System에
대해서, 알아본다.

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

5. Game Object
 여기서의 Game Object는 개념적인 의미
 C++ 등에서 말하는 Object와는 약간 다르다.
 Object-Oriented Design로 비춰보면, Game Object는 본질적으로
attribute들과 behavior들의 모음이다.
 Attribute : object의 현재 상태
 Behavior : 시간에 따라 어떻게 상태가 변하고 이벤트들에 대해 반응하는가?
 Game Object는 Type으로 정의
 Attribute들의 schema와 Behavior들.
 Type들의 instance들은 attriute들의 value들이 다르다.
 (behavior는 script code를 통해서 혹은 이벤트들에 대한 반응, 역시 instance 마다 다
양)

6. Data Driven Game Engine
 Game의 behavior가 programmer들에 의해 독점적으
로 생산된 software보다는 artist들이나 designer들에
의해 제공되는 data에 의해 전체 혹은 일부분이 컨트
롤될 수 있을 때, data-driven이라고 말한다.
 Iteration times를 향상 시킬 수 있다.
 World Editor나 Tool의 형태로 반드시, Designer나
Artist들에게 제공 되어야 한다.

7. Tool Architecture
Data
Run-Time Engine Tools and World Editor
Core System
 일반적인 형태
 Run-Time Engine을 다루는 사람은 Programmer,
Tools/World Editor를 다루는 사람은
Artist/Designer.

8. Tool Architecture
Data Data
Type Run-Time Engine Tools and World Editor Type
Core System
 새로운 Data를 추가하고 싶다면, Programmer가 Game과 World Editor에 모두
새로운 Data에 대한 Type과 기능을 추가해주어야 한다.
 Game에서 사용하는 Data Type과 World Editor에서 사용하는 Data Type은 같지만, 다르다.
 병목 발생!!!
 Programmer의 도움이 항상 필요하다.

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의 일부가 될 수 있다.

10. Data Driven
 결국 Data-Driven을 구현 한다는 것은
Run-time Engine 안에 Data Type의 추가
/제거를 통해서, Game Object의 Type을
정의하는 것을 말한다.
 어떻게?
 Unreal의 사례

11. Data Driven
 문제점
 많은 팀들은 자신들의 게임에 필요한 특화된 feature들의 개발과
연구를 멈추고, data-driven architecture로 미친듯이 달려들게 만
들었다. 하지만, 이런 급함이, 복잡한 tool과 engine system을 만
들게 되고, 결국, hard-coded 방법들보다도 더 낮은 생산성이 발
생!
 즉, 모든 game engine은 Data-driven component들을 가져
야 하지만, data-drive하기 위한 engine의 면을 선택하고자
할 때, 매우 주의깊게 처리해야 한다.
 사례?!

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
 Property-centric
○ 각 tool-side game object는 오직 unique id에 의해 표현된다.
○ Game object의 property들은 object id를 Key로 하고 property type 하나를 많은 data table에 대해 분산
되어 있다.
○ Property : data + behavior
○ Ex) Nebula Device, Naughty Dog,

13. Object-Centric
 Game Object를 하나의 Class(Object)로 표현
 일반적으로 사용하는 형태
 문제점
 다중 상속의 문제점
 Bubble-Up Effect
 계층으로 단순화 하기 위해서, “Is-A”를 “Has-A”로…
 상속관계를 하나의 기능 Component로 만들고, Game Object는 여러 개의
Component들을 가질 수 있다.
 Unreal’s Actor Class
 통신
 객체 단위의 통신은 특정 객체의 메써드를 직접 호출 하는 것이 가능하기 때문에, 주
로 함수 호출 형태로 이루어 진다.

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 참고
 Behaviors
 각 property의 각 type은 property class로 구현할 수 있고, 각 property class는 hard-coded methods로
behavior를 제공할 수 있다.
 또한, Script code를 통하여, game world 내에 발생하는 이벤트들에 대해 game object가 반응 할 수 있도록 사
용될 수 있다.
 통신
 객체 단위가 없기 때문에, 설사 Game Object 내부에서 Property 대 Property 간의 통신이라고 할 경우라도, 직
접 호출 (함수 호출) 형태가 불가능 하다. 즉, Message를 이용한 호출이 일반적!!!

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로 처리되는 것이 훨씬 심플하다.

16. 간단한 예
enum LightType
{
Ambient, Directional, Point, Spot
}
Type Light
{
String UniqueId;
LightType Type;
Vector Pos;
Quaternion Rot;
Float Intensity : min(0.0), max(1.0); // 초기값 및 meta data. Tool에서
사용
}

17. 간단한 예
 Object-centric은 Object Type을 Class를 통해서,
정의.
 Property-centric은 Object Type은 Object Type Id
와 Data의 Table로 정의 되기 때문에, 관계 형 데
이터베이스의 형태로 표현

18. Scripting
 Game Object의 Behavior를 정의
 Game Scripting language들을 일반적으
로 아래 두 가지로 잘 사용됨
 Data-definition languages
 Runtime scripting languages

19. Interface with the Native
Programming Language
 Script와 native code의 쌍방향 통신을 가능.
대부분의 scripting language는 native code
가 script에 의해 invoke되는 것이 가능.
 기본적으로 특정 script function들은 script
language 안에서 보다 native language안에
서 구현되는 것이 일반적이다.

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로 변환하여 처리.

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를 처리할 수 있다.

22. Script의 사례
 gdc09-statescripting-uncharted2.pdf 문서를 통해서,
Uncharted의 스크립트 사용 사례를 볼 수 있다.
 Unreal’s Script의 사례
 Script는 Game Object의 하나의 Component 혹은
Property로 연결할 수 있으며, Game Object 안의 한
부분으로 Update 및 Event 처리가 가능하다.

23. 정리
 Data-Driven
 Game Object
 Attributes
 Behaviors
 Object-centric
 Property-centric
 World Editor

24. More…
 결국 Game Engine에서 Game Play
Foundation이 어떻게 만들어 졌느냐가 게임의
성격을 판가름.
 아니, 어떤 게임의 성격을 가졌느냐에 따라,
Game Play System을 만드는가?
 Ex) Unreal의 성격
 소수의 Game Designer/Artist가 게임을 제작하고, 테
스트하는데 강력한 느낌.

25. MMORPG
 위의 내용 및 사례는 콘솔 게임
 MMORPG의 특징
 대규모의 Game Data
○ 다수의 Artist
○ 다수의 Designer : Excel을 많이 사용
 게임 Logic이 Server/Client에 분산
 정교함보다는 다수의 처리
 그렇다면, 다수의 Game Object를 제작, 수정, 확장을 하기 위해서는
 많은 수의 Designer들이 데이터를 만들고, 게임에 넣어보고 테스트 해보려면, 결국 Data-Driven으로…
○ Object-centric으로 처리한다면, Designer가 객체(Class)를 정의한다.
○ Property-centric으로 처리한다면, Designer는 Data Table을 정의한다.
 Server/Client의 로직이 분산된다?! 즉, Behavior가 나뉜다.
○ Object-centric으로 처리한다면, Server/Client에서 사용할 모든 attribute들과 behavior들을 모두 정의해야 한다.
 서버용 객체와 클라용 객체를 따로 정의?!
 물론 Component를 통해서, 선택적으로 가질 수는 있겠다.
○ Property-centric으로 처리한다면, Server/Client가 사용할 모든 attribute들을 Data Table안에 모두 집어 넣고,
Server/Client용 Property를 구분하여, Data Table에서 Data를 선택적으로 사용한다.

26. Next Generation
 아직은 게임 엔진에서 Game Play System은 하나의
게임의 성격으로 표현된다.
 결국, 게임 엔진에서 Game Play System과 Scripting
은 좀 더 범용적으로 다양한 게임의 성격을 표현할
수 있고, Artist/Designer들은 이런 기반 위에서 다양한
게임 데이터를 빠른 속도로 뽑아낼 수 있도록 발전할
것이다.
 C#과 .Net

27. 결국은
 여전히 랜더링 엔진, 물리 엔진, 사운드 엔진, 네트워크 엔진 등의
SubSystem은 매우 중요하다.
 거기에 Game Play System을 어떻게 쌓을 것인가도 매우 중요.
 Data-Driven은 반드시 기반이 되어야 하지만, 어떤 부분을 Data-Drive할
것인지 선택이 중요.
 결국, 어떻게 하면 팀 간 혹은 영역간의 병목을 없앨 수 있을 것인가? 가
중요. (반드시 기술이 필요한 것은 아니다.)
 즉, Pipeline을 어떻게 설계하느냐도 매우 중요.
 좋은 게임 엔진을 만들려면?

28. Reference
1. www.gameenginebook.com
2. www.udk.com
3. gdc09-statescripting-uncharted2.pdf
4. http://flohofwoe.blogspot.com/(Nebula3)

29. Q&A