East Agent's Blog

Nebula 엔진의 데이터베이스 시스템에 대한 이야기.

이번에는 Nebula와 월드 에디터에 관한 이야기입니다. 아마도 Nebula 엔진에 관심 있는 분들이 가장 관심을 가지시는 내용이 아닐까라는 생각도 듭니다.

Gamasutra의 The Engine Survey: Technology Result을 읽다가 이 내용을 한번 언급해야겠다는 생각이 들었습니다.

일전에 Novodex와 관련한 3dsmax 플러그인 소스 코드를 찾을 수가 없다고 한 것은 바로 위의 링크에 나온 게임 월드 에디터 이야기 때문입니다. (이 이야기는 나중에 다시~)

The Engine Survey: Technology Result의 아래 부분에 보면 엔진 선택의 중요한 이유로 월드 에디터의 유무에 대해서 언급하고 있는데 글에서 이야기하고 있는 내용은 DCC 툴을 에디터로 사용할 수도 있지만 월드 에디터가 있는 것이 좋다라고 말하고 있습니다.

두 가지 방법의 비교에 흥미가 있는 분들은 Tom Forsyth의 블로그에서 "Game Editor vs DCC Ediotr"를 (꼮!) 읽어 보시길 권합니다.
(Tom Forsyth의 블로그는 위키 베이스라서 바로 링크를 걸 수가 없습니다. 부득이 해당 블로그로 이동하셔서 포스트 제목으로 찾거나 아니면  'Toolchain'의 태그를 검색해 보기 바랍니다)

자, 그럼 이제 원래 하려고 했던 Nebula 이야기로 돌아갑니다.

관심 있으신 분들은 잘 아시다시피 Nebula가 코드 레벨에서의 아키텍쳐 등 여러 가지 관점에서 상당히 훌륭한 엔진임에도 불구하고 상업적인 게임 개발의 예를 (국내에서) 찾아 보기 힘든 이유중 하나가 바로 이 월드 에디터의 부재가 아닌가 생각합니다.

RadonLabs에서 애초에 자사의 월드 에디터를 DCC 툴(마야입니다)을 사용하다 보니 인하우스 게임 에디터는 전혀 고려하지 않은거죠.(지금도 그런 이야기는 없습니다)

물론 커뮤니티에서는 이러한 필요성 때문에 다양한 시도가 있긴 했습니다...만 상당히 급진적이었다고 할까요, 결과는 안좋았습니다. 몇 가지 툴들이 시도되긴 했습니다만 상업적인 용도의 전문적인 게임 개발에 사용할 만큼 안정적이고 기능면에서도 부족함이 없는 Nebula 월드 에디터는 아직까지는 전무한 실정입니다.

그러면 RadonLabs처럼 DCC 툴을 에디터로 이용하는 것은 어떨까요. 이 경우 국내 개발사에서는 거의 3dsmax를 사용하니까 맥스를 에디터로 이용할 수 있는 방법이 필요합니다. 그래서 이번 포스팅에서는 3dsmax의 맥스 스크립트를 이용해서 맥스를 에디터로 이용할 때 유용한 한 가지를 이야기해 볼까 합니다.

월드 에디터라는 것이 사실 게임 엔티티의 배치가 가장 큰 기능이라고 할 때 맥스는 이미 이 기능이 잘 구현(^^)이 되어 있습니다. 그래서 이것을 적당히 엔진에서 읽을 수 있는 정보로 익스포트하기만 하면 되는데 이 때 가장 손쉬운 방법으로 XML이 있습니다. 게임 엔티티들의 정보를 XML로 익스포트하는 것이지요. 물론 맥스 스크립트를 사용합니다.

우선은 게임 엔티티의들 속성과 관련한 내용들을 맥스 스크립트의 custom attribute 기능을 이용해서 맥스 오브젝트들이 게임 엔티티의 속성을 가지도록 하는 작업이 필요합니다.

