［GDC 2013］Webブラウザで「Unreal Engine 3」がヌルヌル動く!? ゲームエンジンを5日でHTML5へ移植した驚きの技術とは

　Game Developers Conference 2013（以下，GDC 2013）の2日めとなる米国時間3月26日，Webブラウザ「Firefox」の開発で知られる米Mozilla Foundation（以下，Mozilla）が，「Fast and Awesome HTML5 Games」（高速かつ驚愕のHTML5ゲーム）と題するセッションを開催した。
　HTML5はそのポテンシャルが高く評価されてはいるが，実際にそれで作成されたゲームを見ると，「Webブラウザ上のゲームならこんなものか……」と落胆させられるものが多い。そのため正直に言えば，筆者はあまり期待せずに参加したのだが，蓋を開けてみれば，たしかにタイトルどおり「Awesome」な内容だったのだ。

HTML5でUnreal Engine 3がヌルヌル動くぞ

　というわけでさっそくだが，下に示した直撮りムービーを見てほしい。これは，Webブラウザ上で動く，「Unreal Engine 3」（以下，UE3）のデモである。
　一見，UnrealっぽいFPSが動いているだけだが，UE3をWebブラウザ上で動かすプラグインを使っている……わけではない。「WebGL」と「JavaScript」という，HTML5が持つ要素だけでこのデモは動いているのだ。


　ムービーを見れば，ゲームとしてプレイ可能なフレームレートで，相応のグラフィックス品質を保ったまま動作しているのが分かるだろう。
　デモプレイ中はフレームレートが示されなかったが，別途披露されたベンチマークテストによれば，今回のデモでおおよそ30〜90fps程度のフレームレートが出るとのことだ。今日（こんにち）のゲームPC上で動作させるのと比べれば低いフレームレートかもしれないが，十分に実用的なレベルだといえる。

HTML5で作られたUE3によるベンチマークの1シーン。左下にフレームレートの数値（ここでは90fps）が表示されている。シーンによってかなり変動するが，描画負荷の低いシーンでは写真のように90fps程度，高いシーンでも30fps程度はマークしていた

　HTML5だけでこれだけ動くゲームを作れるというのは相当に衝撃的だが，実のところ筆者が一番驚いたのは，このHTML5版UE3のデモが，わずか5日で移植されたと明らかになったときだった。
　本セッションでは，MozillaのVladimir Vukicevic（ウラデミール・ブキチェビッチ ）氏とAlon Zakai（アーロン・ザカイ）氏が，「いかにしてHTML5版UE3を開発したのか」を語ってくれたので，順にお伝えしてみたい。

Vladimir Vukicevic（Engineering Director, Mozilla）

Alon Zakai（Senior Researcher, Mozilla）

　セッションは，まずVukicevic氏が「ゲームプラットフォームとしてのHTML5の現状」について説明したあとで，Zakai氏がUE3のようなゲームエンジンの移植を可能とする技術について解説するという流れで進められた。

C＋＋からJavaScriptに変換するトランスレータは

「人が書いたJavaScriptより速い」

最新のHTML5対応Webブラウザがサポートする，さまざまな機能やAPI群。赤はストレージやネットワーク関連，青がグラフィックス関連，緑は言語関連で，茶が入力デバイスやサウンド関連

　Vukicevic氏は，「HTML5を実行できる最新のWebブラウザは，ゲームを実行するに十分すぎるほど，豊富なAPIや機能を持っている」と述べて，スライドでそれらのAPIや機能を挙げて根拠を示した。
　ストレージやネットワークへのアクセス，グラフィックスなど多彩な機能やAPIがWebブラウザ上でサポートされているわけだが，Vukicevic氏は「Xbox 360用ゲームパッドも使える」と述べ，入力デバイス系のサポートもすでに実現されていると強調。今後はHTML5から，マルチタッチ対応のタッチパネルや，加速度センサーといったセンサー系デバイスも使えるようになるとの見通しも示している。

　そんなHTML5プラットフォーム向けにゲームを開発する場合，「2つの方法がある」とVukicevic氏は述べる。1つはJavaScriptなどを使って，一から開発するという方法だが，もう1つは「既存のゲームをHTML5に移植する」方法だ。
　Vukicevic氏はHTML5への移植を可能にする技術として，「EMSCRIPTEN」と「ASM.js」という，2つのミドルウェアを挙げた。今回の「UE3のHTML5」移植にも，これらのミドルウェアを使ったという。

