객체 지향형 게임 디자인

(Object-Oriented Game Design)

모듈 방식의 로지컬 게임 디자인

브릿 한나(Britt L. Hannah)

2004-08-01

개요

고급 수준의 컴퓨터 게임을 제작하기 위해서는 상당히 큰 팀이 오랜

시간을 들여 일해야만 한다는 것은 잘 알려진 사실이다. 제작 팀에는

디자이너, 프로그래머, 애니메이터, 그래픽 아티스트, 음향 효과 아티스트,

그리고 물론 비즈니스 측면의 일을 맡는 사람 등이 포함된다. 프로젝트를

완성하기 위해서는 팀의 모든 구성원들이 고루 일을 맡아 해야 하지만

여러 가지 이유로 인해 소프트웨어 개발에 주로 많은 시간이 소요된다.

그러나 어떤 구상에서 완료까지 게임 프로젝트에 소요되는 시간을 줄이는

것이 불가능한 것은 아니라고 나는 생각한다.

나는 객체 지향형 프로그래밍 기법에 기반한 시스템을 이용하면 컴퓨터

게임 제작 방식을 혁신적으로 개선할 수 있다고 믿는다. 상속과

오버라이드 메쏘드를 잘 이용하고 베이스 클래스를 주의 깊게 디자인하면,

핵심적인 게임 구성요소들을 대단히 많은 용도에 쓸 수 있도록 만들 수

있다. 그리고 이들을 재사용 하는 것도 물론 가능할 것이다. 서로 아무

상관없이 생성된 각 개체들의 코드를 전혀 변형하지 않고도 함께

작동하도록 재사용할 수 있을 것이다. 그리고 고도로 최적화되고 상당한

시간이 소요되는 렌더링 코드에 최소한의 영향만을 주도록 효율적으로

만들 수 있을 것이다. 이러한 방법을 이용하면 개발자들에게 유연성,

환경설정 변경 가능성, 효율성, 그리고 궁극적으로는 게임 오브젝트를

제공할 수 있다. 이것은 개발 과정에서 상당한 시간을 절약할 수 있도록

할 것이다.

1

이러한 믿음 속에서, 나는 프로그래머들이 훨씬 더 효율적으로 일을 할 수

있도록 도와주는 객체 지향형 게임 개발 시스템을 디자인하는 데 상당한

시간을 투자하였다. 이 시스템은 아직 프로토타입 단계에 있지만, 중급

수준의 게임을 약 세 달 정도면 제작해낼 수 있는 성능을 갖추고 있다.

이것이 게임 개발에 가장 좋은 방법이라고 주장한다거나, 현재의

프로토타입에 결함이 전혀 없고 완전한 수준으로 작동한다고 말 할 수도

없지만, 세 달 만에 게임 개발을 완료할 수 있다는 가능성은 주목할만한

것이라고 생각한다. 그리고 이것을 현재 상태 그대로, 객체 지향형

시스템이 구현 가능하다는 나의 주장에 대한 증거로 제시할 수 있다.

최소한 이것을 게임의 프로토타입을 엄청나게 빠른 시간 내에 제작하는

데 사용할 수 있을 것인데, 그것만으로도 상당한 혜택이라고 하겠다.

게임 개발 과정

게임 프로그래머들에게 이 시스템의 핵심적인 부분이 낯설게 보이지는

않을 것이다. 어떤 게임 개발 시스템에서나 다음의 다섯 가지 소프트웨어

시스템이 필요하다: 디스플레이 시스템, 오디오 시스템, 입력 시스템,

퍼시스턴스 시스템, 커뮤니케이션 시스템. 그러나 나는 이들 시스템을

게임 자체의 한 부분이 아니라 게임이라는 응용 프로그램에서 사용되는

서비스라는 관점에서 접근하였다. 달리 말하면 이 시스템들이 게임과는

별도로 개발되었다는 것이다. 그림 1 에 보이는 바와 같이 게임 디자인

시스템은 필요에 따라 인터페이스를 통해 이 서비스들을 자유 자재로

사용할 수 있도록 되어 있다.

그림 1 은 아주 간단한 모델을 보여주고 있다. 그러나 동시에 이것은

드러나지 않는 많은 세부적인 사항들을 내포하고 있다. 여기서 핵심

서비스들 중의 하나로 커뮤니케이션 시스템을 주목할 필요가 있다. 만약

그림에서 나타내는 바와 같이 적절한 방법으로 커뮤니케이션 시스템이

구현되었다면 상당히 흥미로운 가능성을 생각해볼 수 있다. 네트웍

기능이 전혀 디자인에 포함되지 않고 또 구현되지도 않은 게임을 일단

만들고, 나중에 그 기능을 추가하는 작업을 할 수 있을 것이다. 이것은

2

현재의 기술로는 거의 상상할 수도 없는 일이다. 비록 완성된 것은

아니지만, 앞서 내가 언급한 프로토타입은 이것을 가능케 할 수 있다.

이것을 가능케 하는 것은 서로의 관계를 이해하는 것으로부터 출발한다.

그림에 표시된 각각의 핵심 서비스들은 게임과 특정한 릴레이션을 갖고

있다. 그림 1 에 나타난 바와 같은 제대로 된 게임 개발 시스템은 이들

릴레이션들을 이해하고, 어떤 게임이나 이 서비스들을 언제나 활용할 수

있도록 하는 것이다. 게임에서 갑자기 통신 기능이 필요해진다 해도 개발

시스템이 통신 서비스와의 릴레이션을 이해하고 있으므로 이 기능을

추가하는 데 별 어려움이 없다. 나는 이 글을 통해 어떻게 그런 개발

시스템이 작동하는지를 설명하고자 한다.

그림 1

그러면, 게임 개발 시스템이란 도대체 무엇인가? 무엇으로 구성되어

있으며, 어떻게 작동하며, 또 도대체 이것을 왜 사용하는가? 논의를

시작하기 위해서는 먼저 게임이 어떤 부품들로 구성되어 있는지를 잘

이해하여야 한다. 통상 프로그래머들은 이에 대해 일반적인 정의 없이 각

게임별로 이것을 달리 설명해왔다. 사실 대부분의 프로그래머들은 게임

오브젝트들을 극단적으로 특화된 것으로 본다. 이러한 관점은 그 구현

방법도 그만큼 특화된 것으로 되도록 만든다. 그러나 하나의 시스템으로

여러 개의 게임을 개발하려고 하면, 또 더 중요하게는 다른 종류의 게임을

3

개발하려고 한다면, 유연한 게임 디자인 시스템에 필요한 구성 요소가

무엇인지 생각해보아야 한다.

모든 컴퓨터 게임은 다음 다섯 가지의 기본적 오브젝트로 구성된다:

1. 게임 엔티티 오브젝트(Game Entity Object): 이것은 게임

토큰을 말한다. 게임 내에 존재하는 아바타, 장애물, 또는

디자이너가 집어 넣은 게임 내의 다른 모든 것들을 말한다.

2. 게임 액션 오브젝트(Game Action Object): 이것은 게임에

적용되는 규칙이나 제한 조건 등 게임이 작동되는 방식을

모델링한다. 기본적으로 이것은 어떤 이벤트를 가상 세계

속에서 나타내는 것이다. 예를 들면, 뛰기, 점프, 슛, 가속,

폭발 등등을 말한다. 액션 오브젝트는 엔티티 오브젝트에

의해 실현되며 다른 엔티티 오브젝트에 어떤 영향을 줄 수

있다.

3. 게임 폼 오브젝트(Game Form Object): 이것은 게임 엔티티

오브젝트가 런타임에 취하는 형태나 모양을 말하는 것으로,

엔티티 오브젝트 자체와는 구별되어야 한다. 이것은 메쉬와

함께 표현된다. 이것을 엔티티 오브젝트와 구별하는 이유는

뒤의 설명을 통해 명확해질 것이다.

