【CEDEC 2018 フォローアップ】モバイルブラウザ上で実現させた『アイドルマスター シャイニーカラーズ』の作り方

enza 事業本部/ゲーム SDK 開発部所属の Smith です。
ゲームSDK開発部は、 enza で展開するゲーム開発に用いる基盤ライブラリを開発し、また関連プロジェクトの技術課題抽出と解決を行う組織です。

本稿は CEDEC 2018 にてお話させて頂いたセッション「モバイルブラウザ上で実現させた『アイドルマスター シャイニーカラーズ』の作り方」についての補足記事です。
本稿を通して、当日の会場では説明しきれなかった技術的トピックの補足情報に触れると共に、現在のモバイル HTML5 ゲーム開発に関わる外的環境の現況について理解を深め、よりモバイルブラウザ向けHTML5ゲーム開発の実現性を感じて頂ければ幸いです。

なお、本稿は CEDEC セッション内容のフォローアップ記事であるため、読者は記事内容の前提知識を有するものとして、下記のいずれかに該当することを想定しています。

• 発表資料を読了されている
• セッション動画を視聴完了されている
• CEDEC 会場にてセッションを聴講頂いている
• 前提知識は無いけれど、とても興味があっていい感じにキャッチアップできる

Index

• モバイルブラウザ上で実現させた『アイドルマスター シャイニーカラーズ』の作り方
• 不採用となった既成エンジンについて
• pixi-particles に見られるブラウザ上の作業環境
• 時間の都合で割愛した項目
• 質疑応答
• まとめ
• 最後に

モバイルブラウザ上で実現させた『アイドルマスター シャイニーカラーズ』の作り方

セッション動画

発表資料

CEDEC のセッション資料をアーカイヴしている CEDiL というサイトより頒布しております。
メールアドレスをご登録頂くことで、ログインして資料をダウンロードすることが出来ます。
https://cedil.cesa.or.jp/cedil_sessions/view/1896

ゲームエンジン選定についての補足

この頁で記載している不採用となった既成エンジンについての補足です。
いずれも不採用というネガティヴな結果に至っていたためセッション中では名称を伏せておりましたが、未来へのポテンシャルが多分にあるゲームエンジンのみを取り扱っているため、本稿では名称を明記させて頂きます。

火の玉みたいなロゴのやつ

CocosCreator – http://www.cocos2d-x.org/creator を指します。
GUI によるゲーム開発環境が提供されているため、開発効率の面での期待効果は非常に高いです。
PIXI.js と比較してパフォーマンスは劣るものの、FPS は 30 で良いという判断さえできれば、モバイル向け HTML5 ゲーム開発においても採用は十分に視野に入れられるものと思います。

宇宙人みたいなロゴのやつ

Phaser – https://phaser.io/ を指します。
Phaser の描画エンジンは検討当時の v2 では PIXI.js を分離させ、カスタマイズしたものを用いていましたが、v3系では 分離せず結合した実装に換装されている*1ため、パフォーマンスが最適化されている事が期待されます。
また、このゲームエンジンでもエディタ*2が提供されているため、開発効率の面でも期待効果が見込まれると思われます。

下のブースでTシャツ配ってるやつ

Unity – https://unity3d.com を指します。
Unity 検証当時の iOS 10.3.3 / iPhone 7 にて、急激に大きいサイズのメモリ確保を行うとクラッシュするような傾向が観測されていました。
これは、Unity のメモリ確保方法の特徴として、アプリ起動時に一定量のメモリ領域をマネージド領域として確保する仕様によるものの名残と思われ、当時は回避が困難な問題と判断しました。
現在もメモリ確保の振る舞い自体に変化はありませんが、最近ではTiny Unity と称した極小サイズのエンジン*も提供されていたりと可能性が感じられます。

資料に挙げたもの以外にも、2D を扱えるゲームエンジンは存在しています。

• Egret – https://www.egret.com/
• PlayCanvas – https://playcanvas.com/

