East Agent's Blog

멀티 코어는 여러 개의 쓰레드를 사용하게 된다. 이런 환경에서 가장 문제가 되는 것은 공유 데이터에 대한 접근 방법이다. 물리 시스템이 하나의 쓰레드를 사용하고 렌더링 시스템 역시 쓰레드를 사용하여 분리한 경우를 보자.

게임 루프에서 충돌이 일어난 후 물리 시스템은 충돌 이벤트에 대해서 게임 객체의 새로운 위치를 계산한다. 그리고 렌더링 시스템에서는 갱신된 새로운 위치 데이터를 사용하여 게임 객체를 렌더링한다. 그런데 이들 두 시스템이 각각의 쓰레드로 분리되어 실행되고 있다는 점이다.

일반적인 방법으로는 lock을 사용한다. 물리 시스템에서 게임 객체의 위치를 갱신하기 전에 다른 시스템에서 이 데이터에 접근하지 못하도록 lock을 건 다음 데이터를 갱신한다.

그런데 이 lock의 오버헤더가 만만치 않다. 또 이런 식으로 lock/unlock을 사용하면 전체 시스템이 복잡해지는 것은 두말할 필요도 없다. 행여 실수로 lock/unlock을 빠뜨리는 경우 시스템은 예기치 않은 오동작을 하게 된다. 더 큰 문제는이 문제가 바로 쓰레드와 관련한 문제라는 것이다. 복잡한 시스템에서 쓰레드의 문제는 해결하기가 매우 어려운 경우가 대부분인데다 심지어는 재앙을 초래하기도 한다.

그럼, 쓰레드를 사용해서 동시에 여러 개의 시스템을 실행할 때 이들 시스템 간의 데이터 공유 문제에 해결에는 어떤 방법이 좋을까?

바로 데이터를 복사하는 방법이다. 이것은 시스템이 서로 다른 시스템의 데이터에 접근하는 방법이 아니라 각 시스템이 시스템 내부에 공유 데이터의 복사본을 가지고 있고 메시지를 통해서 다른 시스템에 자기 시스템에서의 공유 데이터의 변경을 알리는 방법이다.

쓰레드 A에서 쓰레드 B의 함수를 바로 호출하는 방법도 사실은 다른 시스템의 데이터에 lock을 통해서 바로 접근하는 방법에 속한다. 메시지를 통해서 공유 데이터를 복사하는 방법은 이러한 lock을 사용할 필요가 없거나 혹은 최소한의 lock이 필요할 따름이다. 메시지는 특별한 형태가 아니라 일반적으로 알고 있는 바와 같이 다음과 유사한 형태로 처리할 수 있다.


일전[1]에 망갈로 게임 프레임워크의 메시지 시스템의 장점 중에 하나로 멀티 코어 시스템에 편리하다고 이야기한적이 있었는데 바로 이런 이유에서다. 또 이렇게 메시지를 사용하게 되면 각 시스템을 서로 완전히 분리(decoupling) 시킬 수가 있는데 이것 역시 멀티 코어를 사용하여 각 시스템들을 동시에 실행시킬 때에는 매우 중요한 것 중의 하나이다.

컴포넌트 방식의 게임 프레임워크[2]에서 컴포넌트 간의 통신에 메시지를 사용하게 되면 이처럼 멀티 코어 환경에서도 잘 작동하는 유용하고 견고한 시스템의 설계가 가능하다.


[1] KGC 2008, Nebula2 Mangalore Game Framework에서
[2] GPG6, Component based Game Framework Library


...이렇게 메시지를 사용하게 되면 이제 메시지 전달의 순서에 대한 문제가 대두됩니다. 무슨 말이냐 하면 물리 시스템의 위치 메시지는 렌더링 시스템의 위치 메시지보다 먼저 처리되어야 합니다. 바꾸어 말하면 물리 시스템에서 계산된 위치 데이터를 계산한 다음 이 메시지가 렌더링 시스템에 전달되어야 순서에 맞습니다다. 이 부분은 또 다음에... ^^

망갈로 관련해서 작년 7월에 작성하고 마무리 못하고 비공개로 해 놓은 글이 하니 있군요. 망갈로의 리플렉션과 관련한 내용은 자세하게 정리가 된 글이 있지만 공개 여부는 아직 모르겠습니다. 우선 이전의 비공개글들을 하나씩 정리해서 공개하는 차원에서 포스팅합니다.

Reflection of Mangalore

게임과 관련한 리플렉션에 대한 글은 GPG 5권의 "Using Templates for Reflection in C++"에 나와 있지만 기본 지식이 없는 사람이 이해하기는 다소 어렵다고 느껴집니다. 또 핵심만 이야기해 놓은 것도 아니구요.