4. 게임 스테이트 오브젝트(Game State Object): 이것은

엔티티 오브젝트의 데이터나 엔티티 오브젝트가 취한 폼의

상태를 관리하는 데 사용된다. 스테이트 오브젝트는 또한

액션이 작동되는 방식이 달라지도록 만들기도 한다. 엔티티

오브젝트에 대한 스테이트 오브젝트는 이름 등 게임 진행

자체와는 관련이 없는 데이터들이다. 그러나 폼 오브젝트에

대한 스테이트 오브젝트는 게임 작동과 관련된 부분에 거의

전적으로 한정되어 사용된다.

5. 게임 스페이스 오브젝트(Game Space Object): 이것은 위의

오브젝트들의 게임 내에서의 집합을 말한다. 게임

4

오브젝트들의 집합이 필요한 이유는 다양하다. 렌더링이나

A.I. 업데이트와 같은 최적화 과정을 위해서 오브젝트들을

여러 개의 집합으로 구분해 넣기도 한다. 개념상으로 이 게임

스페이스 오브젝트는 게임 속의 세계를 말하며, 이곳은 모든

액션들이 작동하는 곳이다.

위의 다섯 가지 기본 오브젝트들을 활용하면 모든 컴퓨터 게임은

아니더라도 거의 대부분의 컴퓨터 게임을 다 구현할 수 있다.

다음은 이 오브젝트들이 서로 함께 어떻게 작동하여 하나의 게임을

이루어내는지를 살펴보자. 위 오브젝트들은 그 자체로는 아무 의미가

없다. 게임 개발 과정 전체의 맥락 속에서 이 오브젝트들은 서로

릴레이션을 설정하고 함께 작동하여 하나의 게임으로 태어나는 것이다.

이들이 맺는 릴레이션이야말로 시스템의 진정한 본질이며, 시스템을

효율적으로 사용하는 데 이 릴레이션을 이해하는 것은 필수적이다.

다음의 클래스 다이어그램은 이 릴레이션들을 나타내고 있다.

그림 2

그림 2 의 각 클래스 타입과 이에 관련된 릴레이션들에 대해서는 뒤에서

설명하겠다. 그런데 이 클래스들은 극단적으로 일반화된 베이스

클래스로부터 파생된 것이다. 이 베이스 클래스가 왜 존재하는지에

대해서 먼저 설명할 필요가 있겠다. 컴퓨터 응용 프로그램에는

5

기본적으로 두 개의 오브젝트 타입이 있다: 렌더 가능 오브젝트와 렌더

불가능 오브젝트. 이러한 개념으로부터 생각해보면 각 오브젝트들은

내재적 상태(intrinsic state)를 갖고 있음을 알 수 있다. 달리 말해서 이

두 가지 오브젝트들은 변화하지 않는 기본적 상태를 갖고 있으며, 객체

지향형 프레임워크의 어떤 레벨에서나 작동될 수 있도록 되어 있다.

그러나 진정으로 내재적 상태에 해당되지 않는 것을 기본적 오브젝트에

추가하는 것은 과도한 것이다. 그러므로 어떤 상태를 베이스 클래스에

속하는 것으로 할 것인가를 결정할 때는 신중하여야 한다. 이 경우 그러한

내재적 상태를 정의하는 것은 위에서 언급한 두 가지 포괄적인 유형들을

잘 검증하는 문제로 귀결된다.

렌더 가능한 오브젝트는 그 이름이 말해주듯 어떤 형태로든 화면에

표시하도록 렌더링이 가능한 오브젝트를 말한다. 그러므로 이들을

렌더링할 필요가 있을 경우 그것을 위한 데이터들이 필요하다. 현재

컴퓨터에서 렌더링하는 데에는 오직 두 가지 방법이 있다. 그러나 만약 더

새로운 방법이 나온다면 여기서 설명하고 있는 시스템은 충분히 그것에

맞게 수정될 수 있을 것이다. 이차원 렌더링과 삼차원 렌더링 중 어느

것이거나 오브젝트들을 렌더링하는 데에는 위치와 방향 두 가지 성질이

필요하다. 따라서 렌더 가능한 모든 오브젝트에 이 두 가지 데이터들이

포함되어 있다면 다른 어떤 데이터가 더 없어도 오브젝트를 화면에

나타내는 것이 가능할 것이다. 이 데이터의 대부분은 그림 2-A 에

표시되어 있다.

6

그림 2-A

그림 2-A 에 포함되어 있는 데이터들은 오브젝트를 렌더링하기 위해

필요한 필수적인 최소한의 것들이다. 아직 무엇을 렌더링할 것인지 알지

못하기 때문에 베이스 클래스에 어떤 데이터도 더 추가할 필요가 없다.

오브젝트가 어디에 있었는지, 그리고 그 방향이 어느 쪽이었는지는 알고

있겠지만 그 모양은 아직 알 수가 없다. 그러므로 여기에 더 이상의

데이터를 추가하는 것은 불필요한 것이다. 이것은 오브젝트의 모양을

나타낼 수 있는 구체적인 클래스를 이 베이스 클래스로부터 도출해낼

것이라는 점을 의미한다. 이 시스템이 하는 일이 바로 그것이다(뒤에

상세히 서술). 그러나 현재로서는 오브젝트를 렌더링하기 위해 필요한

데이터들을 모두 밝혀낸 것으로 만족하자.

다음으로 살펴볼 기본 개념은 렌더 불가능 오브젝트이다. 이것은 간단한

편이다. 이것은 화면에 표시될 필요가 없는 모든 종류의 오브젝트들을

말한다. 이것은 너무 광범위하기 때문에 그러한 오브젝트들이 요구하는

내재적 데이터를 정의한다는 것은 불가능할 것이다. 따라서 이것의

베이스 클래스는 렌더 가능 오브젝트들로부터 이것을 구별해 줄 수 있는

간단한 추상적 클래스이다. 이것이 존재하는 주된 이유는 오브젝트를

구별하는 것이고, 시스템 내에서 엔티티들을 카테고리로 묶어 관리하는

7

것이다. 그림 2-B 의 클래스 도표는 이 프레임워크를 잘 나타내어주고

있다.

그림 2-B

이제 그림 2 에 나타난 바와 같이 일반화된 베이스 클래스로부터 도출된

다섯 가지의 클래스들을 디자인하는 방법에 대해 자세히 논의해 보자.

그런데 다섯 가지의 기본적인 오브젝트들이 런타임에 상호작용하는

방식은 다소 복잡할 수 있다. 그리고 이들 클래스들 중의 하나, 또는

런터임에서의 상대방 역을 하는 것이 어떻게 작동하는지를 설명하는 것이

게임 개발 시스템을 이해하는 데 모든 독자들에게 반드시 도움이 되지는

않을 것이다. 이 클래스들은 특정한 중요한 릴레이션들을 통해 서로

절묘하게 연결되어 있다. 이 시스템을 설명하기 위해서는 모든

클래스들과 그에 관련된 릴레이션들을 먼저 이해하는 것이 필요하다.

게임 스페이스 오브젝트

그림 3 에 나타난 바와 같이 게임 스페이스 오브젝트는 다른

오브젝트들을 담아두는 데 사용된다. 이것은 하나 또는 여러 개의 게임

엔티티들의 집합을 말한다. 대부분의 컴퓨터 게임에서 게임 토큰들은

어떤 특정한 방식으로 상호작용을 하며, 일반적으로 여러 집합들로

8

구분된다. 그러나 컴퓨터 게임 구현에서 대부분의 경우 이 집합들은

필요에 따라 임의로 생성되는 것이 일반적이다. 이 시스템은 게임

엔티티들이 항상 상호작용을 할 필요가 있다는 것을 염두에 두고

디자인되었다. 따라서 게임 토큰들을 집합으로 묶는 표준적인 방식을

