ネットワークのないところでも使え、サクサク動く。これからのWebゲームアプリが備えるべき機能とは「HTML5 Conference 2013」

今後モバイルWebアプリはどこを目指すのか──。このヒントが得られたのが、DeNA小原隆郎氏の「地下鉄 x サクサク x これからのWebゲームアプリが備えるべき8つの機能」というセッション。

小原氏は昨年秋にDeNAに入社。「@uupaaというネームは知っている人もいるかもしれないが、ほとんどこのような場所に出ることがない。今日会えた人はラッキーだと思う」という前置きをしてセッションは始まった。

SPAでページをまたがった音楽の再生が可能に

同セッションは検証は必要ながらも、小原氏自身が気になっているWebアプリの技術的なトピックスを紹介するというもの。

まず最初に取り上げたのはネイティブにアプリにできてWebアプリにできないこととは何か。

• 電波のないところでは遊ぶ
• たくさんの映像やデータを扱う
• 音を鳴らす
• 3Dで動かす

このようにWebアプリにはでいないことが結構あるが、これらができなくてもせめて「サクサク感」はほしい、というのは万人の望み。とはいえ、従来のサーバからファイルを都度、ダウンロードするWebアプリには待ち時間という弱点がある。

サクサク感を出そうとしても明確な限界があり、いくら回線が速くなっても端末スペックが上がっても、今後コンテンツがリッチになればなるほど遅く重くなっていく。

これを解決する機能として小原氏が注目しているのが、「Single Page Application（SPA）」である。従来とは違い、SPAは基本となる画面が1つだけ存在し、次々と内容を書き換えていくWebアプリだ。
「開発者にとって何がうれしいかというと、進行に必要なデータをサーバから動的に取得し、アプリ側で情報の先読みを行うなど、これまでブラウザに任せていた部分が自分たちでチューニングできるようになること」

またSPAであれば次のようなことが可能になる。

• ページをまたがった音楽（BCM）の再生が可能になる。これによりゲームへの没入間が高まる。
• 電波が来ない環境でWebアプリをある程度動作させられる。ページの読み込み時間は800msから200msになるため、別次元のサクサク感を演出できる。

さらに「余計な話」とした上で「サーバサイドにすべてのロジックを置く必要がなくなる」ことも紹介した。しかし、SPAには次のような課題がある。

• チート対策（結果をバリデーションする仕込が必要）
• 従来の作り方とは大きく異なるので、現場にノウハウが蓄積されていない

だから、「今のところ頑張って移行する理由がない」と小原氏は語る。

WebAudioでBGMとSEの同時再生が可能になる!?

次に取り上げたのは「WebAudio」。従来のオーディオタグはストリーミングによるBGMの再生しか期待できなかったが、WebAudioならBGMとSE（Sound Effect：効果音）の同時再生が期待できるというのだ。

現在、WebAudioをサポートしているのはChromeとMobile Safariだが、この両者においては「使えるレベルで実装されている。しかも試したところ負荷も高くない」と小原氏は説明する。

Android2.3やiOS5など、この機能が使えない端末ではaudioタグを使ったSoundSpriteで、擬似的だが再生可能だそうだ。 今後、いずれは音階や音の長さといった情報からブラウザ上でリアルタイムに動的な波形を生成する（いわゆるMIDIファイル）という使われ方が可能になる。
「メモリを潤沢に利用できるようになったら、モバイルブラウザ上でチップチューンをこ流せるようになるかも」と、小原氏は期待を込める。

WebAudioの懸案事項として小原氏は次の4点を挙げた。

1. いきなりフルサウンドのゲーム開発は無理 理由は「Web開発の環境に音に対するノウハウは蓄積されていないから」（小原氏）だそう。したがって最初はSEだけということから始めるのが得策だ。
2. 波形の動的生成はまだ無理（ブラウザがメモリをあまり使えないため）
3. ボトムラインを設定し、機能をOFFにする対策が必要

「ライブラリ側でON/OFFする端末のカタログを持っておくという対策が必要になる」と小原氏。またAndoridの最低スペックはDual Core、1GBRAM、iOSは7、iPhone 4Sがボトムラインだそうだ。
「まだこの分野はほとんど誰もやっていないため、今なら差別化になる。チャレンジャーを募集している」と呼びかけた。

高解像度化が続くモバイル端末への対応

モバイル端末は高解像度化の一途をたどっている。端末の65～70％が200dpi以上解像度を持っており、326dpiのローエンド端末が登場する時代となっている。そこでCanvasも高解像度のサポートを開始。従来のCanvasRenderingContext2D#toDataURLは96dpi化されたデータを扱う。

また草案では「High Definitionバージョンがメソッドが追加されている」という。しかしImageDataを使ってライブエフェクトかけるには、数十MBを16ms以内に処理しなければならず、forループで回してもビジーループになってしまい、ブラウザのプチフリーズや過負荷によるシステムアラートが発生してしまうことになる。

その解決法として小原氏が期待しているのが「WebWorker」だ。WebWorkerでCanvasと聞くと「えっ」と感じる人もいるかもしれないが、最新のCanvasの仕様には実装はまだだが以下のようなメソッドが追加されている。