本稿公開時点において、モバイル向け HTML5 ゲームにおいて『シャニマス』水準のモバイルHTML5ゲーム開発実績を有するゲームエンジンは enza GameSDK のみという認識ではありますが、これをデファクトの開発環境とするためにはまだまだ開発効率面での課題が多く、今後は特に強化すべき要素であると捉えています。

余談: Unity と iOS Safari メモリ事情

Unity の WebGL 書き出しは、元々はC/C++ ネイティヴのプラットフォーム向けに作られたビルドパイプラインを再利用して WebGL 向けにアプリケーションを吐き出せるようにしたものです。

Unity は IL2CPP*1 という技術を導入しています。
C# のネイティヴコードへのコンパイル時には IL が生成されますが、IL2CPP はその IL から C++ コードを生成する機能です。
これを利用して、iOS や Android ネイティヴ向けバイナリのコンパイルを可能にしています。
IL2CPP 登場以前のビルド仕様については割愛します。

また、Unity の WebGL 書き出しでは emscripten を利用しています*2。
emscripten は C/C++ コードから Javascript コードを生成する技術です。
emscripten が出力する Javascript ファイルは asm.js 形式となります*3 が、asm.js も擬似的なヒープ領域を起動時に確保する挙動をするため、iOS Safari で用いることにはリスクがあると判断していました。

asm.js ではなく WebAssembly での書き出しもオプションとして提供されていますが、WebAssembly 書き出しの experimental ラベルが外れたのは 2018.1 以降*4です。

Point

1. CocosCreator はエディタを提供しており、30 FPS 前提ならば採用も視野に入る
2. Phaser で採用されていた描画エンジンは、v3系では PIXI.js から独自エンジンに換装されている
3. Unity は、検証当時はメモリ確保の挙動が原因で iOS Safari でクラッシュする傾向が観測されていた

pixi-particles に見られるブラウザ上の作業環境

この頁で記載している pixi-particles の提供形態に着目した補足です。

pixi-particles によるエフェクトデータ制作には pixi-particles-editor*1 を利用しており、こちらはブラウザ上で提供されている開発環境となっています。
このように、最近ではブラウザ上で作業ができるタイプのものが散見され、 PlayCanvas*2 や babylon.js*3 などもブラウザ上での作業環境を提供しています。

一般に、利用者にとってブラウザ上で作業することの利点は下記が考えられます。

• URL を知っていればワークスペースが展開できるアクセスの利便性
• 物理ファイルのやり取りなしに作業が開始できる共有の容易性
• 作業環境が実行環境であるデバッガビリティ

反面、懸念事項および検討項目も存在します。

• チーム開発において直面する同時編集の競合解決手法
• オフラインでの作業が許容できない、あるいは限界がある
• 外部プロジェクトとのアセット共有手法
• 作業データをサーバに保有する場合、シームレスなデータ保存・同期にかかるサービス提供側にとってのコスト、及び高水準のサーバ可用性の維持

ツールを提供する側の目線としてはツールが提供できるプラットフォームが増えたのは喜ばしいことですが、その反面でブラウザで展開することが最適かどうかについてはまだ慎重に検討すべき段階であり、ブラウザでの提供について相性が良いもの、悪いものがあるという所感です。

Point

1. pixi-particles はブラウザ上で制作できるエディタを提供している
2. ブラウザで提供されているツール類は少なくない
3. ブラウザでツールを提供すること自体にはメリットもデメリットも混在する

時間の都合で割愛した項目

この頁で触れた、時間の都合で割愛した項目についての補足です。

CORS よくわからん

結論から申し上げますと、 MDN の CORS に関するドキュメント*1が全てでした。
ここで中途半端に補足記事を書くよりも的確な情報ソースです。
長いですが頑張って読んで理解しましょう、やる気と根性です。

「よくわからん」となった言い訳をさせていただくと、iOS Safari には ITP*2 という利用者を守るための機構があり、enza プラットフォームとゲームを結合する上で多発した問題の原因が、CORS と ITP のいずれに起因するのかを分類することが困難だったため、「よくわからん」となった次第です。