요구하고 있다. 이를 통해서 필요한 경우 이 집합들을 재사용할 수 있다.

그림 3

그림 3 은 게임 스페이스 클래스로부터 도출된 두 가지 종류의 오브젝트

집합들을 나타내고 있다. 버추얼 스페이스 오브젝트는 게임 폼

오브젝트들을 포함하는데, 이것은 엔티티의 물리적 형태를 가상적으로

표현한 것이다. 버추얼 스페이스는 로지컬 스페이스의 하위 집합이다.

그림에 나타난 집합에는 차, 비행기, 꽃, 보트가 포함되어 있는데, 이들은

게임 엔티티 오브젝트들의 모습을 나타내고 있다. 버추얼 스페이스의

오브젝트는 단지 엔티티의 물리적 형태를 나타낼 뿐, 그 엔티티 자체가

아니라는 것은 대단히 중요한 점이다. 엔티티 오브젝트의 다른 성질들은

로지컬 스페이스에 구분되어 저장된다. 게임 스페이스 클래스는 모든

집합에 최소한의 기능들만을 요구하는 추상적 베이스 클래스로부터

도출된 것이다. 이 최소한의 기능들이란 엔티티들을 추가하거나 삭제하는

것을 말한다. 그러나 소팅이나 소팅된 집합에 삽입하는 것과 같은

기능들까지 포함할 수도 있다. 엔티티를 두 가지 유형의 집합으로

9

구분하는 주된 이유는 최적화이다. 버추얼 스페이스는 디스플레이

시스템에 렌더링될 수 있으므로 로지컬 스페이스와는 약간 다르고,

따라서 여기에는 렌더링이 필요한 오브젝트들만이 포함된다. 실제로

여기에서 설명하고 있는 게임 개발 프레임워크의 코어 서비스에 대한

인터페이스는 렌더링을 위해 버추얼 스페이스 집합을 사용하고 있다.

그리고 런타임에 여러 개의 버추얼 스페이스 집합들을 서로 바꾸어가면서

어떤 오브젝트에 대해서나 작업을 할 수 있다.

로지컬 스페이스는 실제 작업이 이루어지는 공간을 말한다. 버추얼

스페이스가 엔티티의 물리적 형태를 저장하고 있다면 로지컬 스페이스는

엔티티의 가상 영혼을 포함하고 있다고 말할 수 있을 것이다. 이

스페이스는 모든 엔티티들이 상호작용 할 수 있도록 만들어지는 공간이다.

여기에는 포함된 엔티티의 수들 만큼이나 여러 가지 유형의 상호작용이

있을 수 있다. 예를 들어 플레이어의 아바타가 레일 건으로 악당을 쏘는

것을 생각해보자. 이 행동이 일어나면 이것을 인지하기 위해 코드에서

무언가를 반드시 해야만 한다. 그러한 인지가 이루어지는 곳이 바로 이

공간이다. 여기에 포함된 오브젝트들은 오브젝트간 조건부 브랜칭(inter-

object conditional branching)이 일어나지 않도록 최적화된다는 것을

알아둘 필요가 있다. 상호작용 시스템 내에서는 switch/case 구문이 많이

들어있지 않고, if/else 구문도 복잡하게 들어있지 않다. 오브젝트

자체에는 약간의 조건 구문들이 들어 있지만, 프로그래밍에서 조건

구문들을 전혀 포함하지 않는 것은 사실상 불가능하기 때문에 그것은

불가피할 것이다. 중요한 것은 게임 스페이스는 상호작용을 갖는

엔티티들을 담아두는 곳이라는 점이다.

게임 스테이트 오브젝트

오브젝트 간의 상호작용을 더 정확히 정의하기 위해서 사용하는 것이

스테이트 오브젝트이다. 상호작용을 일으키는 오브젝트는 궁극적으로

어떤 행동을 표현하고 있는 것이다. 상태란 그 행동의 한 순간, 또는 어떤

특정 시점에서의 행위를 말하는 것이다. 게임 프로그램들이 재활용되지

10

못하는 이유가 주로 여기에 있다. 대부분의 게임들 구현에서 상당히

세부적으로 나뉘어진 특화된 클래스들을 이용하는 경향이 있다. 최적화할

필요가 있기 때문인 것이다. 어떤 클래스의 기초적인 상태를 사용하는

경우도 있지만 재활용이 가능한 클래스에 그런 상태를 추가하는 것은

대단히 신중하게 처리되어야 한다. 여기에 소개하고 있는 게임 개발

시스템에서는 스테이트 클래스를 이용하여 엔티티 오브젝트의

상호작용을 나타내고 있다. 스테이트 클래스를 사용하면 폼 클래스와

엔티티 클래스를 정의할 수 있고, 런타임에 액션 오브젝트가 엔티티

오브젝트의 행동을 제어하도록 할 수 있다. 결론적으로 말해, 런타임에서

폼 오브젝트와 엔티티 오브젝트가 취하는 행동 그리고 액션 오브젝트

자체는 이 시스템의 스테이트 오브젝트들을 통해 제어된다고 할 수 있다.

엔티티의 행동을 제어하는 데 특화된 기초 변수들을 사용하지 않고

스테이트 클래스를 사용하는 것을 통해 얻을 수 있는 장점은 두 가지가

있다. 첫째, 일단 스테이트 클래스가 정의되고 나면 게임 개발 시스템에서

어떤 게임 토큰을 정의할 때 언제나 이것을 사용할 수 있다. 둘째,

런타임에 엔티티 오브젝트가 어떤 스테이트 오브젝트를 가지고 있는지

질의하는 것이 가능하다. 여기에 포함되어 있는 상태 오브젝트를

이용하여 오브젝트들이 상호작용을 일으킬 수 있는 것이다. 이것은

상당히 흥미로운 의미를 갖는다. 서로 아무 관계 없이(서로를 명시적으로

레퍼런스하는 것이 전혀 없이) 정의된 두 개의 게임 토큰들이 스테이트

오브젝트와 이들이 형성한 릴레이션을 이용하여 런타임에 상호작용을 할

수 있다는 것이다. 잠깐, 도대체 이것이 어떻게 가능하단 말인가? 그것은

액션 클래스가 모델링하고 있는 이벤트의 유형에 관계된 특정한 스테이트

오브젝트를 수정할 수 있도록 액션 클래스가 디자인되었기 때문이다.

이렇게 디자인한 이유는 또 스테이트 오브젝트가 게임 토큰의 행위를

정의하거나 제한하고 있기 때문이며, 따라서 스테이트 오브젝트를

수정함을 통해 간접적으로 이들이 정의하는 행동을 제어할 수 있다. 즉,

완전하게 정의된 엔티티가 아니라 스테이트를 이용해 상호작용을 하여

시스템을 유연하고 광범위하게 이용할 수 있는 것이다. 그리하여 게임

11

토큰들이 특정한 데이터에 의존하여야만 하는 것을 차단할 수 있다.

이것은 엔티티 클래스를 구현하는 데 엄청난 유연성을 제공한다.

예를 들어, “빠른” 차를 나타내는 게임 토큰이 있다고 하자. 그리고 이

차가 더 빨리 이동할 수 있도록 그 행동을 수정하려고 한다고 하자.

그런데 우리가 원하는 것은 이 차만 더 빨리 가도록 하는 것이 아니라

빠른 차를 나타내는 게임 토큰이라면 필요에 따라 모두 더 빨리 갈 수

있도록 하는 것이라고 가정하자. 더욱 중요하게는 차를 나타내는 게임

토큰뿐 아니라, “빠른” 속성을 갖는 게임 토큰이라면 무엇이든지 더

빠르게 되도록 하고자 한다고 하자. 그리고 이들을 모두 동일한 방법으로

수정이 가능하도록 하려고 한다. 약간 우습게 들릴지도 모르지만 한 번

생각해보자. 이런 방법은 대단히 강력한 최적화를 구현할 수 있는