　続いて登壇したZakai氏は，EMSCRIPTENとASM.jsの詳細について説明した。
　まずEMSCRIPTENとは，ゲーム開発によく使われるプログラミング言語「C」や「C＋＋」のソースコードを，HTML5アプリケーションを記述するJavaScriptに変換するトランスレータだ（関連リンク）。オープンソースのコンパイラプラットフォーム「LLVM」を基盤にしているそうなので，C言語やC＋＋以外のソースコードをJavaScriptに変換することも，原理的には可能だろう。

EMSCRIPTENはC＋＋からJavaScriptコードを生成するトランスレータ。ASM.jsは，EMSCRIPTENが出力したJavaScriptコードの実行を高速化する，JavaScript拡張のような技術だ

EMSCRIPTENは，LLVMが出力した中間コードを，さらにJavaScriptに変換する。LLVMが扱えるプログラミング言語なら，原理的にはJavaScriptに変換できるだろう

　EMSCRIPTENはCやC＋＋のソースコードからJavaScriptへの完全な変換が可能で，「面倒な手作業は必要ない」とZakai氏は述べている。多くのゲームやゲームエンジンはCやC＋＋で書かれているので，EMSCRIPTENを使えば，簡単にJavaScriptへと変換可能というわけだ（※ハードウェア性能の違いを棚に上げておけば，だが）。

EMSCRIPTENが出力したJavaScriptは手で書いたコードより速いのだという。その鍵は……

　しかも，「EMSCRIPTENで変換したJavaScriptは，人間が書いたJavaScriptより高速だ」とZakai氏。にわかには信じがたく，ソフトウェア開発者からすれば，「そんな都合よくいくものかね？」と言いたくもなるだろうが，Zakai氏が挙げた理由を聞くと，納得できる部分がある。

　その秘密は，最新のJavaScriptがサポートしている「型（かた）付き配列」を使う点にあるそうだ。JavaScriptは基本的に，「整数型」とか「文字列型」といった型が，変数にないプログラミング言語だ。型がないといっても，実際は内部的に使っているのだが，動的に型が決められることから「動的型付け言語」などと呼ばれることもある。

型付き配列の使用例。「Int32Array」は「32bit 整数型配列」で，型の決まった配列を使うと，非常に高速化されるそうだ

　この動的型付けは，ソフトウェア開発者にとっては開発を楽にしてくれる利点がある一方で，処理負荷が大きいことが知られている。そのため最新のJavaScriptでは，型付き配列をサポートしたのだが，「これを使うと処理が非常に高速化される」（Zakai氏）。EMSCRIPTENで変換したJavaScriptが，人間の書いたJavaScriptより高速なのは，この型付き配列を多用するコードに変換するから，というわけだ。

　EMSCRIPTENがどのくらい速いのか，Zakai氏はメモリコピーといった単純な処理を使うベンチマークプログラムを作成し，FirefoxとChrome，およびネイティブコード（通常のアプリケーション）で実行したテスト結果を，下のスライドで示した。EMSCRIPTENは，小さなコードに対してとくに高い効果を発揮するそうだ。

ごく単純な処理を繰り返すベンチマークテストで，ネイティブコードとEMSCRIPTENの変換コードの速度を比較したグラフ（短いほうが高速，以下同）。Mozillaがライバル視している「Chrome」が併記されているのはご愛嬌として，Firefoxとネイティブコードとの差は，せいぜい3倍以内で収まっている

　しかし，コードサイズが大きいゲームのようなアプリケーションになると，EMSCRIPTENの効果は大幅に落ち込む欠点もあると，Zakai氏は明らかにした。「コードが複雑になり，変数や関数が増えると，（変換時に）型を決めるのが難しくなるため」（Zakai氏）とのことだ。

zlib（圧縮），Skinning（色の平滑処理），bullet（数値演算ライブラリ）という，やや複雑な処理によるベンチマークテストで，EMSCRIPTENとネイティブコードの実行時間を比較。小さなコードを用いたテストとは対照的で，10倍以上の時間がかかってしまうものもある

EMSCRIPTENの弱点をカバーするASM.js

ASM.jsで書かれたstrlen関数（文字列の長さを調べる関数）のサンプル

