game play system
TRANSCRIPT
Introduction Data-Driven 의 의미를 알아보자 . 결국 게임 엔진의 전체 아키텍처와 발전
방향 2008 년도에 KASA 모임에서도 Entity-
Component 에 대해서 이야기 한 적이 있지만 , 여전히 어려운 이야기 !
특히 , 국내 엔진에서는…
Introduction Game Engine Architecture
책에 나와 있는 내용을 통하여 , Game Engine 에서 지원하는 Game Play System 에 대해서 , 알아본다 .
Contents Game Object Models Data-Driven Game Engines Runtime GamePlay System
Runtime game object modelReal-time object model updatingMessaging and event handlingScripting
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 마다
다양 )
Data Driven Game En-gine Game 의 behavior 가 programmer 들에 의해
독점적으로 생산된 software 보다는 artist 들이나 de-
signer 들에 의해 제공되는 data 에 의해 전체 혹은 일부분이 컨트롤될 수 있을 때 , data-driven 이라고 말한다 .
Iteration times 를 향상 시킬 수 있다 .
World Editor 나 Tool 의 형태로 반드시 , Designer 나 Artist 들에게 제공 되어야 한다 .
Tool Architecture
일반적인 형태Run-Time Engine 을 다루는 사람은 Programmer,
Tools/World Editor 를 다루는 사람은 Artist/De-signer.
Core System
Run-Time Engine Tools and World EditorData
Tool Architecture
새로운 Data를 추가하고 싶다면 , Programmer가 Game과 World Editor에 모두 새로운 Data에 대한 Type과 기능을 추가해주어야 한다 . Game 에서 사용하는 Data Type 과 World Editor 에서 사용하는 Data Type 은 같지만 , 다르다 .
병목 발생 !!! Programmer 의 도움이 항상 필요하다 .
Core System
Run-Time Engine Tools and World Editor Data Type
Data Type
Tool Architecture
Run-Time Engine 을 기반으로 World Editor 를 만든다면 , Run-Time Engine
에서 Data 의 Type 을 정의하면 , World Editor 에서 사용이 가능하다 .
새로운 Data 의 Type 을 추가할 필요가 있더라고 하더라도 , Run-time Engine 에 추가하면 , World Editor 에서 바로 사용이 가능 .
Runtime engine 위에 Editor 가 있기 때문에 , 수정된 결과를 바로 게임 플레이가 가능하고 , Editor 가 Game 의 일부가 될 수 있다 .
Core System
Run-Time Engine
World Editor
Tools
Data Driven 결국 Data-Driven 을 구현 한다는 것은
Run-time Engine 안에 Data Type 의 추가 / 제거를 통해서 , Game Object 의 Type 을 정의하는 것을 말한다 .
어떻게 ?Unreal 의 사례
Data Driven 문제점
많은 팀들은 자신들의 게임에 필요한 특화된 feature 들의 개발과 연구를 멈추고 , data-driven architecture 로 미친듯이 달려들게 만들었다 . 하지만 , 이런 급함이 , 복잡한 tool 과 engine system 을 만들게 되고 , 결국 , hard-coded 방법들보다도 더 낮은 생산성이 발생 !
즉 , 모든 game engine 은 Data-driven component 들을 가져야 하지만 , data-drive 하기 위한 engine 의 면을 선택하고자 할 때 , 매우 주의깊게 처리해야 한다 .
사례 ?!
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,
Object-Centric Game Object를 하나의 Class(Object)로 표현 일반적으로 사용하는 형태 문제점
다중 상속의 문제점 Bubble-Up Effect
계층으로 단순화 하기 위해서 , “Is-A”를 “Has-A”로… 상속관계를 하나의 기능 Component로 만들고 , Game Object는 여러 개의 Component들을
가질 수 있다 .
Unreal’s Actor Class
통신 객체 단위의 통신은 특정 객체의 메써드를 직접 호출 하는 것이 가능하기 때문에, 주로 함수 호출
형태로 이루어 진다 .
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를 이용한 호출이 일반적 !!!
Object Type Schema Game Object 의 attribute 들과 behavior 들은 G.O 의 type 에
의해 정의된다 . game world editor 에서 , game object type 은 at-
tribute 들의 모음을 정의한 data-driven schema 에 의해 표현된다 .
Type schema 들은 world editor 에 의해 사용되기 위해 단순하게는 text file 로 저장될 수도 있고 , Script 등 여러 형태로 저장할 수 있다 . 사용자에 의해 편집되고 Inspection…
Data management 관점에서 보면 , serialized object format 이나 정의된 pointer 를 가지는 binary object image 로 관리되는 것보다 key-value 의 table 로 처리되는 것이 훨씬 심플하다 .
간단한 예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에서 사용}
간단한 예 Object-centric 은 Object Type 을 Class 를 통해서 ,
정의 .
Property-centric 은 Object Type 은 Object Type Id와 Data 의 Table 로 정의 되기 때문에 , 관계 형 데이터베이스의 형태로 표현
Scripting Game Object 의 Behavior 를 정의 Game Scripting language 들을
일반적으로 아래 두 가지로 잘 사용됨Data-definition languagesRuntime scripting languages
Interface with the Native Programming Language
Script 와 native code 의 쌍방향 통신을 가능 . 대부분의 scripting language 는 native code 가 script 에 의해 invoke되는 것이 가능 .
기본적으로 특정 script function 들은 script language 안에서 보다 native lan-guage 안에서 구현되는 것이 일반적이다 .
Game Object Handles Script function 들은 engine 의 native language 에서 구현된
Game Object 와 상호작용이 필요하다 . Native language 의 referencing object 들에 대한 mechanism(pointer 등 ) 은 Script-
ing language 에서는 사용할 수 없다 .
Handle 을 사용 (Numeric, String)
Script 는 매개변수로 object 의 handle 을 넘겨서 native func-
tion 을 호출함으로서 game object 에서 operation 을 수행할 수 있다 . Native code 에서는 handle 을 다시 native object 로 변환하여 처리 .
Receiving and Handing Events
엔진의 성격에 따라 , Object Type 별로 scripted event
handler 들을 가지거나 , Object Instance 들 별로 scripted
event handler 를 가진다 .
각 script 는 여러 상태를 가질 수 있다 . (Uncharted en-
gine 에서는 script 들은 FSM 들이다 .) 각 상태는 하나 이상의 event handler 들을 가질 수 있다 . Game Object
가 이벤트를 받았을 때 , 각 상태는 native C++ 에서 선택적으로 event 를 처리할 수 있다 .
Script 의 사례 gdc09-statescripting-uncharted2.pdf 문서를 통해서 ,
Uncharted 의 스크립트 사용 사례를 볼 수 있다 . Unreal’s Script 의 사례
Script 는 Game Object 의 하나의 Component 혹은 Property 로 연결할 수 있으며 , Game Object 안의 한 부분으로 Update 및 Event 처리가 가능하다 .
정리 Data-Driven Game Object
AttributesBehaviorsObject-centricProperty-centric
World Editor
More… 결국 Game Engine 에서 Game Play Foundation
이 어떻게 만들어 졌느냐가 게임의 성격을 판가름 . 아니 , 어떤 게임의 성격을 가졌느냐에 따라 , Game
Play System 을 만드는가 ?
Ex) Unreal 의 성격소수의 Game Designer/Artist 가 게임을 제작하고 ,
테스트하는데 강력한 느낌 .
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를 선택적으로 사용한다 .
Next Generation 아직은 게임 엔진에서 Game Play System 은 하나의
게임의 성격으로 표현된다 .
결국 , 게임 엔진에서 Game Play System 과 Scripting은 좀 더 범용적으로 다양한 게임의 성격을 표현할 수 있고 , Artist/Designer 들은 이런 기반 위에서 다양한 게임 데이터를 빠른 속도로 뽑아낼 수 있도록 발전할 것이다 . C# 과 .Net
결국은 여전히 랜더링 엔진 , 물리 엔진 , 사운드 엔진 , 네트워크 엔진 등의 SubSys-
tem은 매우 중요하다 .
거기에 Game Play System 을 어떻게 쌓을 것인가도 매우 중요 . Data-Driven은 반드시 기반이 되어야 하지만 , 어떤 부분을 Data-Drive할 것인지
선택이 중요 .
결국 , 어떻게 하면 팀 간 혹은 영역간의 병목을 없앨 수 있을 것인가? 가 중요 . (
반드시 기술이 필요한 것은 아니다 .)
즉 , Pipeline을 어떻게 설계하느냐도 매우 중요 .
좋은 게임 엔진을 만들려면 ?
Reference1. www.gameenginebook.com
2. www.udk.com
3. gdc09-statescripting-uncharted2.pdf
4. http://flohofwoe.blogspot.com/(Nebula3)
Q & A