하드코어 게임에서 웹으로의 이동 : Making History(역사 만들기)

작성자 : 매트 시그밀러 (Matt Seegmiller)
가마수트라 등록일 : 2010년 1월 5일

Making History II 발매가 다가오는 시점에서, Muzzy Lane Software의 The War of the World는 3D 전략 게임이 웹 브라우저로 도래를 가져왔고, 멀티 플레이어 경험을 더욱 할 수 있게 하는 특징으로써, 그 회사가 나아갈 새로운 길을 보여주고 있다.
Making History II: The War of the World

MHII는 Sandstone 상에서 만들어진 것이다. Muzzy Lane에서 사회적 네트워킹 특징을 가진 3D 브라우저를 기본이며 웹을 통합한 게임을 위한 새로운 플랫폼이 나왔다. 이러한 기술은 Muzzy Lane에서 중학생 과학 수업을 위한 게임 개발을 선도하는 Clearlab Project를 포함한 어려운 게임 프로젝트을 해낼 수 있는 능력을 갖게 해주었다.

MHII를 구축함으로, Muzzy Lane은 다양한 엔지니어링 도전 과제들을 직면하였다. 즉, 웹 브라우저에서 어떻게 3D 게임을 최상으로 렌더링 할 수 있을까? 후위 처리 장치(backend) 서비스를 어떻게 접근할 것인가? 내용물(content) 배포는 어떻게 다룰 것인가?

이 글에서는 Muzzy Lane이 직면했던 이러한 도전과제들과 그 문제를 어떻게 해결해 나갔는지에 대해 살펴보고 논의해보고자 한다. 그리고 Sandstone backbone을 구성하는 여러 핵심적인 디자인 결정들과 Making History와 더불어 다른 Muzzy Lane의 게임들이 플레이어들에게 역동적인 경험을 제공이 가능하게 해주는 디자인 결정들에 대해 설명할 것이다.

브라우저에서 3D Games 렌더링 하기

첫 번째 엔지니어링 도전과제 중에 하나는 브라우저에서 3D 게임을 실행시키는 최선의 방법을 결정하는 것이다. 진실로, 우리는 웹을 기초로 한 게임을 구축하는데 확실히 전념했으나, 브라우저에서 하는 게임적인 사고로 충분히 전념하는데 다소 시간이 걸렸다.

본래, 우리는 브라우저에서 막 발매될 게임들을 구축하고 개별로 운영할 계획을 갖고 있었다. 이렇게 개별 어플리케이션으로 하면 이행하기가 더욱 쉽기 때문이었고, 한편으로는 3D게임들을 항상 꽉 찬 화면(full screen)으로 실행하기 때문이다. Flash 게임들은 브라우저에서 확실히 플레이가 되지만, 하드코어 3D 게임들도 실제로 되는가?

그러나 유튜브 비디오, 포드캐스트 그리고 e-book 리더스와 같은 웹 컨텐츠를 보면 볼수록, 그것을 접하며 갖는 감각은 적어지게 된다. 브라우저에서 플레이할 수 있는 3D 게임들은 꽉찬 화면을 옵션으로 선택하여 감각을 갖게 해준다.

Making History II: 브라우저를 기초로 한, The War of the World는 Muzzy Lane Software의 Sandstone 플랫폼 상에 구축되어진 완전히 웹 통합적 WWII 전략 게임이다.

Making History II: The War of the World, a browser-based, fully web-integrated WWII Strategy Game,

built on Muzzy Lane Software's Sandstone platform.

그것은 브라우저 윈도우에서 3D 그래픽을 가속화하는 하드웨어를 렌더링 하기에 전혀 어렵지 않은 것으로 판명되었다. 그래서 기본적인 윈도우 상에서 극복해야 하는 어려운 문제들은 한 개의 윈도우를 처리하며 해결할 수 있다. (이것은 리눅스나 Mac OS X에서 되는 것과 유사하다.)

브라우저 plug-in을 사용하므로, 대부분의 브라우저에 있는 3D 솔루션이 최근 이러한 문제를 해결하였다. 그러나 이에 대한 두

가지 단점이 있다. 첫째로, 많은 사람들은 custom browser plug-ins을 신뢰하지 않는다. (Flash와 Java plug-ins 은 예외이다.)

둘째로, 각각의 브라우저 플러그 인은 브라우저마다 매우 상세하다. 심지어 Mozilla plug-in 건축은 많은 부라우저를 지원하고 있지만, 여전히 각각의 개별 브라우저를 위해 약간씩 종종 비틀기를(tweak) 해 줄 필요가 있다. 이것은 결국 밤새 관리해야 하는 상황이 되기도 한다.

우리의 해결책은 대신 Java extension을 만들어 내는 것이었다. 일반적으로, Java applets 은 클라이언트 머신으로 접근을 다소 어렵게 하는 안전한 sandbox로 운영되고 있다. 이것은 종종 실행되는 본래 코드를 허락하지 않으며, 하드웨어 가속화를 위해 필요하다고 한다.

이러한 방식은 클라이언트 머신 상에 설치되어진 Java extension을 만드는 것이다. Java extension에서 앤드 유저가 그것을 설치하도록 되어 있기 때문에, classes는 신뢰되어지는 것으로 여겨지고 있다. 이러한 classes 문제없이 본래 코드를 내려 받고 작동시킬 수 있다. 일단 Sandstone Player가 설치되어지면, (Java extension을 포함하여), applet class는 각 페이지 마다 놓여진다. 이러한 applet은 내용이 어떤 것이든 필요한 것은 다운로드 받을 수 있고 디스크에 그것을 저장할 수 있다.

