Game Play System

  • 663 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
663
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
2
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 20100221 이창희 In kasa Blog: cagetu.egloos.comE-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 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,
  • 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 NativeProgramming 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. Reference1. www.gameenginebook.com2. www.udk.com3. gdc09-statescripting-uncharted2.pdf4. http://flohofwoe.blogspot.com/(Nebula3)
  • 29. Q&A