잠재력이 있다. 액션 오브젝트와 그것이 포함하는 릴레이션들을 어떻게

정의하는지 뒤에 설명을 하고 나면 왜 이 시스템을 이렇게 디자인하는지

더 명확해질 것이다.

그런데 더 설명을 계속하기 전에 여기서 리플렉션 기술의 문제를 잠깐

언급할 필요가 있겠다. 리플렉션 기법은 최근 사용되는 대부분의 객체

지향형 프로그래밍 언어에 포함되어 있다. 이것을 통하면 기본 상태들을

상당히 보편적인 방법으로 이용할 수 있다. 리플렉션을 이용하면

대부분의 오브젝트들, 그리고 그것이 갖는 필드와 메쏘드를 찾아낼 수

있다. 그러나 리플렉션 기술을 이용하면 그것이 이용하고 있는 객체

지향형 프레임워크에 시스템이 종속된다는 문제가 있다. 따라서 여기서

소개하고 있는 게임 개발 시스템에서는 엔티티 오브젝트의 데이터를

기록하기 위해 스테이트 오브젝트를 이용하고 있는 것이다. 이렇게 하면

필요에 따라 적절한 언어를 선택하여 이 게임 개발 시스템을 구현하는

것이 가능할 것이다.

12

게임 폼 오브젝트

그림 2-B 는 렌더 가능 오브젝트로부터 도출된 폼 클래스를 나타내고

있다. 여기서 소개하고 있는 시스템에서는 이것이 유일한 렌더 가능

오브젝트 유형이다. 폼 오브젝트를 사용하는 이유는 대개 아주 단순하다.

이것은 통상 어떤 엔티티 오브젝트가 취하는 모든 종류의 모양을

나타내는 데 사용된다. 플레이어는 이 오브젝트를 게임 토큰이라고

생각하게 될 수도 있다. 그러나 이것은 옳지 않은 것이다. 프로그래머는

절대로 이 문제에서 혼란을 일으켜서는 안 된다. 컴퓨터 디스플레이에

무언가를 효율적으로 렌더링하기 위해서는 렌더링 루프를 최대한 빨리

작동하여야 한다. 이 시스템에서는 기능으로부터 폼을 구분해내어

렌더링을 이처럼 효율적으로 구현할 수 있다. 또 재활용이 가능한 폼

클래스를 생성하는 것을 가능케 한다. 기본적으로 엔티티 클래스를

일반화하여 이들이 취해야 하는 어떤 모습이든 그것을 나타내는 폼

오브젝트를 사용할 수 있도록 하는 것이다. 그림 4 에서 보여지듯이 폼

클래스는 메쉬를 포함한다. 메쉬를 이용하면 폼 오브젝트는 어떤 3D

모델링 소프트웨어에서나 만들 수 있는 모양이 된다. 그리하여 게임

디자이너가 원하는 대로 폼 오브젝트를 표현할 수 있는 것이다. 이렇게

하면 대단히 유연한 엔티티 클래스를 만들 수 있다. 그리고 폼 오브젝트와

엔티티 오브젝트(게임 토큰)이 구별되어 있으므로 렌더링에 필요한 어떤

방법으로든 폼 오브젝트를 분류하고 소팅하는 것이 가능하다. 이것은 각

오브젝트가 요구하는 렌더링 상태의 유형에 따라 오브젝트를 분류하는 데

대단히 유용하다.

13

그림 4

폼은 스테이트 릴레이션을 포함한다

이러한 릴레이션을 이용하면 폼 오브젝트가 스테이트 오브젝트를

포함하는 것이 가능하고, 폼 오브젝트가 버추얼 공간에서 취하는 행동을

제어하는 데 스테이트 오브젝트를 사용할 수 있다. 우리가 추구하는 것은

엔티티 오브젝트가 취하는 모양을 나타내는 데 사용할 수 있는 재활용이

가능한 폼 오브젝트를 만드는 것이다. 일반적으로 게임 디자이너나

개발자들은 게임 토큰이 실제 상황에서처럼 행동을 나타낼 수 있도록

하는 것을 원하는데, 스테이트 오브젝트는 바로 그것을 가능케 한다.

스테이트 오브젝트는 게임 토큰의 기능을 제어하는 데 사용되는데,

이들은 폼 오브젝트에 포함되어 있다. 따라서 폼 오브젝트는 자기 완결적

성격을 갖는다. 달리 말하면 폼 오브젝트는 다른 엔티티들이 그것을

사용하는 데 필요로하는 모든 것들을 자체에 다 가지고 있다.

그러나 스테이트 오브젝트가 폼 오브젝트에 포함되어 있다는 사실 자체가

그것이 무슨 오브젝트냐 또는 왜 그러하냐라는 것보다 더 중요하다는

것을 염두에 두어야 한다. 앞에서 이미 “빠른” 것을 더 빠르게 하는 것이

특정한 게임 토큰 하나를 빠르게 하는 것보다 더 강력한 효과를 발휘할 수

있다는 것을 설명하였다. 릴레이션을 이용하면 특정한 오브젝트 하나가

아니라 일반적인 오브젝트 전체에 대해 그러한 효과를 낼 수 있는 것이다.

여기서 소개하고 있는 게임 시스템에서는 스테이트 데이터나 폼 오브젝트

14

자체가 아니라 릴레이션을 처리하고 있다. 즉, 폼 오브젝트의 모양이

어떠하거나에 관계 없이 또는 스테이트 데이터가 나타내려고 하는 행동이

무엇인지에 관계 없이 모든 폼 오브젝트를 활용할 수 있는 것이다. 이것은

재활용이 가능한 엔티티를 생성하는 데 대단히 유용한 개념이다.

폼은 스페이스 릴레이션을 포함한다

그림 2 에서 보여지는 바와 같이 엔티티는 폼을 포함하고, 폼은

스페이스를 포함하며, 스페이스는 엔티티 오브젝트의 집합을 이용한다.

이러한 관계들은 스페이스 오브젝트 내에서 작동하는 액션 오브젝트와

관련하여 더 중요한 의미를 갖는다. 여기서는 다만 그림 3 에 나타난 것과

같이 버추얼 스페이스를 나타내는 데 엔티티 오브젝트를 사용할 수

있다는 것만을 언급해두자. 이 엔티티 오브젝트는 폼 오브젝트를 포함할

수 있는데, 폼 오브젝트는 그 스페이스의 볼륨을 나타내는 데 사용될 수

있다. 폼 오브젝트가 스페이스 오브젝트를 포함할 수 있으므로 다른

엔티티들도 스페이스 오브젝트와 형성하고 있는 릴레이션을 이용하여 폼

오브젝트 내에 구현되고 포함될 수 있다. 앞서 설명했듯이 액션

오브젝트는 스페이스 오브젝트 내에서 작동하며 엔티티 전체에 걸쳐

영향을 주도록 구현될 수 있다. 액션 오브젝트는 폼 오브젝트의 버추얼

스페이스 내에 있는 엔티티의 위치를 제어하기 위해 폼 오브젝트가 갖고

있는 메쉬 데이터를 사용할 수 있다. 또한 집합 내의 모든 엔티티의

스테이트를 제어하기 위해 폼 오브젝트와 연관된 스테이트 오브젝트

데이터를 활용하는 것도 마찬가지로 매우 쉽다. 이와 같이 하면 버추얼

스페이스 내에서 다른 엔티티에 포함된 엔티티의 집합들을 이리 저리

이동하는 것이 대단히 간단하게 해결될 수 있다.

게임 액션 오브젝트

엔티티 오브젝트는 런타임에 액션 오브젝트를 불러내어 어떤 일들을 하게

된다. 그 이름이 말해주듯이 액션 클래스는 엔티티가 수행할 수 있는 어떤

일들을 구현하는 것이다. 더욱 정확하게는 런타임에 어떤 이벤트를