한번 이러한 컨텐츠가 다운로드 받아지면, 게임 엔진을 다운로드 하면서, 막 다운로드 되어진 C++코드를 받은 Java에서 C++로 call이 만들어진다. 이러한 엔진은 운영되기 위해 다운로드 된 패키지로 불리며, 서버로 연결할 수 있게 한다. 가장 중요한 점은, 자바에서 애플릿에 의해 만들어진 본래의 윈도로 그것이 처리할 수 있게 생기고, C++에서 접근할 수 있게 된다. 이것은 엔진이 장소를 제공하게 하며, 브라우저에 웹 페이지가 실제로 생기게 한다.

브라우저와 C+ 사이에서 심(shim)으로써 자바를 사용하는 이 해결책은, 그 자체가 가진 단점들이 있다. 클라이언트 머신 상에 설치되어진 자바에 의존적이라는 점이 있다. 이것은 보통의 경우이지만, 그렇지 않을 때는, 앤드 유저가 인스톨을 해야만 한다.

자바 확대 장치 (Java extension mechanism)는 표면적으로 브라우저를 다시 시작하지 않고 설치할 수 있게 하여, 그 확대 설치하는 것을 지원한다. 이것은 항상 브라우저를 다시 시작하지 않고 샌드스톤 플레이어를 설치할 수 있고, 게임을 다운로드 하고, 게임을 할 수 있도록 웹 페이지에 누군가 들어가는 것을 허락해주며, 그리고 자바 인스톨이 이미 된 것처럼 여겨지게 하는 것이 큰 특징인 것 같다. 이것은 우선적으로 이 방식이 선택한 주요한 이유중에 하나이기도 하다.

실제로, 항상 그렇게 작동되는 것은 아니다. 확대 장치는 다운로드 할 때에 유저에게 피드백이 거의 없다. 빠르게 화면상에서 진행상황을 보여주기 위해서는, 설치되고 있는 나머지 것을 다운로드 하는 인스톨러를 매우 작은 것으로 사용해야만 한다.

게다가, 자바 플러그-인은 확대 설치자(extension installers)를 관리자로써 운영하는 환경에서 문제를 가지고 있다. 심지어 UAC의 모든 후프(hoops)가 적절하게 되었을 때에도 문제를 보인다. 잠시 동안, Sandstone Player은 매뉴얼 설치자가 되고 브라우저는 설치의 일부로써 다시 시작되어져야만 해야 하는 결과를 가져온다. 그렇지만 좋은 점으로는, 자바 플러그-인은 브라우저의 세부 문제 모두를 다룰 수 있어서, 우리가 매번 브라우전 기초로 하기보다는 각각 플랫폼의 기초 위에 무언가 기초로 세우고 관리하면 되도록 해준다. 결과적으로, 우리는 윈도우상에서 많은 다른 브라우저들에서 플레이어를 운영시킬 수 있게 되어졌다. IE와 Firefox, 심지어 Chrome과 Opera는 모두 특별한 코드나 기타 지원 없이도 작동되고 있다.

The Sandstone platform supports true hardcore 3D games, like Making History II in the browser.

Sandstone Player, but also the Java plug-in.

후위 처리 장치(Backend)서비스를 운영하기

초기에, 우리는 Sandstone을 지원하는 후위 처리 장치(backend) 상에 운영되는 수많은 서비스가 필요할 것이라 깨닫게 되었다. 이러한 서비스들은 각각 다른 서비스에 말을 할 필요가 있고, 사람들이 게임을 플레이 할 수 있도록 하는 웹 서버에 의해 접근할 수 있도록 일부 서비스가 필요하였다. HTTP 요청이 되는 이러한 서비스를 위하여 우리는 API의 대부분을 갖도록 선택하였다.

이것은 거기에 어떤 언어가 사용될지는 상관없이 Sandstone서비스에 말을 걸 웹 프레임웍을 수월하게 해준다. (대부분의 웹 프레임워크의 근본적인 능력이라 할 수 있는) HTTP요청을 하는 동안, 그것은 서비스들과 상호작용을 할 수 있다.

초기에, 대부분은 데이터는 XML로써 앞뒤로 통과하게 된다. 대부분의 데이터가 간단한 데이터이기 때문에, 이것은 다루기 불편한 것으로 판명되었다. 결국, 우리는 이 데이터를 위해 평균 XML보다 훨씬 더 작고 우리가 사용하는 언어에서 훨씬 분석하기 쉬었던 JSON을 사용하도록 변경하였다.

이러한 서버 APIs가 HTTP요청에 따라 이행되어진 이후로, 우리는 HTTP요청을 이행시키기 쉬운 언어를 사용할 필요가 있었다.

우리가 PHP 혹은 Ruby 대신에 매우 일관성 있는 언어인 Python을 사용하는 것을 선택하였다. 그것은 웹 서버를 많이 보완해주며 쉽게 C++코드와 연결될 수 있다. 즉 게임 서버 운영을 위해 매우 용이하다.

※ 자세한 내용은 첨부(PDF)화일을 참고하시기 바랍니다