개인적으로는  Detlef Vollmann의 "Metaclasses and Reflection in C++"이 처음 접하는 사람도 쉽게 이해할 수 있는 글이라 추천하고 싶네요.

약간 길다고 느껴지면 GDMag 2007년 12월에 소개된 Mick West의 글이 있습니다. 온라인상에서 볼 수 있는지는 모르겠지만 소스는 여기에서 구할 수 있습니다.

그리고 Insomniac의 Nocturnal Initiative 프로젝트의 ToolFramework라는 것도 있습니다. 리플렉션과 관련해서는 실전 종합편이랄까요. 툴 프레임워크지만 게임과 관련해서 프레임워크에 대한 의미도 한번 되새겨 볼 수 있는 오픈소스 라이브러리입니다.

새로운 기술을 개발하고 이를 정의한 아키텍쳐에 맞추어서 프레임워크로 발전 시키는 것이 소프트웨어 개발사의 바람직한 모습이라고 할 때 Nocturnal Initiative 프로젝트야 말로 이러한 개발의 모범 사례가 아닐까요.

박PD님의 KGC 08 후기입니다.로부터 트랙백

* 원문 덧글에서 이야기한 바와 같이 코드에 대한 내용은 망갈로 코드의 설명 문서의 부분 공개를 고려 중입니다.

* 이 방식이 OOP를 대체한다고 하면 의미가 달리 해석될 요지도 있어 보여서 부연 설명을 드리면, 게임 개발이라는 소프트웨어 개발 분야는 형상 변경이 매우 잦은 특징 때문에 객체들을 모델링하는 방법으로 "상속"은 부적합하다라는 것입니다.

* 디버깅 이야기는 다른 블로그에도 덧글로 올린 내용이지만, 방법에서 기인된 문제라기 보다는 익숙하지 못함에서 나온 문제라고 봅니다. 개인적으로는 전체 메시지 구조를 파악한 다음부터는 크게 어렵지 않았으니까요. - 그런데 쓰면서 가만히 생각해보니 주위에 컴포넌트 방식을 적용해 보신 분들도 메시지 시스템을 함께 사용하신 분들은 보지를 못했는데 그러면 구체적으로 어떤 점이 디버깅할 때 어려웠는지 의문이 드는군요. (갸우뚱)

* 여기 블로그에도 짧은 글이나마 생각나는대로 조금씩 관련된 글을 포스팅할테니 궁금하신 분들은 구독을...^^;

오늘 메일 박스의 sweng-gamedev 메일링 리스트에서 "Responsibilities in a component system"의 컴포넌트 시스템에 대한 질문이 올라 온 것을 보고 생각난 김에 몇자...

Mangalore의 사용시 해당 게임 플레이와 관련된 코드에만 집중하면 된다. (Mangalore는 컴포넌트 기반의 게임 객체 시스템을 포함한 게임 프레임워크이다. 다시 말하면 게임 프레임워크는 게임 객체 시스템을 포함하는 보다 큰 개념이다)

Mangalore의 소스 디렉토리는 다음과 같이 구성되어 있다.

• application - 응용 프로그램 프레임워크
• attr - 속성
• audio - 사운드 처리 관련 모듈
• bldfiles - 빌드 파일들이 저장되어 있다.
• cegui -  CEGUI 관련 모듈, 커뮤니티 코드 베이스에만 포함되어 있다.
• ceui - CEUI 사용자 인터페이스 라이브러리
• db - 객체의 Attribute, 데이터베이스 시스템
• fundation - RTII, Reference Count
• fsm - 유한 상태 기계(finite state machine)
• game - 기본적인 게임 로직 관련 기반 모듈
• graphics - 그래픽 처리
• input - 사용자 입력
• lib - ODE, opcode 등의 외부 라이브러리가 있는 폴더.
• loader - 각종 게임 데이터 카테고리별 로더 모듈.
• manager s - 매니저 클래스, 게임 엔티티의 생성, 저장 등.
  
• message - 메시지 전달 시스템과 관련한 모듈.
• msg - 프로퍼티 간에 전달되는 게임 메시지들을 정의.
• navigation - 웨이포인트(way-point) 및 네비게이션 메쉬 등과 같은 길찾기 관련 모듈.
• ode - 물리 엔진인 ODE의 헤더 파일들이 있는 폴더.
• opcode - 충돌 라이브러리인 opcode의 헤더 파일들이 있는 폴더.
• physics - 물리 처리를 위한 모듈
• properties - 게임 엔티티의 프로퍼티 클래스 파일들이 있는 폴더.
• script - 스크립트 모듈
• tools - 툴 모듈
• ui - 사용자 인터페이스 모듈
• util - 유틸리티 모듈.
• vfx - 카메라 흔들기(shaking)과 같은 특수 효과 관련 코드
• viewer - 망갈로 뷰어.

