WebGL によるブラウザゲーム開発・調査ノート

2019-11-14

このページは
  • 2019 年に 「今、仕事でブラウザゲームの案件をやるならどういう技術選定になるか」 という調査をする機会があったので、 その調査結果をまとめたもの
  • ※ ここで言うブラウザゲームは、よくあるスマフォ RPG くらいのゲームサイクルがある商用ゲームを想定
    • （インスタントなカジュアルゲームよりも規模が大きいものを想定）
  • ※ 本稿では Server サイドレンダリングなどは考えず、ブラウザ上で行う描画や処理を調査の対象とする

自分の結論
  • 2019 年現在において、モバイルブラウザを考慮しなくてよいのなら Unity で開発して WebGL 出力するのが 最も開発効率が良さそう
    • PC ブラウザと、iOS / Android のネイティブアプリがターゲットなら Unity で問題ない
  • 大人の事情で モバイルブラウザ をターゲットに含める場合、現状 Unity ではパフォーマンス的に厳しい
    • JS のライブラリやフレームワークを利用して、ゲームの要件に合った構築が必要になる
  • 実際問題、Unity の WebGL 出力でモバイルブラウザはサポートされていない：
  • モバイルでまともに動くものを作るならば、ライブラリを組み合わせて JS で実装し、 自前で細かいところをチューニングしていく必要があるだろう（つらそう）
    • 2D ベースであれば Phaser や Pixi.js をベースに、薄いフレームワークを書けば何とかなりそう
    • 3D が要件に入ってくるなら、Babylon.js という選択肢がある
      • チームに手練が多いなら、three.js を内部で使ってフレームワーク全体を自作する道もある
  • 中国では Egret Engine や Cocos がよく使われているようだが、メインの情報源が中国語になりそうなので 中国語が得意でない日本人開発者が採用するには敷居が高いと思う
  • なお PC ブラウザ向けであっても、Unity WebGL 出力はエンジン部分のメモリ消費がそれなりに大きくなること、 アセットの DL 管理もネイティブアプリ以上に気を使う必要があることには留意されたい

はじめに

時系列
時期 出来事
2007 OpenGL ES 2.0
2011-03 WebGL 1.0 策定（W3C 勧告）
2012 OpenGL ES 3.0
2017-01 WebGL 2.0 策定
2017-01 Chrome 56 / Firefox 51 が標準で WebGL 2.0 に対応

基礎知識

WebGL は OpenGL ES をベースに、Web ブラウザ向けに調整された規格。

  • WebGL 1.0
    • OpenGL ES 2.0 の派生規格
  • WebGL 2.0
    • OpenGL ES 3.0 の派生規格

WebGL 2.0 のサポートに必要な要件：

プラットフォーム 要件
Windows DirectX 11
macOS OpenGL 4.1
Linux OpenGL 3.3 + いくつかの拡張
その他 OpenGL ES 3.0

参考リンク：

世の中の対応状況
  • 2019-11 現在において、WenGL 1 はほとんどの環境で使用できるものと思って問題ない
  • WenGL 2 は Mac / iOS の Safari が対応しておらず、商用ゲームに使える普及率にはなっていない

情報源

読み物

技術系

ゲーム市場

基礎を学べる系

技術記事 / 実装系

HTML5 向けゲームエンジンに関する記事 / リンク

ベンチマーク / 比較

採用事例

DMM GAMES で最近リリースされたゲームとかを覗いてみると大体 Unity で作られている印象。

ブラウザゲームのプラットフォーム（日本国内向け）

HTML5 向けゲームエンジン / ライブラリ
  • ※ ゲームエンジンとうたっているものでも、単なる js のコードに過ぎないものも多いので、 Unity みたいな統合環境を前提としないように
  • よく使われているものは描画機能をベースにゲーム向け機能を揃えた js のフレームワーク、くらいの位置づけのものが多い印象

かつては Flash というやつもあったが、今は昔…

【調査メモ】

  • Cocos Creator は歴史が少々ややこしそう / Cocos2d-js とは分けて考える必要がある
    • 昔は Cocos Studio というのもあった気がするが消えた
    • Cocos には C++ 向け API と JS 向け API がある
      • JS 向けは、かつては cocos2d-js というリポジトリだったが 2016 年に cocos2d-x に統合されている
    • Cocos Creator で書く js は cocos2d-x の JS API とは別物っぽい
      • 実際には cocos2d-html5 というリポジトリから fork されたものの様子
      • （cocos2d 側にある API が Cocos Creator 側にはなかったりするらしい）
    • Cococs Creator のエディタはオープンソースではないのでビルドの中身がブラックボックスになりそう
  • Babylon は Microsoft 主導ということもあり割と安定感はありそうな印象
    • three.js とかと比べて API の破壊的変更が少なめ、みたいな意味での安定
    • ドキュメントやサンプルコードも整っている方だと思う
    • ブラウザ上でコードを編集してプレビューできる Playground があり、サンプルも豊富
    • 開発自体が TypeScript ベースで行われていて、ドキュメントにも型が載ってる
      • （Pixi.js や three.js にも ts 版はあると思うが、こちらは発症がもともと js である認識）

ファイルサイズ

2019-07 当時、軽く調べた結果：

エンジン js のサイズ
Babylon.js 2.4 MB
Phaser 921 KB
three.js 576 KB
Pixi.js 421 KB

こんなのもあるよ

Emscripten