다음으로는 scene에서 이들의 정보를 XML로 저장하기만 하면 됩니다. 즉, 맥스 스크립트로 scene의 오브젝트들의 정보를 XML로 저장하는 유틸리티 플러그인을 하나 작성해야 하는데 이 방법이 바로 이전 포스트에서 이야기했던 http://www.melax.com/3dsmax/nxmax 의 플러그인 코드에 포함된  px_xmlutil.ms 스크립트 파일입니다.

제가  링크가 없어졌다고 이야기한 이유가 여기에 있었습니다. 그런데 링크를 찾아 주신 neojzs님 덕분에 소스 코드는 아래 링크에서 구할 수가 있답니다. ^^

http://www.feelingsoftware.com/content/view/72/109/lang,en/ (source code를 다운로드)

맥스 스크립트와 맥스의 Custom Attribute에 대한 이해가 있으면 px_xmlutil.ms의 코드를 보고 쉽고 빠르게 구현할 수 있는 내용입니다.

이 방법은 (당연하지만) Nebula에만 유효한 방법이 아니라 DCC 툴을 에디터로 이용하는 경우라면 모두 해당되는 내용입니다. MMO라면 무리가 따르는 방법이지만 캐쥬얼 게임이라면 고려해 볼만한 방법이죠. 특히 에디터 만들 시간 없을 때라면 더욱.

하드 정리하다 동영상을 하나 발견...보니까 예전에 Nebula2로 만들었다고 어디서 줏어 온 동영상인데 따라 가보니 People Can Fly의 프로그래머가 만든 것.

PhysX and Nebula Device

내 하드의 날짜를 보니 2006년 3월. 이 시기라면 망갈로가 없을 때 만든 것인데...이건 중요한 이야기가 아니고, 동영상에서 중요한 것은 카트의 움직임이다.

ODE로는 이런 움직임이 힘들다.(파라미터들 조정하려면 꽤나 삽질이 필요하다) 만들기도 까다롭고. 예제도 충분하지 않고. 아마 그런 이유로 PhysX를 사용했을지도...그리고 이 시기라면 아마 Novdex가 아직 nVidia로 인수합병 되기 전일터...

반면에 PhysX는 소스는 없지만 샘플도 충분하고, (물리 엔진의)초보라도 코드 보고 만들 수 있을 정도고, 대부분의 경우에는 ODE보다 안정적인 동작을 보여준다.

Nebula2, Nebula3는 물리 엔진으로 ODE를 사용하고 있는데 이것은 순전히 RadonLabs의 정책 탓인듯. (그런 메일을 Floh와 주고 받은 적이 있다. PhysX는 소스 없어 안쓴다고)

서드파티의 미들웨어 혹은 라이브러리는 반드시 소스 코드가 있는 것을 사용한다는 것이 그 정책. (사실 이것은 굉장히 중요한 내용이다. 상업적인 게임 개발을 위해서는 반드시라고 할 만큼.)

하지만 최근에 nvidia 사이트를 보면 (PhysX는 Nvidia로 합병되었다) DCC툴(3dsmax와 Maya)의 플러그인도 제공하니 (ODE는  공식적으로 이런 것이 없다 -_- Mangalore용 3dsmax script가 있긴 하지만 업데이트 안된지 좀 되기도 했고) Nebula2 (혹은 Nebula3)에서 PhysX를 사용하기를 원한다면 Mangalore의 ODE wrapper 클래스의 ODE API들을 PhysX API로 대체하면 된다. 그렇게 어려운 일은 아닐듯...

만약 소스 코드가 진짜로 중요하다면 (물론 PhysX의 소스 코드도 구할 수는 있다. 돈이 들 뿐~) Bullet Physics를 고려해 보는 것도 좋다. DCC 플러그인은 이쪽은 Collada. 또 이쪽은 소니 엔터테인먼트가 밀고 있으니 오픈소스 프로젝트라고 하지만 프로젝트의 진행과 서포트에 대해서는 그리 걱정하지 않아도 된다.