properties 디렉토리는 게임 엔티티 클래스의 property 클래스들을 포함하고 있는데 Mangalore에서는 이 property가 바로 컴포넌트이다. 실제로 개발시에는 어떤 property들을 조합하며, 어떤 property들을 만들어야 할까에 대해서 고민하는 일이 대부분이다.

코드의 재사용과 프로세스의 복잡도에 컨트롤을 극대화 시킬 수가 있다.

이것을 팀 프로젝트 레벨에서 보면 새로운 컨텐츠 개발은 임의의 개발자가 상속등의 방법으로 기존의 프로퍼티를 확장하거나 새로운 프로퍼티를 생성하는 일이 된다.

이 때 중요한 것이 메시지 시스템이다.

각 프로퍼티들은 완전하게 디커플링되어 있다. 바꾸어 이야기하면 A 프로퍼티에서 B, C와 같은 다른 프로퍼티의 헤더 파일을 포함(include)하지 않는다. 프로퍼티 간의 통신은 오로지 메시지를 통해서만 이루어진다.

그러므로 새로운 컨텐츠의 개발은 프로퍼티에 대한 처리와 함께 메시지도 고려가 되어야 한다.

딱 요만큼이다. 새로운 컨텐츠를 추가할 때 신경 써야 할 내용들은.

게임이 복잡하더라도 전체에 대해서 신경 써야 할 필요가 없다.

3년간 개발하고 4년간 서비스한 MMORPG 게임이 있다고 가정하자.

새로운 개발자가 입사했다. 입사 전에는 한번도 이 게임을 접해 보지 않았기 때문에 몇 주간 게임을 플레이해 보고 기본적인 시스템을 이해했다. 물론 이 기간 동안 회사 시스템에도 익숙해 졌으리라.

그럼 이제 본격적으로 일을 시작해야 한다.

그런데,

라이브 중인 게임의 컨텐츠를 개발하는 일을 위해서 총 7년간 만들어 낸 코드를 다 이해해야 한다면?

물론 현실이야 이렇게 극단적이지는 않지만,

전체 코드가 마구 뒤엉켜 있다면?

수 십명이 동시에 코드 여기 저기를 휘저으며 작업하고 있다면?

새로 온 신참 입장에서는 한라인 한라인 작성하는 일이 지뢰밭일거다.

이 복잡도를 조절할 수 있는 시스템을 갖추지 못한다면 시간이 지날 수록 개발에 대한 비용은 기하급수적으로 증가하게 된다.

추가된 다른 컨텐츠와의 상관 관계, 복잡도 증가에 따른 QA 비용 증가, 숙련된 엔지니어의 고용 필요성 등으로...

MMORPG라는 단어에는 이미 이 '복잡도'에 대한 내용이 상정되어 있다.

혁신이나 효율, 생산성, 비용 절감...

입은 이런 것들을 이야기하면서 눈은 렌더링, 쉐이더 등과 같은 아이 캔디(eye candy)에 고정되어 있으면 안된다는 말이다. ^^

- 리플렉션(Reflection)이란 무엇인가?

- 실제 게임에서는 리플렉션을 어떻게 응용할 수 있는가
   XML 파일을 이용한 직렬화(serialization)
   네트워크를 통한 클래스 객체 전송

리플렉션을 위해 필요한 것
    1) RTTI
    2) Attr

RTTI

C++에서 제공하는 기본 RTTI를 사용하지 않고 직접 커스텀 RTTI 를 작성하는 이유는 퍼로퍼티 시스템 작성을 보다 간단하게 할 수 있는데다 확장도 용이하다. 그리고 리플렉션에 최적화된 코드를 작성할 수 있다는 장점도 있다.

망갈로의 RTTI 시스템은 다음의 내용을 포함한다
  - 클래스 이름
  - unique ID

Attr 객체

영속성(persistence)이 필요한 클래스 멤버들은 Attr 객체를 이용해서 정의한다.

 
참조
[Dominic]Dominic Filion, Artificial Mind & Movement, Using Templates for Reflection in C++, Game Programming Gems 5

@

일반적으로 Property라고 이야기하지만 망갈로에서는 이 프로퍼티(Property)가 속성(Attribute)으로로 컴포넌트(Component)를 Property로 이름 지어서 헷갈리는 것이 흠.