Game Play System
Upcoming SlideShare
Loading in...5
×
 

Game Play System

on

  • 953 views

 

Statistics

Views

Total Views
953
Views on SlideShare
952
Embed Views
1

Actions

Likes
1
Downloads
2
Comments
0

1 Embed 1

http://blog.naver.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Game Play System Game Play System Presentation Transcript

  • 20100221 이창희 In kasa Blog: cagetu.egloos.comE-mail: cagetu79@gmail.com
  • 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 model  Real-time object model updating  Messaging and event handling  Scripting
  • 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 Engine Game의 behavior가 programmer들에 의해 독점적으 로 생산된 software보다는 artist들이나 designer들에 의해 제공되는 data에 의해 전체 혹은 일부분이 컨트 롤될 수 있을 때, data-driven이라고 말한다. Iteration times를 향상 시킬 수 있다. World Editor나 Tool의 형태로 반드시, Designer나 Artist들에게 제공 되어야 한다.
  • Tool Architecture Data Run-Time Engine Tools and World Editor Core System 일반적인 형태  Run-Time Engine을 다루는 사람은 Programmer, Tools/World Editor를 다루는 사람은 Artist/Designer.
  • 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의 도움이 항상 필요하다.
  • 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의 일부가 될 수 있다.
  • 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 ModelArchitectures 결국 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은 attribute 들의 모음을 정의한 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 languages  Runtime scripting languages
  • Interface with the NativeProgramming Language Script와 native code의 쌍방향 통신을 가능. 대부분의 scripting language는 native code 가 script에 의해 invoke되는 것이 가능. 기본적으로 특정 script function들은 script language 안에서 보다 native language안에 서 구현되는 것이 일반적이다.
  • 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로 변환하여 처리.
  • 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를 처리할 수 있다.
  • Script의 사례 gdc09-statescripting-uncharted2.pdf 문서를 통해서, Uncharted의 스크립트 사용 사례를 볼 수 있다. Unreal’s Script의 사례 Script는 Game Object의 하나의 Component 혹은 Property로 연결할 수 있으며, Game Object 안의 한 부분으로 Update 및 Event 처리가 가능하다.
  • 정리 Data-Driven Game Object  Attributes  Behaviors  Object-centric  Property-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
  • 결국은 여전히 랜더링 엔진, 물리 엔진, 사운드 엔진, 네트워크 엔진 등의 SubSystem은 매우 중요하다. 거기에 Game Play System을 어떻게 쌓을 것인가도 매우 중요.  Data-Driven은 반드시 기반이 되어야 하지만, 어떤 부분을 Data-Drive할 것인지 선택이 중요.  결국, 어떻게 하면 팀 간 혹은 영역간의 병목을 없앨 수 있을 것인가? 가 중요. (반드시 기술이 필요한 것은 아니다.)  즉, Pipeline을 어떻게 설계하느냐도 매우 중요. 좋은 게임 엔진을 만들려면?
  • Reference1. www.gameenginebook.com2. www.udk.com3. gdc09-statescripting-uncharted2.pdf4. http://flohofwoe.blogspot.com/(Nebula3)
  • Q&A