15

창조해내는 것이다. 일반적으로 어떤 이벤트가 발생하면 그것이

발생했다는 것을 나타내는 무언가가 있다. 액션 오브젝트는 이 이벤트를

나타내는 실행 코드이다. 즉, 이것은 이벤트를 가상적으로 표현한 것이다.

액션 클래스는 미리 지정된 스테이트 오브젝트들을 수정하도록

디자인된다. 스테이트 오브젝트를 수정한다는 것은 폼 오브젝트와 엔티티

오브젝트의 행동을 수정한다는 것을 의미한다. 앞서 언급했듯이 스테이트

오브젝트는 어떤 행동의 순간을 포착한 것, 또는 특정 시점에서의 행동을

가리킨다. 액션 오브젝트는 이 시스템의 음향이나 시각 효과들을

진행시켜 나가는 역할을 하여 이것이 마치 영화처럼 보이게 만든다. 더욱

정확하게는 액션 오브젝트는 엔티티 오브젝트에 포함된 스테이트들을

순차적으로 나타내는 것이다. 액션 오브젝트는 특정 시점 자체에서는

아무 의미를 갖지 않으며 어떤 시간의 경과에 따라 존재하는 것이다. 액션

오브젝트가 존재하는 동안 그것은 그것을 작동한 엔티티 오브젝트의 현재

상태를 나타내고, 또 다른 엔티티 오브젝트의 현재 상태를 수정하는

역할을 한다.

액션 클래스는 엔티티를 포함하며 스테이트 릴레이션을 이용한다

그림 2 에서 표시된 바와 같이 액션 클래스는 엔티티 클래스와 쌍방향의

릴레이션을 형성하며, 따라서 엔티티 클래스에 대한 레퍼런스를 자체

내에 포함하고 있다. 이 레퍼런스들은 액션 오브젝트가 작용을 하도록

호출된 타겟 엔티티를 가리킨다. 스테이트 오브젝트들은 개체화된 엔티티

오브젝트들을 정의하고 있는데, 액션 오브젝트는 엔티티 오브젝트와의

릴레이션을 통해 이 스테이트 오브젝트들에 대한 레퍼런스를 포함하게

된다. 스테이트 오브젝트들을 레퍼런스하는 것은 대단히 중요한

릴레이션이다. 앞서 설명한 바와 같이 엔티티와 폼들은 스테이트와

액션의 조합이라고 볼 수 있다. 따라서 이들 릴레이션을 통해 엔티티의

일부를 제어하는 것은 사실상 엔티티 그 자체를 제어하는 것과 같은

것이다. 스테이트 레퍼런스들은 해쉬 테이블을 이용하여 엔티티 오브젝트

내에 구현된다. 액션 오브젝트는 필요한 스테이트 오브젝트를 엔티티

16

오브젝트의 스테이트 해쉬 테이블로부터 질의한다. 그리고 그 스테이트

오브젝트가 존재하면 액션 오브젝트가 그것에 작동할 수 있다. 스테이트

오브젝트는 액션 오브젝트가 실행되는 방식에 영향을 주며, 반대로

스테이트 오브젝트는 액션 오브젝트에 의해 수정될 수 있다. 그리고 다른

액션 오브젝트의 실행에도 영향을 준다. 이러한 릴레이션들은 게임이

진행되는 동안 엔티티 오브젝트들을 따라 반복적으로 발생한다: 액션은

스테이트를 수정하고, 스테이트는 다시 액션을 작동시킨다.

스테이트 오브젝트를 설명한 섹션에서 언급했듯이 엔티티들은 서로를

명시적으로 레퍼런스하는 것을 자체 내에 포함하고 있지 않더라도 서로

어떤 작용을 할 수 있다. 이를 위해서 액션 오브젝트를 이용하는 것이다.

스테이트 오브젝트는 액션 오브젝트의 기능들을 호출하며, 특정한 액션

이벤트들은 미리 정의된 스테이트 오브젝트들을 사용하도록 구현되어

있다. 이를 통해 액션 오브젝트가 그것을 이용하는 게임 토큰들로부터

분리될 수 있다. 동시에 그것이 어떤 게임 토큰의 일부가 되더라도 반드시

작동할 수 있도록 보장한다. 이렇게 하면 엔티티 오브젝트와

그것으로부터 만들어진 실질적인 게임 토큰들이 대단히 강력하고

재사용이 가능한 것으로 될 수 있다.

액션 오브젝트는 엔티티 오브젝트를 레퍼런스하는 것을 통해 작동한다.

액션 오브젝트에 포함된 레퍼런스의 하나는 “UserEntity”를 가리키는데,

이것이 바로 그 액션을 호출한 엔티티를 말하는 것이다. “UserEntity”가

그 레퍼런스를 통해 처리하는 게임 스테이트를 가지고 있다면, 액션

기능이 작동하는 방식은 바로 그 스테이트들에 의해 수정된다. 또

“TargetEntity”라는 레퍼런스도 있는데, 이것은 “UserEntity”가 아닌

다른 엔티티를 가리킨다. 액션 오브젝트는 이것을 대상으로 작동하도록

호출된 것이며, 일반적으로 액션 오브젝트에 의해 그 스테이트가

수정된다. 만약 “TargetEntity”가 없다면, 달리 말해서

“TargetEntity”가 Null 을 레퍼런스하고 있다면, “UserEntity”에 의해

호출된 액션은 바로 그 “UserEntity” 자신에 작동하는 것이다.

17

다음으로는 “TargetSet”라는 엔티티 레퍼런스가 있다. 이것은 여러 개의

엔티티 오브젝트로 이루어진 그룹에 작동하는 액션을 정의하는 데

사용된다. 이것은 게임 스페이스 내에 존재하는 엔티티 어느

것으로부터나 만들어질 수 있고, 궁극적으로 게임 스페이스의

부분집합이라고 할 수 있다. “TargetSet”에 어떤 액션이 작동하면

거기에 포함된 엔티티들 중 스테이트 오브젝트가 유효한 것들은 모두

영향을 받게 된다.

그러면 액션 오브젝트는 도대체 어떻게 호출되는가? 액션을 호출하는

방법은 두 가지가 있다. 가장 뻔한 첫 번째 방법은 입력을 사용하는

것이다. 사용자가 입력 이벤트를 제공하면, 이것을 특정 게임 토큰 내에

존재하는 액션 오브젝트로 매핑할 수 있다. 입력에 의해 호출된 액션

이벤트는 실행이 끝날 때까지 또는 그것을 취소하는 다른 입력 이벤트가

있을 때까지 계속된다. 이 시스템은 AI 사용자가 액션을 호출하는 입력을

제공할 수 있도록 하고, 또 AI 모듈에 그 결과를 피드백하도록 한다.

그러나 그런 AI 엔티티는 이 시스템의 프레임워크를 염두에 두고

디자인되어야만 한다. 두 번째 방법으로는 액션 오브젝트가 다른 액션

오브젝트를 호출하는 것이다. 이것은 약간 미묘한 방법으로 약간

이해하기 어려울 수도 있다. 예를 들어 아바타를 나타내는 게임 토큰이

슈팅 액션을 호출하려고 한다고 하자. 플레이어에 의해 제어되고 있는

아바타는 키를 누르는 입력 이벤트를 이용해 슈팅 액션을 호출한다. 슈팅

액션은 악당이라는 다른 게임 토큰을 “TargetEntity”로 갖고 있다. 슈팅

액션은 “자체 취소”가 이루어지는 액션의 하나다. 즉, 액션을 취소하는

다른 입력을 기다리는 것이 아니라 게임 내의 조건을 이용하여 그 작동

기간을 자동적으로 결정한다. 액션 오브젝트는 악당 토큰에 충돌했는지를

검사하고, 만약 충돌했다면 악당 오브젝트에 포함된 스테이트 오브젝트를