Emscripten は C/C++ から LLVM のバイトコードを生成し、そこから JavaScript のコード （asm.js） を生成する技術。 現代では JS でなく WebAssembly にも出力ができる。

WebAssembly (wasm)

WebAssembly とはブラウザ上でバイナリを動作させることを目標にした低水準言語。ブラウザで動かすアセンブリといったところ。 JS 以外の言語で書かれた（それでいて高速な）プログラムを Web に持ってこれるようになる。

Go や Rust はすでに wasm 出力のオプションがあるらしい。 C 言語などから wasm にする場合は Emscripten を使う。

世の商用ブラウザゲームを実際に覗いてみる

ブラウザゲームはその性質上、読み込まれているアセットや js のコードが利用者に見えてしまう。 中身を覗くのは純粋なゲームファンや制作者の人にとっては気持ちの良いものではないだろうが、 ブラウザゲームの宿命ということでご容赦いただきたい。これも技術の発展のためなのだ。

とは言いつつ、Chrome の Developer Tools で軽くリソースや Request を眺めたり、 ゲーム内に明記されているコピーライトを参照する程度のライトなやり方で採用技術を見ていく。

色々見てみた中でいくつか大きめのタイトルをピックアップしてみる：

アイドルマスター シャイニーカラーズ （2018-04 〜）
（C）BANDAI NAMCO Entertainment Inc.

（C）BANDAI NAMCO Entertainment Inc.

  • アイマスという大きな IP のゲーム。アニメーションの品質が高い。モバイル版も出ている
  • アニメーションは Spine のデータを Pixi JS 経由で再生してるっぽい
  • 音声は m4a ファイルをダウンロードしてきている様子
  • 権利表記に emscripten がある
  • プラットフォームである enza 用の内製ライブラリを使ってそうな雰囲気
    • Pixi を利用しつつ、自前でもろもろ構築してそうだ
  • 参考：

マジカミ （2019-06〜）
  • マジカミ公式サイト【MAGICAMI】
  • ペルソナ感のある RPG。一般向けのものとアダルト版がある
  • 総製作費 12 億円と謳われている。「リッチな国内向けブラウザゲーム」としてはこれ以上ないベンチマークとなりそう
（C）Studio MGCM

（C）Studio MGCM

  • Unity でできてる。以上
    • 実行中にバイナリをストリーミングしていて、データの中に Unity というアスキーコードが見えたらたぶん Unity 製である
    • バージョンは 2018.4.1f1 かな？
  • アセットは CloudFront から都度たくさん落としている模様
    • お金がかかりそう…

このゲームじゃないけど DMM さんの技術資料：

FFデジタルカードゲーム （2019-07〜）
（C）2019 SQUARE ENIX CO., LTD. All Rights Reserved.

（C）2019 SQUARE ENIX CO., LTD. All Rights Reserved.

  • フレームワークに Babylon.js が使われている
    • Babylon は 3D 向けという印象だったので、2D の GUI が多いゲームに採用されていてオッ、と思った
  • GUI の部分はレイアウト情報が書かれた json を読み込んでノードを構築して Babylon で描画しているといった感じ
    • 恐らくだが、この json を生成するレイアウトツールを内製で作っているのだろう
    • カードリストとかのスクロールまわりの処理は自前実装だろうか？
      • gil.min.js というコードが内製ライブラリっぽい雰囲気 （名前もギルで FF っぽいし）
  • テクスチャのアトラス情報は TexturePacker の Unity 向けエクスポートデータを使用してそう
  • オーディオは awb という拡張子だった / CRIWARE のものかな
  • エフェクトなどに Spine を使用している
    • Spine は自分が調べた範囲では、Babylon 向けの公式サポートは無かった
    • spine-babylonjs-min.js というコードがあり、見た感じ PixiJS のランタイムをもとに自前で用意したものではないかと予想
  • Android 端末でも動かしてみた。少し重めだがちゃんと動いていた

所感
  • 結論は最初に述べた通り。Unity を使っていいなら心配事をかなり減らせるだろう
    • モバイルブラウザも対応してくださいと言われたら、
      神妙な顔で 「いばらの道になりますよ…」 と言おう
  • ブラウザゲームの「ブラウザですぐに動かせる手軽さ」の魅力はわかる
    • 一方で、規模が大きくなってくるとアセットのダウンロード量がどうしても多くなるのは気になるところ
    • モバイルだとユーザはデータ通信量を気にするので、プレイする側も抵抗がありそう
    • 運営する側としては、毎回ダウンロードさせなきゃいけないのでデータ通信の費用が多くかかるのがお金的につらい
      • アプリでやるように、Client にアセットを自由にキャッシュできるならいいのだが
  • 調べている中で世のブラウザゲームをさわってみて、やっぱり Request の数がすごいな… とは思った
    • タイトルからホーム画面に行くまでになんやかんやで 250 回くらい HTTP Request が飛ぶなど
    • 描画性能より、この辺の通信量や処理負荷がアプリと比べてネックになっちゃうのが悩ましい
    • まあ昨今なら、デスクトップで遊ぶ分にはそんなに気にならなそうではある

昔から HTML5 ゲームのビジネスは色んな人が挑戦するも、大成功には至っていない印象がある。 だがアイドルマスターなどの強い IP のゲームが出てきたり、 マジカミのようにリッチなやつが動いているのを目にすると、 まだまだ可能性に満ちているという期待もある。 未来を歩もう。


Tatsuya Koyama

 /