• canvas.transferContorolToProxy
• canvasProxy.setContext
• context.commit

夢は大きく膨らむが、無理もある、と小原氏は続ける。メモリ関連の改善が必要なこと、任意のタイミングでGC（グラフィックスコンテキスト）を発動できる仕組みがないなど、課題があるからだ。
「High Definitionはモバイルブラウザではまだ実用的ではないが、CanvasProxy+WebWorkerにはかなり期待している」

CommandPatternで発生頻度の低い不具合の再現も

第4のトピックスは「CommandPattern（コマンドパターン）」。これはデザインパターンの一つで動作とパラメータを中間言語化（カプセルか）したものである。

例えばゲームをある程度進めると、特定のAndorid端末ブラウザで描画が破綻するという現象があったとする。この不具合を再現するためには、ゲームを進める必要があり、確認するためにその環境を維持することはもちろん、修正後はまた確認しないといけない。「ラスボス登場の場面で現象が出たら、そこまでゲームを進めなければならず、大変」と小原氏。

また最小化コードを見つける作業も大変だ。これを解決するのがコマンドパターンというわけだ。つまり描画コマンドの保存と再生の仕組みが導入されればいつでも現象を再現可能になり、サーバがとまっていても調査を進められる。

そのほかにも、発生頻度の低い不具合の再現が簡単になる、最小化コードを見つける作業を大幅に省力化できる、保存しておいたコマンドはエンバグチェックのテストケースとしても再現できるなどが可能になる。
「AndroidブラウザやChrom for Androidの不具合で悩む時間が大幅に短縮されるかもしれない」（小原氏）

また「DrawCallを減らせるという効能もある」という。細切れで実行されるCanvasAPIは複数回のDrawCallを発生させる可能性が高いが、まとめて実行するとDrawCallを最小化できるというのだ。Chrome Canary版の「Canvas profiler」を使うと、DrawCollやCanvasAPIを可視化してくれる。「ぜひ、使ってほしい」（小原氏）

さらに「ゲーム画面のスナップショットと動画の作成も可能、リモートプレイにも展開できるかもしれない」という。

機能強化が続けられているWebWorker、その注目の機能

第5のトピックスは先ほどから登場している「WebWorker」である。「計算だけさせておくのはもったいない」と小原氏。機能強化はひっそりとされ続けており、例えばChromeとSafariでは次のような機能が使えるという。

• importScript
• JSON、BLOB、FileReade、FileRiedeSync
• Timer
• TipeArray
• MessageChannel
• WebSQL、WebSWLSync
• WebSocket、XML Http Request

またChromeでは次のような機能を先行して実装されている

• HighPerformanceTimer-performance now()
• Text Encorder/Text Decorder
• IndexdDB
• WorkerConsole
• ImageBitmap
• RequestFilesystem,RequestFilesystemSymc
• Crypto,Base64

気になるのはPostMessageの通信速度である。「検証は足りないかもしれないが、無負荷状態ならサクサク動く」ことがわかったという。

しかし「荷物が重いと遅くなる」とのこと。1MB程度の負荷ならなんともないが、32MBもの巨大な配列（payroad）を与えると速度が25％程度まで落ちてしまうこともあるというのだ。「巨大なデータの受け渡しはちょっと注意が必要」と小原氏は注意を促す。

WebWorkerは注目に値する技術だが、現在、既存のライブラリやフレームワークで動くものはほぼないという。ただImportScripitがあり、JavaScriptのプロトタイプ拡張をしてもWebWorker上では副作用なく行える。

またWebWorkerが利用できない環境ではiframeでエミュレーションできるという。 「WebWorkerは手つかずのブルーオーシャン。ライブラリを書きたい人には楽しい世界だ」

「Storage」「Cache」「Offline」

最後のトピックスとして紹介したのは「Storage」「Cache」「Offline」。 特にApplicationCacheは利用できるシーンが限られており、「開発者からもあれはないよ」といわれている。 そこで小原氏が注目しているのが。「LocalStrage+WebSQL」を使ったキャッシュである。これは画像やバイナリデータはBASe64化した状態でストレージに保存。取り出した後はDataURLで画像化しなどに埋め込んで利用するというものだ。

また小原氏は「AssetManifest」という考え方を利用しているとも言う。サーバ上でアセットのリストを作成し、ブラウザ側でリストを元にキャッシュを管理するというもの。これにより「ブラウザ任せにしない高度なキャッシュ管理が可能になる」というわけだ。 マニフェストは以下のパラメータが必要になる。

• IDまたはURL
• ファイルサイズ
• MimeType
• ファイルのHash値（MD5hashなど）
• 優先度や保存先などのパラメータ

次世代のStrageはどうなるのか。小原氏はIndexedDB+SrverWorker+DiscQouter ManagementAPIにより、「端末の空き容量の10％がストレージとして利用可能になる予定」と話す。これが整備されると現場の苦悩もなくなるかもしれない。 最後に小原氏は無限ストレージのデモを実施し、セッションを終えた。

【セッション映像】