수정한다. 이미 액션 오브젝트가 악당 토큰과 상호작용을 하고 있으므로

토큰의 헬쓰 스테이트를 검사한다. 만약 스테이트 오브젝트가 특정한

조건을 만족시킨다면 액션 오브젝트는 악당 토큰에 대해 사망 액션을

18

작동시킨다. 이러한 방법은 일종의 환경적 인공 지능에 해당하는 액션을

호출하는 것이다.

액션은 코어 서비스의 릴레이션과 인터페이스를 갖는다

그림 5 는 액션 오브젝트와 코어 서비스의 릴레이션을 나타내고 있다.

여기서 소개하고 있는 시스템에서는 액션 오브젝트가 게임의 비주얼과

음향을 이끌어 나간다는 사실을 다시 한번 상기하는 것이 좋을 것 같다.

이것은 코어 서비스에 대한 인터페이스를 사용함을 통해 가능하다.

그러나 음향과 시각 효과가 제대로 작동하기 위해서는 최적화가 필요하다.

그리고 액션은 시각과 음향에 대해 완전한 제어권을 갖는 것은 아니다.

액션 오브젝트는 이들에 대해 자연스런 매니저의 역할을 하는 정도이다.

액션 오브젝트는 단지 시각과 음향 효과가 작동되도록 하는 요청을 하는

것뿐이다. 반면 코어 서비스는 발생하고 있는 액션에 맞는 적절한

그래픽과 음향 효과를 최적으로 나타내기 위해 작동을 한다. 대개 코어

서비스가 적절히 구현되어 있고 최적화되어 있다면 요청이 발생할 때마다

시각과 음향 서비스를 제공하는 것은 결코 어려운 문제가 아니다.

그림 5

19

게임 엔티티 오브젝트

게임 엔티티 클래스는 여기서 소개하고 있는 게임 개발 시스템의 핵심에

해당한다. 그림 2 에서 나타내었듯이 엔티티 클래스는 시스템 내의 다른

모든 클래스들과 릴레이션을 갖는다. 엔티티 오브젝트는 런타임에 이들

모든 오브젝트들이 작동된 것들로 구성되며, 시스템 내의 모든 기본

오브젝트들로 구성된 이것은 게임 토큰이라는 상당히 고도의 오브젝트를

생성해내는 것이다. 엔티티 클래스는 게임 토큰이 될 수 있는 하나의

개념에 불과한 것이지 게임 토큰 그 자체는 아니다. 이것은 대단히 중요한

차이이다. 실행되는 엔티티 오브젝트는 게임 토큰이 무엇을 나타내는지를

완전히 구현하고 있고, 엔티티 클래스는 이 게임 토큰이 변화할 수 있는

그 모든 것을 의미하는 것이다. 즉, 차를 나타내는 게임 엔티티는 게임

런타임에 차라고 하는 게임 토큰이 되는 것이다. 그러나 그 이전까지는

게임 엔티티는 모든 것인 동시에 아무 것도 아니다. 달리 말하면 게임

토큰은 폼과 스테이트를 갖고, 액션을 수행할 수 있는 엔티티를 말하며,

게임 엔티티가 게임 토큰의 청사진에 해당하는 것이라면 게임 토큰

자체는 게임 스페이스에 존재하는 것이다. 엔티티 오브젝트가 다른

오브젝트들과 형성하는 릴레이션들은 이들이 게임 엔티티 “청사진”을

통해 상호작용을 할 수 있도록 만든다. 이 시스템에서는 모든 엔티티가 폼,

스테이트, 액션, 그리고 스페이스로 이루어져 있으며 동시에 스페이스

집합 내에서 존재하고 있다는 것을 염두에 두고 있다. 이러한

릴레이션들을 전제로 하고 있으므로, 이 시스템은 엔티티 오브젝트가

런타임에 일관성 있게 작동할 수 있도록 하는 프레임워크가 되는 것이다.

그리고 이것을 대단히 효과적으로 처리할 수 있다. 일단 구현 단계에

이르면, 프로그래머는 게임 개발 시스템의 엔티티를 이용하여 게임

토큰을 정의할 수 있고, 이 게임 토큰들은 상호작용을 일으키는 데 필요한

모든 데이터 레퍼런스들을 갖고 있을 것이다. 상호작용의 프레임워크를

별도로 디자인하지 않아도 되므로, 프로그래머는 이제 게임 토큰이 어떤

20

방식으로 일을 할 수 있도록 하느냐가 아니라 무슨 일을 하도록 하느냐에

집중할 수 있다. 이것은 대단히 많은 시간을 절약해 줄 것이다.

엔티티는 스테이트 릴레이션을 포함한다

엔티티 오브젝트는 이 릴레이션을 통해 어떤 스테이트를 보유하게 된다.

달리 말하면 런타임 게임 토큰은 그것을 구성하고 있는 폼

오브젝트로부터 분리된 스테이트를 보유하게 된다. 이것은 이름과 같이

“서술적(descriptive)”인 데이터에서 대단히 유용하게 사용될 수 있다. 폼

오브젝트의 스테이트는 폼 오브젝트를 화면에 나타내는 방법을 결정하는

데이터를 포함하고 있지만, 이름과 같이 추가의 데이터를 포함하기

위해서는 폼 오브젝트 내부만을 가지고는 충분하지 않다. 가상 공간

내에서 다른 오브젝트들과 상호작용하는 방식에 결정적인 영향을 주지

않는 엔티티 오브젝트의 내부에 폼 오브젝트가 데이터를 저장하면,

대단히 강력하고 다양한 종류의 게임들에서 사용이 가능한 폼 오브젝트를

만들 수 있다. 그리고 엔티티 클래스 내부의 스테이트들의 메타 데이터를

신중하게 고안하면, 엔티티 클래스 자체도 대단히 효율적으로 재사용하는

것이 가능하다.

엔티티는 폼 릴레이션을 포함한다

이미 여러 차례에 걸쳐 엔티티를 폼으로부터 분리하는 것을 반드시

유지하여야 한다는 점을 강조한 바 있다. 이것은 엔티티 클래스를

일반화하는 것을 가능케 한다. 즉, 엔티티 클래스를 이용하여 상상 가능한

모든 종류의 게임 토큰을 다 정의할 수 있게 해준다. 오직 게임

디자이너만이 게임 토큰이 어떤 식으로 행동할 것인지, 그리고 어떤

모양을 나타낼 것인지를 정의할 수 있으므로 엔티티 클래스를 이런

방식으로 일반화하는 것은 대단히 유용한 일이다. 나아가 폼 오브젝트의

메쉬가 갖는 디멘션에 아무 제한이 없을 것이다. 이것은 이차원 또는

삼차원 오브젝트를 이용하여 엔티티 오브젝트가 그 외관을 나타낼 수

있도록 하는 것이다. 그러므로 엔티티 오브젝트를 이차원

21

인터페이스에서나 삼차원 아바타를 통해서나 별로 어려움 없이 나타낼 수

있다. 이 게임 개발 시스템은 이러한 릴레이션을 전제로 하고 있으므로,

게임 토큰이 어떤 모양으로나 화면에 표시될 수 있도록 엔티티 클래스가

정의하는 것이 가능하다.

엔티티는 스페이스를 사용하며 액션 릴레이션을 포함한다

스페이스 오브젝트와 액션 오브젝트가 형성하는 릴레이션은 엔티티

오브젝트가 다른 엔티티 오브젝트와 상호작용을 할 수 있도록 한다. 앞서

언급한 바와 같이 스페이스 클래스는 엔티티 오브젝트의 집합을 정의하는

데 사용된다. 엔티티 오브젝트는 엑션 오브젝트 레퍼런스들을 확보하기

위하여 이 오브젝트 집합들을 레퍼런스한다. 액션 오브젝트는 그 대상을

