HTML5 가 게임 제작 방식을 바꿀 것인가?

작성자: 윌 이스트콧(Will Eastcott)
작성일: 2012 년 8 월 29 일

Will Eastcott 는 EA, Sony, Activision 에서 초거대 타이틀을 만들어 냈던 비디오 게임 테크놀로지스트이자, 클라우드 기반 HTML5 게임 개발과 퍼블리싱 플랫폼을 제공하는 PlayCanvas 의 공동 창립자다. 그는 이 글을 통해 급부상하고 있는 HTML5 기술이 게임 개발자들에게 실제로 어떤 영향을 미칠 지에 대한 의견을 공유하고, 게임 개발의 진일보가 이 언어를 통해 이루어지는 사례를 만들고자 한다.

아마 이런 기사 제목을 본 적이 있을 것이다. “콘솔 게임은 죽었다!” “HTML5 가 미래다!”

HTML5 를 둘러싼 논의는 너무 과장된 경우가 많고, 감히 말하건대 편견으로 가득 차 있다. 이런 것들은 일단 뒤로 제쳐놓고, 조금 객관적인 이야기를 하도록 하자. 내 의견을 조심스럽게 제시해 보자면, HTML5 는 비디오 게임 제작 방식을 근본적으로 바꿀 것이다. 그 이유를 설명하기에 앞서 현재 HTML5 의 상황을 요약해보자.

우리가 지난 30 년 이상 보아온 것은 하드웨어 플랫폼이 점점 더 강력해지는 일반적인 트렌드와 그 하드웨어를 전략적으로 더 잘 이용하기 위한 툴과 언어의 발전이었다. 현실을 뛰어넘는 게임 환경에 대한 욕구는 수그러들지 않았고, 콘솔 게임 제작사들은 개발자들의 손에 더욱 강력한 기술을 쥐어주었다.

그러나 모바일 게임이 부상하면서 우리는 새로운 현상을 목격하게 되었다. 게이머들이 어디에서나, 어느 기기에서나, 또 누구든지 함께 플레이할 수 있는 더 단순한 게임에 예외적으로 반응하기 시작한 것이다. 이것이 현재의 유저들이 요구하는 핵심이다. 기술은 여전히 중요하고, 또 잘 만든 그래픽도 여전히 염두에 두어야 한다. 하지만 이러한 게임에서 더욱 중요한 것은 접근성(accessible)과 연결성(connected)이다. 웹 브라우저보다 더 접근성과 연결성이 뛰어난 것이 무엇이란 말인가?

그러면, 이런 게임을 만드는 데 어떤 옵션이 있는가? 그냥 맨 처음부터 만들 수도 있다. 하지만 한 개 이상의 플랫폼을 목표로 설정하는 것은 작은 개발팀에게 무리일 수도 있다. 이럴 때 플래시를 이용할 수 있다. 조금씩 조금씩 매력도가 감소하고 있긴 하지만 말이다. 플래시의 모바일을 지원하지 않기로 한 일과 Stage3D 라이센싱 비용을 둘러싼 명쾌하지 않은 입장은 개발자들에게 좋지 않은 인상을 심어주었다.

Havok Vision Engine 과 Unity 와 같은 엔진을 예로 들어보겠다. 이러한 엔진들은 보통 데스크탑 브라우저는 자사 플러그인으로, 모바일 기기는 고유 실행파일로 지원하도록 되어 있다. 그리고 HTML5 가 있다. HTML5 를 선택하기에 앞서, 이것이 가진 장점과, 약점을 완화시킬 방법을 숙지하는 것이 매우 중요하다. 더 깊숙히 들어가보자.

진화하는 표준

HTML5 는 완성된 것이 아니다. 표준화 위원회인 W3C and WHATWG 에 의해 아직도 개발이 진행되고 있다. 즉 브라우저 판매사는 움직이는 타겟을 쫓고 있는 것이다. 그러므로 HTML5 를 지원하는 수준이 모든 브라우저마다 다를 수밖에 없다. 여기에 대해서는 caniuse.com 라는 사이트에서 자세히 설명하고 있다.