물리 엔진 자체도 중요하지만 전체 프레임워크에서의 이 시스템에 대한 인터페이스 부분을 유심히 살펴 보는 것도 의미가 있다. 무슨 말인고 하니 Mangalore 게임 플레이 프레임워크에서 바로 물리 엔진의 API를 호출하는 방식이 아니라 (PhysicsProeprty에서 ODE의 API를 호출하지 않는다!) 물리 엔진에 대한 래퍼 클래스들을 따로 두고 Property 에서는 래퍼 클래스의 멤버 함수들을 호출한다는 점이다. 이렇게 추상화하면 좋은 점은 물리 엔진이 변경되어도 애플리케이션쪽은 변경이 필요 없다는 점이다.

그런데 사실 어려운 것은 이 추상화의 문제다. 게임의 다른 시스템에서 물리 엔진에 대한 접근 방식을 잘 알고 있어야지 제대로 된 추상화가 이루어진다. 당연히 물리 엔진을 사용한 다양한 게임들을 개발해 본 경험이 있다면 제대로 된 래퍼 클래스들의 설계가 이루어지겠지만 그렇지 않은 경우 추상화는 하나 마나한 일이 될 터. 이런 점에서 Nebula2 Mangalore의 물리 엔진에 대한 래퍼 클래스는 잘 설계되어진 인터페이스를 포함하고 있다. 그래서 Nebula Device를 사용하지 않더라도 물리 엔진에 대한 추상화 클래스가 필요하다면 한번 쯤 참고해 보는 것도 좋을 듯 하다.

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

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

일반적인 방법으로는 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


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

류한석 소장님의 블로그에 좋은 글이 올라 왔네요.



1)과 2)에 대해서는 오픈 소스 프로젝트 때문에  많이 공감하는 부분입니다.

Nebula Device는 1)에 대한 내용은 엔진 자체가 보여주는 것이라서 쉽게 알 수 있는 부분이지만 2)의 경우에는 겉으로 드러나지 않아 쉬이 알 수 있는 부분은 아닌 것 같습니다. 어려움을 토로하시는 분들은 아마도 2)에 대한 부분이겠지요.

이 블로그도 2)에 대한 나침반 역할이 목적인데 아직도 부족함을 많이 느낍니다.

이전 포스팅에서 엔진 및 미들웨어 별 캐릭터 워크 플로우에 대해서 이야기한 적이 있습니다.

Nebula2에서는 하나의 애니메이션 파일에 캐릭터의 모든 애니메이션들이 포함되어 있어야 하므로 개발시 새로운 애니메이션 등이 추가될 때 번거로운 점이 있다고 언급했는데 최근에 소스 코드를 보다고 이미 그러한 부분에 대한 코드가 있다는 것을 발견했습니다. 코드는 업데이트 되었지만 부실한(?) 문서와 관련 샘플이 없는 관계로 눈치채지 못했던 것이지요.

Nebula2에서는 nSkinAnimator 대신 nCharacter3Animator 를 이용하면 애니메이션 파일들을 순차적으로 로딩하면서 병합하여 사용할 수 있습니다. 즉, 작업은 개별 애니메이션 파일이 수정되거나 추가될 때마다 지정된 폴더 내로 애니메이션 파일만 추가하면 되며, 엔진에서는 실제로 nCharacter3Animator의 애니메이션을 읽어 들일 때, 해당 폴더의 모든 애니메이션들을 차례로 읽어 들이면서 병합해서 새로운 애니메이션 데이터를 생성합니다. 나머지는 기존의 nSkinAnimator 와 동일하며 차이가 없습니다.

실제로 nCharacter3SkinAnimator::LoadResources() 함수를 살펴 보면 nCombinedAnimation 클래스로 메모리의 애니메이션 파일 객체들을 병합하는 코드를 볼 수 있습니다.

그런데 애니메이션 데이터의 용량이 큰 경우에는 아무래도 이런 방법으로는 처리가 힘듭니다. 이 경우에는 좀 더 지능적인 스트리밍이 필요한데, Nebula2에서의 리소스 관리는 스트리밍 부분은 지원이 약하죠. (Nebula3에서는 모든 리소스에 대한 스트리밍 지원이 기본적으로 지원됩니다)

 nCharacter2SkinAnimator 의 경우 현재 3dsmax 플러그인에서는 지원하고 있지 않습니다만 회사 일도 있고 하니 조만간 업데이트가 이루어지리라 생각합니다. ^^