선택하거나 레퍼런스하는 엔티티에 작용을 가하는 데 액션 오브젝트

레퍼런스를 사용한다.

예를 들어, 행성의 표면을 하나의 엔티티로 정의한다고 하자. 이 행성의

표면을 나타내기 위해 다양한 지형적 특징을 포함하는 메쉬를 만들고,

이것을 폼 오브젝트에 포함하며 폼 오브젝트와 행성 표면이라는 엔티티

오브젝트를 레퍼런스할 수 있을 것이다. 모든 폼 오브젝트가 스페이스

오브젝트를 포함할 수 있고, 스페이스 오브젝트는 엔티티의 집합이므로,

다른 엔티티들을 정의한 뒤 이것을 이 집합에 속하는 것으로 정의할 수

있을 것이다. 집합에 포함된 모든 엔티티들이 폼 오브젝트들로

이루어지는데, 이 폼 오브젝트들은 렌더 가능 오브젝트로부터 도출된

것이다. 여기에는 삼차원 공간에서 나타낼 수 있는 어떤 위치도 나타낼 수

있는 스테이트들이 포함되어 있고, 행성 표면이라고 정의된 엔티티

오브젝트를 위해 액션 오브젝트를 정의할 수도 있을 것이다. 이것은

엔티티의 집합에 간편하게 작용을 가할 수 있다. 예를 들어

"ApplyGravity()"라는액션과 SetEntityZToPlanetSurfaceZ@XY()"라는

액션이 여기에 해당될 수 있을 것이다.

22

그림 2 에서 나타내었고 또 앞에서 설명한 바와 같이, 엔티티 클래스는 이

시스템에서 대단히 밀접하게 연결되어 있다. 그러나 이들 연결 관계의

극점은 최대한 일반화되어 있다. 이처럼 일반화 하면 엔티티 클래스를

원하는 어떤 곳으로나 쉽게 형성해 넣을 수 있다. 그러나 이들 일반화된

오브젝트들이 안정되게 상호작용을 할 수 있는 프레임워크를 보장할 수

있도록 그 연결들 자체는 특화되어 있다. 그러나 동시에 이들 일반화된

클래스들은 어떤 특정한 방식으로 함께 처리될 수 있도록, 그리하여

하나의 게임 토큰이 될 수 있도록 정의될 수 있다. 이 글에서 설명된 모든

클래스들과 릴레이션들을 이용하면 필요한 게임 토큰은 어느 것이나 다

만들 수 있다. 엔티티 오브젝트는 스테이트 오브젝트와의 릴레이션을

통해 이름과 같이 개별화된 데이터를 포함할 수 있다. 또 폼 오브젝트와의

릴레이션을 통해 엔티티 오브젝트는 이차원 또는 삼차원의 상상 가능한

어떤 형태로든 다 표시될 수 있다. 폼 오브젝트가 스테이트 오브젝트와

갖는 릴레이션을 통해 엔티티 오브젝트는 가상 공간에서 그것의 행동에

영향을 주는 데이터들을 포함할 수 있다. 그리고 폼 오브젝트가 스페이스

오브젝트와 갖는 릴레이션을 통해 엔티티 오브젝트는 다른 엔티티

오브젝트를 자체 내에 포함할 수 있고, 따라서 가상 세계 속의 또 하나의

가상 세계가 되는 것이다. 스페이스 오브젝트 릴레이션을 통하면 엔티티

오브젝트는 현재 런타임 코드 상에서 유효한 다른 엔티티 오브젝트는

어떤 것이든지 다 레퍼런스할 수 있다. 그리고 끝으로 액션 오브젝트와

갖는 릴레이션을 통해 엔티티 오브젝트는 다른 엔티티 오브젝트를

수정하거나 그 엔티티 오브젝트의 행동을 수정할 수 있다. 게임 토큰에서

이것 이외에 더 무엇이 필요하겠는가?

구현 가능성

이쯤 되면 이들 다섯 개의 오브젝트, 그리고 이들이 형성하는 관계들이

서로 함께 작동할 수 있도록 구현하는 것이 어떻게 가능할 것인지 의문이

생길 것이다. 그 해답은 추상 클래스와 버추얼 메쏘드에 있다.

DoAction()이라고 하는 버추얼 메쏘드를 채용하고, 이것을 도출된

23

클래스들에 오버라이드하도록 할 수 있을 것이다. 이렇게 하면 액션들의

집합을 따라서 반복 처리를 하거나 집합 Z 에 포함된 모든 액션에

대해 Z.DoAction()를 수행할 수 있다. 여기서 설명하고 있는

프레임워크는 엔티티 오브젝트의 집합으로 이루어져 있으므로,

Entity.DoAction()를 게임 스페이스 내의 모든 엔티티에 대해 모두 각각

수행하는 방식으로 이것을 처리할 수도 있을 것이다. 이러한 방식으로

호출된 모든 액션은 비주얼 및 오디오 서비스를 요구할 것이고, 이것은 곧

액션 이벤트를 나타낸다. 끝으로, 호출된 액션 오브젝트는 먼저 액션을

수정하고, 궁극적인 대상 엔티티의 스테이트 오브젝트를 찾아 수정하기

위해 그 대상 레퍼런스를 사용한다. 이것이 바로 이 시스템이 작동하는

기본적인 원리이다. 그림 6 과 그림 6-A 는 이것을 시각적으로 나타내고

있다.

그림 6

24

그림 6-A

메인 루프 이터레이션을 구현하는 두 가지 방법…

그림 6 에 표시된 바와 같이 게임 엔티티 내에는 두 개의 집합이 존재한다.

그리고 게임 엔티티는 코어 서비스를 제공하는 응용 프로그램 내부에

존재한다. 카메라 엔티티는 사용자에게 가상 공간의 장면을 제공하는데

가상 공간은 어느 곳이거나 쉽게 나타내 보일 수 있다. 로지컬 스페이스

내의 엔티티는 액션 오브젝트를 이용해 상호작용하며, 이를 통해 가상

공간 내의 상대방이 갖는 가상의 물리적 형태에 변경을 가할 수 있다.

그리고 카메라 엔티티는 변경된 새로운 그림을 나타내는 것이다. 폼

오브젝트가 메쉬를 어떻게 변경하느냐 하는 것은 문제가 되지 않는다.

메쉬의 버틱스를 실제 변경하는 것은 디스플레이 서비스가 담당하고 있고,

이것은 행렬 계산이나 모션 캡쳐 애니메이션 등 다양한 방법으로 구현될

수 있다. 문제는 얼마나 빠르게 액션 오브젝트가 업데이트를 실행할 수

있느냐 하는 것이다.

렌더링 시스템은 작업에 상당히 많은 시간을 요구한다. 만약 오브젝트가

그들이 하고 있는 일을 제 때에 업데이트해주지 못한다면 다른 모든

것들이 다 제 때에 표시되지 못한다. 바로 여기에 이 시스템의 강점이

있다. 이 시스템에서는 액션 오브젝트를 가능한 액션들과 현재의

액션으로 구분한다. 로지컬 스페이스에서 엔티티를 따라 시스템이 작동할

25

26

때 현재 액션의 집합에 걸쳐 이터레이션이 진행된다. 그리고 바로 그

집합에 속한 액션 오브젝트들의 코드만을 실행하는 것이다. 액션이

취소되면 그것은 다시 가능한 액션 집합으로 분류가 변경된다. 이러한

방법을 이용하면 메인 루프의 동일한 이터레이션에서 한 가지 액션을 두

번 실행하는 것을 회피할 수 있다. 그리고 현재 액션 집합에 포함된

코드들만이 실행되므로 상당히 많은 프로세서 시간을 절약할 수 있다.

만약 엔티티가 아무 액션도 수행하지 않으면 액션 코드는 아무것도

실행되지 않을 것이다. 어떤 것을 실행해야 하는지를 검사하기 위한 조건

