East Agent's Blog

Nebula2 엔진의 스크립트 시스템에 대한 다이어그램


아래 내용은 Nebula2의 스크립트 시스템의 함수 바인딩 방법에 대한 것이다.


우선 스크립트 시스템의 가장 기본적이면서도 중요한 처리는 게임 엔진의 클래스 객체의 멤버 함수를 호출하는 일이다.

위의 그림은 이에 대해서 Nebula2 엔진의 스크립트 시스템에서의 메카니즘을 나타낸 다이어그램이다. 설명은 다음과 같다.

1) 게임 엔진의 클래스들 중에서 스크립트(맨 아래쪽)에서 엔진의 API를 호출할 수 있도록 하려면 nRoot 클래스를 상속받아야 한다.

2) 스크립트 언어에 독립적인 소통 방법이 필요하다. 바꾸어서 이야기하면 어떤 스크립트 언어(Tcl, Python, Lua, Ruby 등...)를 사용하던지 간에 같은 방법으로 게임 엔진의 API를 호출하는 방법이 필요하다. (스크립트 언어가 바뀌는 경우 모든 관련 시스템을 다 바꾸어야 한다면 곤란하지 않은가)

3) 스크립트 서버는 게임 엔진과 스크립트 사이의 중간에서 상호 소통을 위한 동시 통역사의 역할을 한다.

4) 함수 호출에 대한 처리는 nCmd 클래스로 처리한다. 함수 호출을 위해 알아야 할 내용은 리턴값, 각 인자의 개수, 인자별 데이터형(type), 함수 포인터가 있다. nCmd 클래스 객체의 인스턴스는 이 정보를 가진다. nRoot 클래스를 상속한 클래스는 스크립트 인터페이스 함수의 개수에 따라 복수개의 nCmd 클래스를 가진다. 스크립트 인터페이스 함수란 nRoot 클래스를 상속한 클래스의 멤버 함수 중에서 스크립트 코드에서 호출할 수 있도록 만든 함수를 말한다.

5) 멤버 함수의 인자의 실제 값은 nArg 클래스에 저장된다.

6) 원으로 그래진 도형들은 색상을 주의 깊게 볼 것. nRoot 클래스의 멤버 함수들 중에서 스크립트 인터페이스를 가지는 멤버함수들은 이에 대응하는 각각의 nCmd 클래스가 있고, nCmd 클래스는 대응하는 멤버 함수가 가지는 인자의 개수만큼 nArg 클래스의 인스턴스를 가진다.

7) 그러면, 왜 nArg 클래스를 사용해서 인자를 처리할까라는 의문이 생긴다.(이런 의문이 저절로 생겨야 한다 -_-)

8) 대부분의 스크립트 언어에서는 데이터의 형 검사가 엄격하지 않다. 설사 데이터형을 구분한다고 하더라도 C++과는 다른 것이 보통이다. 이를 위한 universal[1]한 데이터형이 필요한데 이것이 바로 nArg 클래스이다.





[1] universal - 적절히 번역할만한 단어가 떠오르지 않는군요...-_-;

@ Property와 Reflection, 그리고 이를 다시 툴 프로그래밍에까지 연결시키는 설명이 뒤따르는데 시간 관계상 주말에는 여기까지 옮깁니다.

@@ 요점만 간추렸는데 Nebula2 스크립트 시스템을 코드를 찾아 보면서 이해하려니 힘들다는 분들에게는 조금이나마 도움이 되었을려나요. ^^

여기에서는 네뷸라 엔진이 다른 엔진과 구별되는 특징이 무엇이며 게임 엔진으로서 네뷸라 엔진이 어떻한 것들을 처리하고 있는지에 대해서 이야기하고자 합니다. 단, 자세한 기능들에 대한 이야기가 아니라 큰 범주내에서의 기능들의 분류에 대해서 살펴 보고자 합니다.

RadonLabs에서는 네뷸라 엔진을 게임 제작을 위한 OS(Operating System)이라고 이야기하고 있습니다. 먼저 게임 엔진과 게임 프레임 워크와의 관계에 대해서 살펴 보겠습니다.

OS(operating system) 없이 컴퓨터를 사용하는 사람은 없습니다. 그리고 OS만 설치해서 사용하고 있는 사람도 없습니다. 우리가 컴퓨터를 사용해서 원하는 일을 하기 위해서 다양한 프로그램(Application)이 필요합니다. 이러한 프로그램들은 하고자 하는 일에 따라 매우 다양합니다. OS는 기본적인 목적은 이러한 프로그램들을 사용하기 쉬운 환경을 사용자에게 제공하는 것입니다. 이렇게 보면 OS와 응용 프로그램의 관계를 다음과 같이 볼 수 있습니다.