最近では iOS 12 の正式アップデートが配布されておりますが、Safari の特性であるセキュリティの堅牢性から、 CORS に関しての挙動が突然変化するかもしれない、というゲーム開発者という立場からの懸念があります。
同様に WebKit の ITP もアップデートされ続けており、こちらの仕様差分も注視すべき対象です。

iOS 12 について、GameSDK チームで enza 及び enza で提供するゲーム全般の挙動を確認したところ、enza ログインや一連のゲームプレイに問題は見受けられませんでしたが、各ゲームにおいての精緻な動作検証は実施中となっております。

Spine 重い

セッション当日の質疑応答でも多少触れた内容ですが、本稿にて再掲致します。
Spine そのものについての補足は割愛します。

PIXI.js は公式の github ネームスペース配下にて Spine の PIXI.js ランタイムである pixi-spine*1 を提供しており、 Spine データを PIXI.js 上で再生させるためにはこのモジュールの利用が適切です。
Spine が重くなる現象は、下記の二つの要因の組み合わせによって発生したものでした。

• PIXI.js のメッシュ描画には、パフォーマンス向上を意図した処理は入っていない
• 『シャニマス』の Spine データは多分にメッシュを利用している

PIXI.js の描画は、主にスプライトやテキストなどの描画される対象と、それらをどのように描画するかのレンダラで構成されます。
例えばスプライトにも専用のレンダラが用意されていますが、こちらは予めパフォーマンスが考慮されており、設定した数だけ*2 バッチ処理が走るようになっています*3。

PIXI.js が提供するレンダラの内、メッシュを描画する MeshRenderer というものも提供されていますが、こちらは特にバッチ処理や頂点結合などを行わず純粋に1要素を描画する*4 ため、 Spine のスロットにメッシュを適用している場合はその数だけ 1 ドローコールがかかってしまっていました。

『シャニマス』のアイドル 1人につき、60~70 のスロットがメッシュとして設定されておりましたが、ゲーム中のオーディションでもリンクアピールというスキル使用時には最大で ５人のアイドル達が表示されるため、単純計算で 300~350 ドローコールが必要となります。
『シャニマス』チームではこれを表現力とパフォーマンスのトレードオフと捉え、表現力を優先してメッシュの利用を継続する判断をしています。
その代わり、プロデュース時のシナリオなどでは最大で表示されるアイドルを 3人に抑えるなどの制作上のルールを設けて、通常プレイがストレスなく行えるようにしています。

Point

1. CORS は MDN のドキュメントで完全に理解できる
2. iOS 12 での enza 初動確認は概ね問題なし
3. PIXI.js でのメッシュ多用はドローコール数が課題

質疑応答

講演当日の会場にて頂戴した質問事項の補足です。

Dev Tool 以外のデバッグツールの利用状況

『シャニマス』に限らず、 Chrome 拡張で普段から用いているツールをいくつかご紹介差し上げます。

PixiJS devtools

https://chrome.google.com/webstore/detail/pixijs-devtools/aamddddknhcagpehecnhphigffljadon
PIXI.js をバックエンドとしているアプリケーションにおいて、PIXI.js のオブジェクトツリーおよび各オブジェクトの一部プロパティ情報を参照することができるデバッグツールです。
なお『シャニマス』においては、セキュリティリスク軽減の観点からこちらのツールは無効になるようにしています。

Spector.js

https://chrome.google.com/webstore/detail/spectorjs/denbgaamihkadbghdceggmchnflmhpmk
WebGL レンダリングに関わるデバッグツールです。
描画パイプラインにおいて叩いた WebGL コマンドのログや、各コマンドを叩いたタイミングでのテクスチャバッファの状態をデバッグ表示してくれるツールでかなり出来が良いです。
また、ドローコールなどの統計情報も取得してくれるため、描画周りのチューニングにかなり活躍してくれています。

ブラウザ等の動作環境別処理の現状