판별조차도 필요 없는 것이다. 동시에 메쉬 오브젝트 이터레이션을 통해

현재의 데이터를 이용해 엔티티를 렌더링할 수 있다.

다른 한편으로 액션을 호출하기 위해서는 엔티티가 할 수 있는 가능한

액션들이 무엇인지 사람이나 AI 가 질의하고, 만약 어떤 액션이

존재한다면 그것을 호출하는 것이다. 이것은 일반적으로 입력 이벤트에

속하는 것이기 때문에 무슨 액션이 호출되었는지를 판단하기 위해 복잡한

조건 구문을 작성할 필요는 없다. 액션은 이벤트에 의해 간단히 호출되는

것이다. 예를 들어 사용자가 어떤 키를 누르면 게임 토큰이 달려가는

액션을 취하게 되는 것이다. 그리고 동일한 입력 이벤트가 그 액션을

취소할 수도 있다. 일부 액션 오브젝트들은 액션이 계속되어야 하는지

아닌지를 자체적으로 판별하는 논리 구조를 갖고 있다. 그러나 이 조건

판별 논리는 액션 오브젝트 자체 내에만 포함되어 있는 것이다. 그리고 이

액션이 일단 유효하지 않은 것으로 변경되면 현재 실행 중인 액션

집합에서 제외되고 엔티티의 가능한 액션 집합으로 다시 속하게 된다.

게임 디자이너가 원하는 바에 따라 액션 오브젝트가 정확히 무엇을 할

것인지 결정된다.

나는 앞서 이 게임 개발 시스템을 이용하여 게임을 개발하면, 처음부터

멀티 플레이어 용으로 만들지 않더라도 나중에 다 완성된 게임을 완전히

새로 고쳐 만들지 않고도 멀티 플레이어 기능을 지원할 수 있도록 할 수

있다고 주장한 바 있었다. 이것은 결코 실언이 아니다. 디스플레이

27

시스템이 완전히 독자적으로 만들어지고 고유한 방법으로 최적화가 될 수

있듯이 커뮤니케이션 서비스도 그렇게 될 수 있다. 게임 자체는 네트웍

서비스가 어떻게 작동하는지 전혀 상관할 필요가 없다. 게임은

전달하고자 하는 데이터를 네트웍 서비스에 제공하고, 또 반대로

네트웍을 통해서 전달받은 데이터를 처리하기만 하면 된다. 최근의

전형적인 MMOG 에서는 결국 이것은 플레이어의 아바타 데이터를

의미하는 것이다. 이 시스템의 게임 토큰은 결국 아바타를 나타내고, 게임

토큰은 액션 오브젝트를 이용하여 작용을 가하므로, 네트웍을 통해

통신을 한다는 것은 결국 액션과 ReportToCommService()를 만들고

엔티티/토큰이 이것들을 호출할 수 있는 기능만을 제공하면 처리되는

것이다. 토큰은 그것이 전달하는 데이터에 무슨 일이 일어나는지 상관할

필요가 없고 그 액션을 취하기 전에 어떤 것이든 상관 없이 처리할 수

있다. ReportToCommService() 내부의 코드는 그 액션을 안전하고

안정적으로 실행하기 위해 필요한 것이면 어떤 것이든 상관 없다. 나아가

일단 액션과 ReportToCommService()을 정의하고 나면 시스템 내의

어떤 토큰이든 그것을 이용할 수 있고, 이것이야말로 이 게임 시스템의

진정한 장점이라고 할 수 있다.

결론

그림 6 은 실행되는 응용 프로그램이 논리적으로 어떤 모양을 띠고

있는지를 아주 추상적인 수준에서 보여주고 있다. 나는 이 글에서 게임

토큰이란 용어를 많이 사용하였는데, 게임 프로그래머들이 흔히 간과하는

것은 게임 자체도 하나의 토큰이 될 수 있다는 것이다. 지금까지 서술한

프레임워크의 관점에서 보면, 이것은 게임 스페이스의 프레임워크의

집합에 속하는 클래스라고 할 수 있다. 그림 6 에 보이는 ‘게임 엔티티’는

말 그대로 이 시스템에서 사용하고 있는 엔티티 오브젝트이다. 이것은

로지컬 스페이스에 포함되는 것으로 나타내어질 수도 있고, 거기에

존재할 가능성이 가장 크다. 그리고 다른 엔티티 오브젝트와 마찬가지로

이것도 액션 오브젝트를 포함하며 다른 엔티티들에게 작용을 가할 수

28

있다. 그리고 None 이라고 정의된 폼 오브젝트를 포함할 가능성이 크고,

액션 오브젝트를 통해서 다른 게임 오브젝트와 상위 수준의 게임 작동

방식 사이의 자연스런 인터페이스로 존재할 것이다. 그러므로 게임 그

자체도 다른 게임 토큰들을 제어하는 토큰인 것이다.

게임 토큰이라는 개념은 아무리 강조해도 지나침이 없을 정도로 중요하다.

만약 게임 자체가 하나의 엔티티 오브젝트라면, 게임도 다른 모든

토큰들이 갖고 있는 상호작용의 기능을 다 갖고 있을 것이고, 게임 속의

어떤 토큰도 이 상호작용 프레임워크를 통해서 조작할 수 있을 것이다. 좀

더 실용적인 예로 엔티티 팩토리라는 개념을 생각해볼 수 있다. 그것

자체로서는 게임이라고 할 수 없는 게임 토큰을 프로그래머가 제작한다.

이 프레임워크를 통해 디자인된 토큰은 자기 완결적이므로, 이

프레임워크를 이용해 제작된 게임이라면 어느 것이거나 이 토큰을 사용할

수 있다. 그러므로 프로그래머가 엔티티 팩토리를 구축하여 환경 설정

파일로부터 게임 토큰을 개체화하는 것이 가능할 것이다. 이 환경 설정

파일은 게임 토큰을 생성하기 위해 고안된 툴로부터 나올 수도 있고,

스크립트로 작성할 수도 있다. 그리고 게임 그 자체가 하나의 엔티티

팩토리가 되는 것이다. 환경 설정 파일을 통해 제공되는 구현 룰에 따라

게임 엔티티들은 상호작용 프레임워크를 이용하여 개체화되고 환경이

설정된다. 이를 통해 엔티티들의 모양과 행동이 제어된다. 사용자가 실제

보는 것을 통해(토큰 환경 설정에 의해 정의됨) 게임을 정의하겠지만, 이

시스템은 사실상 모든 게임에 아무 차이가 없도록 만든다. 그리고 이것은

극도로 빠른 속도로 게임을 개발하는 것을 가능케 할 것이다.

게임을 엔티티로 처리하게 되면 많은 것들이 가능해진다. 엔티티

클래스의 하나로 정의된 게임 자체는 런타임에 하나의 오브젝트로

개체화될 것이다. 그리고 그런 전제 속에서 활용될 것이다. 그 뿐 아니라

이 개발 시스템에 포함된 다섯 개의 기본 오브젝트들은 완전히 재사용이

가능하고 다른 게임 엔티티들과 호환성을 갖게 될 것이다. 게임을

작동하는 동시에 게임을 개발하는 것을 상상해보라. 게임이 이미

29

실행되고 있는 도중에 게임의 일부분들을 실시간으로 네트웍을 이용해

교환하고 그 변화를 실제 상황에서 관측하는 것이다. 좀 먼 미래의 일처럼

들릴지 모르지만 이것은 결코 불가능한 이야기가 아니다. 이 시스템이

그러한 수준으로 충분히 발전해갈 수 있을 것이다. 아직 먼 미래의

일이지만 분명히 올바른 방향을 향하고 있다. 자, 이제 이런 개념을

이해하였으니 여러분들도 지난 20 세기 식의 게임 개발 방식을

극복하기를 바란다.

ⓒ 2003-2004 DevMaster.net. All Rights Reserved.