브라우저간 불일치의 가장 대표적인 예가 바로 오디오다. 현재 세 가지 API 가 있는데, Mozilla 의 오디오 데이터 API, Google 의 웹 오디오 API, JavaScript API 의 Audio 엘리먼트가 그것이다. 최근에 Mozilla 는 자사의 API 를 곧 도태시키고, 웹 오디오 개발을 시작하겠다고 선언했다. 즉, 브라우저 판매사들이 개발자의 편의를 위해 일제히 혁신에 나서고 HTML5 플랫폼으로 수렴하게 될 것이라는 점은 자명하다.

특히 게임 개발자들에게 새로운 HTML5 API 를 제공해야 한다는 브라우저 제작사의 공통된 요구가 있다. 중요한 예로 GamePad API (플랫폼에서 지원하는 모든 종류의 게임패드에서 입력을 받을 수 있음), Pointer Lock API (마우스 커서를 숨기고 마우스 동작을 직접 읽음), Fullscreen API (모든 HTML 요소를 전체화면으로 표시)의 세 가지를 들 수 있다.

이들 API 는 짧은 기간 동안 일관성을 가지도록 사양이 정해졌고 많은 브라우저에 구현되었다. 이들을 도입함으로써 1 인칭 슈팅과 같은 류의 게임이 갑자기 HTML5 에서 훨씬 쉽게 돌아가기 시작했다.

자바 스크립트

개발자들은 프로그래밍 언어에 대해 상당히 강한 향수를 품고 있다. 콘솔 백그라운드가 있는 개발자들은 자바스크립트를 의심스럽게 보는 경향이 있다. 자바 스크립트는 새롭게 배워야 하는 언어이면서도 같은 내용의 C++ 코드에 비해서 느리고, 벡터화(vectorization) 같은 최적화 전략도 사용할 수 없다. 게다가 게임 코드는 브라우저의 개발자 툴에서 모두 볼 수 있다.

더글라스 크락포드(Douglas Crockford)의 자바스크립트가 <세상에서 가장 오해받는 언어(The World's Most Misunderstood Programming Language)>1라는 주장을 참고해볼 필요가 있다. C++ 프로그래머에게 자바스크립트 배우는 건 사실 식은 죽 먹기다. 전체적으로 C++과 밀접하게 관련이 있다. 클로저(closure) 같은 컨셉이나 ‘this’ 키워드에는 익숙해져야 할 테지만 말이다.

C++같은 언어의 경직성이나 장황함을 좋아하지 않는 사람들에게 자바스크립트는 환상적이고 다이내믹한 언어다. 1 급함수(first class function)같은 강력한 기능들이 작성해야 하는 코드와 작성시간을 크게 줄여준다. 자바스크립트를 일단 쓰기 시작한 사람들은 다시 돌아가지 않는 것 같다.

퍼포먼스도 생각하는 것보다 좋다. 우선 Web Workers API 로 자바스크립트에서 멀티스레드 프로그래밍이 가능하다. 더 중요한 사실은 자바스크립트 엔진이 지난 몇 년간 크게 발전했다는 것이다. 오픈소스 물리 엔진인 Bullet 에 이미 자바스크립트 포트가 있으며, 자바스크립트를 사용한 매우 CPU 집약적(intensive)인 알고리즘이 –비록 퍼포먼스가 눈부시지는 않아도- 제법 쓸만한 속도로 실행되는 걸 보면 알 수 있다.

톡 까놓고 얘기해보자 - 베끼기는 어느 플랫폼에서나 존재한다. 하지만 HTML5 게임에 관해서라면 몇 가지를 염두에 두어야 할 것이 있다. 구글의 Closure 컴파일러 같은 툴은 소스를 최적화하는데 뛰어난 성과를 보여준다. 애매모호한 소스코드를 분석하는 것은 원래의 코드에 접근하는 것과는 다르다. 코드 베이스의 사이즈가 확장되었기 때문에, 역설계(reverse engineer)하는 것이 점점 힘들어지고 있는 것이다. 두 번째로 어떤 게임에 온라인 콤포넌트가 있다면 많은 코드를 서버에서 실행시킬 수 있고, 클라이언트는 시각화만 담당하면 된다. 많은 “가치”를 서버 안에 숨길 수 있는 것이다.

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