前提として enza でサポートする動作環境は下記の二択となり、考慮しなければならないのは OS別、ブラウザ別、そしてブラウザバージョン別の差分吸収です。

• Android / Chrome
• iOS / Safari

これまでの開発実績上、OS に関連した個別処理はほとんど見られず、ブラウザもしくはブラウザバージョンによる個別処理がほとんどでした。
傾向としてはメディアを取り扱う API においての処理分けが多く、サウンドや動画再生などがそれに該当します。
特にサウンド周りはハードウェアに近い機能であり、またブラウザベンダーのセキュリティポリシーに仕様が左右されやすい領域ですので、ブラウザ別、バージョン別の処理が多く見られます。
また、Safari には indexeddb の特定 API にバグがあったりするので、こちらもバグを踏まないような実装を行っています。
手前味噌ですが、Safari の indexeddb バグについては検証用リポジトリ – https://github.com/dolow/safari-idb-memory-leak-sample を公開しています。

余談ですが、 iOS でダウンロードできる Chrome は実質 Safari です。
いかなるWebブラウジング処理も WebKit で行うように指示するレビューガイドラインが存在します*。

HTML5 ゲーム開発人員の確保状況

要件として、HTML5 (Javascript) とゲームの開発経験の両方を提示していますが、それらの全てを満たす人材は稀有であり、また実際に応募頂いたりご紹介頂く機会はほぼ無いと言っても過言ではありません。
そのため外部からの採用に関してはゲーム開発経験を有することを前提条件とし、その上でキャッチアップ能力及び HTML5 へのモチベーションを主に評価させていただいております。
内部での人材流動については、志望度がもともと高い、あるいはキャッチアップ能力の高い人材を充てておりますが、ネイティヴゲーム開発プロジェクトなどからの流動性が決して高くないことが目下の課題です。
ドリコム内部の HTML5 技術領域に対する投資をもって、この問題を解決するための育成・教育を推進していくものとしています。

通信量削減施策について

『シャニマス』ではなく GameSDK 開発計画の範疇の話になりますが、具体的な施策としては Cache API*1 やダイナミックインポート*2 など、モダンなブラウザ API を活用することによっての通信量削減やコード量自体の削減を計画、検討しております。
GameSDK コードの削減においては、必ずしも使わないモジュールのプラグイン化を行うことによって本当に必要なコードのみダウンロードさせるなどを実現させようとしています。

After Effect 関連と見られるツールについて

会場で明確にお答えできなかった質問事項ですが、こちらは開発協力会社である株式会社ノックノート様の goccy さんが Qiita に記事を投稿されておりますので、こちらをご参照下さい。

AfterEffectsアニメーションをWebGLで動かす
https://qiita.com/goccy/items/1b60ac0b5f67b764c1cb

セキュリティ対応方針について

ブラウザではクライアント側のソースコードやサーバ通信内容がほぼ全て見えてしまったりすることから、セキュリティ強度に関してはネイティヴより低いという印象もあるかと思います。
しかし、これはネイティヴゲームにおいてチーターが一手間かけた後の状態であるだけですので、本質的に有効な対策はネイティヴゲームとほぼ変わりません。

他のユーザ様に悪影響を与えうる、もしくは運営が被害を被る可能性がある事項については優先的に対応しております。
そうではなく、チート自体がその攻撃者のみにしか影響を与えないものであれば、(決して看過は出来ませんが)対応優先度は低いと考えています。

ただし、クリックジャッキング* などブラウザならではの攻撃手法があることは事実ですので、平時と異なるドメイン下で提供されているゲーム画面でのプレイは行わないなどのユーザ様への注意喚起は必要になるものと思われます。

下限動作環境の更新について

本稿公開時点で Android / Chrome においては バージョン 39 という歴史的遺物を下限環境としておりますが、つい最近、 GameSDK チームの強い意志により enza での下限環境に関する刷新の方針が決定致しました。
毎年4月に1年半前にリリースされたバージョンを下限とすることで概ね合意頂いております。
enza としてはビジネス要件としてブラウザバージョンシェア率が主な問題として取り扱われているため、目安として enza 利用ユーザ様の 90% 以上において動作要件を満たす状況であれば問題ないとのことでした。