• Game Engine-> Operating System

• Game Framework -> Application

게임 제작을 위한 모듈을 통칭해서 게임 엔진이라고 이야기하지 않고 게임 엔진과 게임 프레임 워크를 분리하고 있다는 사실에 주목하기 바랍니다.

네뷸라를 게임을 위한 OS라고 이야기하는 것은 일반적인 OS에서 제공하는 메모리 관리, 파일 시스템등의 서비스를 네뷸라 엔진 역시 제공하고 있다는 점입니다.

네뷸라 엔진의 기본적인 목적은 보다 쉬운 게임 개발을 위한 환경을 제공하는 것이지, 특정한 게임 개발을 위한 모든 툴과 모듈을 제공하는 것이 아닙니다. 다른게 이야기하자면 RAD 툴이 아니라는 이야기입니다.
게 임 제작에 필요한 툴과 모듈은 만들고자 하는 게임의 장르(RPG, FPS 등)에 따라서 많은 차이가 있습니다. 이야기할 필요도 없는 것이지만, 공개된 퀘이크 엔진이 FPS 게임을 만드는데에는 적합한 툴과 모듈을 가지고 있지만 이 엔진으로 던전 시즈와 같은 게임을 만들려면 많은 부분을 수정하고 필요한 툴을 새로 작성해야 할 것입니다. 즉, 특정한 장르에 맞추어서 게임 엔진을 개발하게 되면 해당 장르의 게임들을 개발할 때에는 강력한 성능을 발휘할지 모르겠지만 다른 장르의 게임 개발에는 적합하지 않다는 것입니다. (하지만 메쉬(mesh) 렌더링이나 텍스쳐 파일의 관리등과 같은 상대적으로 로우 레벨에 해당하는 부분은 범용적인 코드의 작성을 고려할 수 있습니다.)

네뷸라 엔진은 특정 장르의 게임에 상관없이 재사용할 수 있는 코드 베이스로서의 엔진이라는 것입니다. 이러한 이유로 네뷸라 엔진은 엔진의 코어 부분과 게임 프레임워크 부분을 엄격히 구분하고 있으며, 코어 부분이 바로 게임 장르에 상관없이 범용적으로 재사용 가능한 코드의 집합입니다. 예를 든다면 Direct3D와 같은 렌더링 API나, 오디오 API등의 로우 레벨의 처리를 담당하는 코드들이 여기에 해당하는 것들입니다.

네뷸라 엔진은 OS 시스템에 해당하는 부분의 모듈을 제공하는 것이 특징입니다. 다르게 이야기 하자면 이 부분에 해당하지 않는 부분은 사용자가 직접 작성해야 하는 것을 의미합니다. 게임 개발을 위해서 모든 팀원들이 윈도우즈는 공통적으로 설치하겠지만 윈도우즈를 설치한 다음 프로그래머는 VC와 같은 컴파일러를 설치하고 그래픽 디자이너는 포토샵이나 3DS Max등과 같은 그래픽 툴을 설치하는 것과 같은 이치입니다.

같은 RPG의 장르이더라도 던전시즈와 NWN(NeverwInter Nights)은 다소 차이는 있겠지만 공통된 장르라는 특성상 유사하게 구현할 수 있는 부분이 많을 것입니다.(물론 실제로는 전혀 다른 제작사의 개발자들에 의해 개발되었으므로 같은 부분이 없겠지만 말입니다)  이렇게 (모든 게임에 범용적으로 사용할 수는 없더라도) 유사한 장르의 게임들에는 재사용이 가능한 부분들의 집합을 생각해 볼 수 있는데 이것이 바로 일명 코드 네임 Mangalore로 통칭하고 있는 Game Framework으 로 Mangalore에는 게임 객체를 위한 Entity 시스템이나 충돌 검출을 위한 모듈, 물리 엔진, 메시지 시스템등을 포함하고 있습니다. Mangalore에 대해서는 추후에 (기회가 된다면) 다른 지면을 통해서 자세하게 언급할까 합니다.

장르나 특징에 상관 없이 모든 게임 제작에 적합한 게임 엔진은 누구나 원하는 것일지는 모르겠지만 현실과는 거리가 멀어 보입니다.

네뷸라의 구조에 관한 글은 여기에서 볼 수 있습니다.
(계속...)