　EMSCRIPTENによる変換コードは，大きくて複雑なアプリケーションになると，速度の低下が顕著になる。これを解決するのが，先ほど2つめの技術として紹介したASM.jsだ（関連リンク）。考え方の基本はEMSCRIPTENと同じで，JavaScriptを型付きの言語にしてしまう拡張である。

　ASM.jsを使うと，JavaScriptでも変数型が使えるようになるのだが，ここで導入される変数型は，人間の手作業によるプログラミングで使うことが考慮されていない。あくまでも，EMSCRIPTENのようなトランスレータが，型付きで出力したソースコードを使うのが基本だという。サンプルコードでは「『|0』は整数型」と書かれているが，こんな表記は人間には理解しにくいので，確かに機械的な変換で使うのが妥当だろう。

　ASM.jsにはもうひとつ，「Ahead-Of-Time^※1コンパイル」という処理で可能な限り最適化を行い，そのうえで実行するという特徴もある。
　下に示したのが効果を示したグラフだが，EMSCRIPTENのみでは成績が悪かった「大きめコードを用いたベンチマークテスト」であっても，ASM.jsを使えば，ネイティブコードとの差が2倍程度まで縮まっている。たしかにこの効果はすごい。
^{※1：AOT，「事前に」といった意味。}

大きめのベンチマークテストを，ASM.js使ったコードで比較したグラフ

UE3のHTML5移植はわずか1日で完了！

UE3を移植するのにかかった期間は，わずか1日！

　セッションには，EMSCRIPTENとASM.jsを使ってUE3をHTML5に移植した，Epic Gamesの担当者がゲストとして登壇。移植のポイントを簡単に解説した。
　インパクトがあったのは「移植に要した時間」で，Epic Gamesの担当者によれば，コードをHTML5に移すだけなら1日で完了し，実際に動くようになるまでも5日しかかからなかったという。これほど短期間で移植が完了したのは，EMSCRIPTENとASM.jsを使うことにより，C＋＋で書かれているUE3のほとんどを自動変換できたためだろう。

短時間で移植できた理由。自動変換に加えて，UE3がWebGLに容易に対応できたこと，OpenALラッパーを作ることで，WebAudioに迅速に対応できたことが鍵だという

　ただ，ここまで短期間での移植を可能にした要因は，それだけではない。たとえば，HTML5の3DグラフィックAPIである「WebGL」が，「OpenGL 2.0」のラッパー^※2であるため，OpenGL ES 2.0対応のUE3を使うことで，最小限の変更でWebGLに対応できたというのも大きな理由だ。また，UE3がサウンドAPIに「OpenAL」を使っていたため，そのラッパーを作ることで，サウンド周りも容易にWebAudio APIへの移植ができたという。

^{※2：あるAPIを包む（ラッピング）ように内包して，ほかのAPIや言語から，その機能を利用しやすくする技術。}

移植で判明した問題点。まだ実験的な段階にあるASM.jsは，Webブラウザ側のサポートがまだ安定していないと強調している

　ここまでは，移植作業が困難もなく順調に終わったように聞こえるが，当然ながら，まだいくつかの問題点も残っているとのこと。とくに，Webブラウザ側のASM.jsサポートがまだ不安定という点は強調されており，Zakai氏は，ASM.jsを使う場合，Firefoxの開発版最新ビルドである「Nightly Build」を用いるよう呼びかけていた。ちなみに，Nightly Buildとは，Firefoxの開発版最新ビルドのことだ。

　最後に，将来の話にも目を向けよう。まず次世代の「Unreal Engine 4」（以下，UE4）は，OpenGL ES 2.0対応版が開発中だという。それが完了すれば，UE4もHTML5で動くようになるだろうとのこと。ASM.jsがまだ実験段階という制約もあり，実用できる技術というわけではないが，今後の応用に期待は膨らむ。

　Epic Gamesは移植を通じて，Mozilla側に不具合や改良点などをフィードバックしているとのことで，Mozilla側もまた，それを受けて迅速に対応を進めているという。近い将来，HTML5で作られたゲームが，今までのブラウザゲームの常識を覆す可能性は，十分にあるといえそうだ。

Mozilla 公式Webサイト（英語）

Unreal Engine 公式Webサイト

Game Developer Conference公式サイト