技術的には、これが実現すると WebAssembly や 完全ES2015化、あるいは PWA 機能を活用した通信量削減に関連する恩恵が近い将来に提供出来るようになります。

Spine のパフォーマンスについて

時間の都合で割愛した項目 に記載の通りですので割愛させて頂きます。

開発環境及び職掌を跨いだワークフローの課題とその解決手法について

予め開発環境が提供されている CocosCreator や Babylon.js と比較して、PIXI.js や GameSDK では開発効率に課題があるという認識です。
また GameSDK の近況で恐縮ですが、GameSDK では特にエンジニア~デザイナ間のワークフローに対して課題が多く、またそれらを解決することによる効果は大きいと判断しており、 UI 制作を支援するツールの開発から着手しています。
とは言っても、ゼロからエディタのような GUI を開発、提供することには年単位での時間とコストが掛かるため、まずは CocosCreator 等の既成の GUI で制作した UI を PIXI.js ランタイムにエクスポート/インポートできるようにする機能の開発に着手しております。
これは既に『シャニマス』以外の enza タイトルに試験導入中で、今後も拡充予定です。
これらは npm 公開されておりますので、ご興味のある方は是非、覗いて見て下さい。

scene-graph-schema

https://github.com/drecom/scene-graph-schema
シーン情報の中間表現フォーマット。
不特定多数の種類の静的シーン定義ファイルをこのフォーマットに変換することで、同じく不特定多数のランタイムに復元出来るようにするための定義です。
仕様のみの定義で実装はありません。

scene-graph-mediator-cli

https://github.com/drecom/scene-graph-mediator-cli
静的シーン情報を scene-graph-schema へ変換するモジュール。
CocosCreator であれば .fire や .meta ファイルに納められているシーンに関わる情報を scene-graph-schema 形式に吐き出すモジュールです。

scene-graph-mediator-rt

https://github.com/drecom/scene-graph-mediator-rt
scene-graph-schema 形式のファイルを任意ランタイム上で復元するためのモジュール。

同様に、GameSDK も OSS にしていきたいという強い意志がありますが、こちらには時間がかかりそうです。

まとめ

本稿ではCEDEC 2018 セッション補足記事として以下のトピックについて触れました。

• ゲームエンジン選定時の補足と各ゲームエンジンの現在の状況
• pixi-particles-editor に見られるブラウザ上でのツール提供についての考察
• iOS 12 における CORS と ITP の enza 動作状況
• PIXI.js メッシュのパフォーマンス的なリスク
• 質疑応答内容の明文化と補足

最後に

既に『シャニマス』がリリースされ、これまで運用されていることから、技術的にはモバイルブラウザ向けにネイティヴ水準のゲームを開発して提供する、という事自体が可能であることを実証しています。
また、enza プロジェクトローンチ当初と比較すると外的環境も進化しており、HTML5 ゲーム x モバイルブラウザの開発難度が徐々に下がりつつあるのではという所感です。

しかしながら課題が全く無いわけではなく、ユーザ様が「スマートフォンで遊ぶゲームを探す」という行動モデルの内に、ブラウザから任意のプラットフォームを開くというアクションがまだ確立しておりません。
また、ブラウザを開けば何か面白いゲームが集まっているという状態にする、つまり enza を AppStore や Google Play の代替とするには、更にコンテンツの拡充が必要であると思っています。
enza では引き続きパートナー様を拡大していくと共に、モバイルブラウザ向けプラットフォームとしての価値を高めていくため挑戦を続けて行きます。

末筆ながら、CEDEC 受講者へのメッセージとして掲載させて頂いた一文を結びに代えさせて頂きます。

Web や HTML5 は、ゲーム開発者にとってはまだ可能性と挑戦に満ちた領域です。
この荒波のような領域を突き進むライバルが増え、市場がより一層盛り上がることを期待しています。