2015年4月19日（日）

Unity技術者は必読！ 3,200万ダウンロードの『白猫プロジェクト』を支える“最適化”

　ゲーマーなら誰しも「なんかロード時間が長いなぁー」や「表示が遅くなるんだけど……」といった、ゲームの挙動がおかしくなる経験をしたことがあるはず。

　そうした不快感を減らすために、製作陣は日夜、血の涙を流すほど（おおげさ？）の努力を重ねているわけだが、その苦労はなかなか一般人のわれわれに見えてこない。

　そこでぜひ読んで欲しいのが本記事だ。ソフト開発エンジンUnity（ユニティ）の開発者向けイベント“Unite 2015 Tokyo”にて、スマホ向けRPG『白猫プロジェクト』で実施したパフォーマンス調整について、コロプラの技術者が具体例を交えて語った。

　その要点をまとめたレポート記事をお届けしていく。


▲講演タイトルは“白猫プロジェクトの裏側！～パフォーマンスチューニングとリアルタイム通信のすべて～”。


▲最初に登壇したのは、コロプラのKuma the Bear開発本部・技術開発チームマネージャー、池田洋一氏

　白猫プロジェクトには、最大4人のマルチプレイなど、スマートフォンの限界に挑戦しようという目標があったという。プロトタイプの時点では、開発メンバーはコロプラの他のプロジェクトと同様で2、3人。最終的に最大18名が9、10ヵ月ほどかけて制作することになった。

　興味深かったのは、β版を全社員に配布して意見を集めるというところ。さらに小学校高学年の子どもにもプレイしてもらい、わからなかったとフィードバックをもらったところはチュートリアルができてないとみなして作り直す“子どもレビュー”も実施しているという。


▲α版、β版と徐々に開発人数が増えていっている。

　そうした過程で少しでもプレイヤーが快適に遊べるように、キャッシュの見直し、フラグメントシェーダーの見直し、起動時間の高速化、ロード時間の短縮といった点でソフトを最適化していったとという。

　講演で多くの時間を割いていたのがキャッシュだ。キャッシュとは、よく使うデータを効率よく読み出せるように一時的に保存しておく仕組みのこと。

　例えば、バトルシーンにて攻撃がヒットしたらダメージ表記が現れるが、このキャッシュが最適化されていなかったため表記が重なると処理落ちが発生していたという。


▲ほとんどのオブジェクトがキャッシュされていなかったので、“CachedObjectManager”を作成してオブジェクトをキャッシュするようにした。


▲オーディオファイルは、その都度読み出していたので、こちらもキャッシュを使うことに。ただ、流れる可能性が低かったり、一度しか使わないものもまとめてキャッシュするはムダなので、鳴った一度目のタイミングで保存する方式にした。


▲一方で、エフェクトはそもそもキャッシュすることを想定してつくていなかったので、今回は断念した。現状、エフェクトが大量に出てしまうと処理が重くなるという。

　GPUの負荷を軽くする最適化では、マップ画面で処理落ちしていた事例が語られた。この重たい症状は、実はリリースしたあとも続いていたとのこと。


▲普通のマップ画面で、GPUに負荷をかけそうな3D表現は見当たらなそうだが……。


▲どうも調べていくと、海のキラキラしている表現が処理落ちの原因だった。海は描画面積が広く、一番最初に描かれてしまうというため、これがボトルネックになっていたという。


▲波の表現はフラグメントシェーダーで計算していたが、特にフラグメントシェーダーを使う理由がなかったので、バーテックスシェーダーに変更。画像中のコードは、実際のもののビフォア/アフターだという。


▲さらに条件を指定して、プログラムから必要のないカラー計算を実施してるシェーダーを一括変換した。Unityの素材ダウンロードサービスである“Asset Store”などで買ってきたシェーダーの中には、PCでの動作を想定していてモバイルにあっていないものもあるため、こうしたチューニングが重要になってくる。

▲さらに条件を指定して、プログラムから必要のないカラー計算を実施してるシェーダーを一括変換した。Unityの素材ダウンロードサービスである“Asset Store”などで買ってきたシェーダーの中には、PCでの動作を想定していてモバイルにあっていないものもあるため、こうしたチューニングが重要になってくる。

　起動時間の高速化では、ある程度プレイするとなぜかiOS版だけ起動が遅くなるという話が出てきた。具体的にはAndroidが25秒に対して、iOSは2倍以上の1分！その原因は、必要に応じてサーバーからデータを落としてくる仕組みの“アセットバンドル”にあったという。

　ちなみにスマートフォン向けアプリストアのうち、Androidでは50MB以下でないとアプリを配信できないし、iOSでは100MB以下に抑えないと3G/LTE回線で入手不可能だ。そうした制限を超えてリッチな表現を実現するために、初回起動時や追加時にネットからデータを落としてくれるアセットバンドルが利用されている。


▲調査時点で白猫プロジェクトのアセットバンドルは、約3万種類存在している。ある程度プレイして、使うアセットバンドルが増えていくにしたがって、キャッシング（“Caching.ready”項目）が準備状態になるまでが非常に遅かった。


▲そもそもタイトルもアセットバンドルを使うので、表示されるのに起動時間がかってしまう。そこで独自のキャッシュシステムをつくることで、起動時間を8秒に縮めることに成功した。


▲どういう仕組みかというと、パスとバージョン番号で各アセットバンドルを管理する“AssetVersionList”を導入した。写真ではソウルボードのアセットバンドルを表示していて、ファイル名の右側に1、2と書かれているのがバージョン名になる。


▲元データからビルドする際、AssetVersionListにパスを探しに行って、そのバージョンも更新して、2つをセットにネットに投稿する。プレイヤー側では“起動データ構築中”と出る時にこのAssetVersionListをダウンロードしている。

　同じiOSのアセットバンドルで、ファイル読み込み数の制限にひっかかったという話も興味深かった。白猫プロジェクトは、カットシーンで大量のアセットバンドルをダウンロードしているとのこと。例えば、オープニングから紙芝居っぽい一枚絵の上にテキストが流れていくが、そこでも裏で大量のアセットバンドルを落としている。

　しかし、iOSは同時に開けるファイルの上限が256個なので、アセットバンドルをどんどん落として読み込ませていくと、いつのまにか限界を突破していることがあった。そこでカットシーンのロードは、1ファイルずつ実施して、随時閉じていくことにしたという。


▲こうしたカットシーンの裏で、大量にアセットバンドルがロードされている。


▲実物に近いコードでは、Listに“string”で配列を入れて、アセットバンドルが全部ダウンロードし終えたら、Dictionaryにパスとアセットバンドルを詰め込む。ちょっと設定を変えてこの数が256個を越えると、進行不能になってしまう。しかもiPhoneでしか起こらないため、なかなか原因が見つけにくかったそうだ。

▲実物に近いコードでは、Listに“string”で配列を入れて、アセットバンドルが全部ダウンロードし終えたら、Dictionaryにパスとアセットバンドルを詰め込む。ちょっと設定を変えてこの数が256個を越えると、進行不能になってしまう。しかもiPhoneでしか起こらないため、なかなか原因が見つけにくかったそうだ。


▲体感時間を減らすために、バックグラウンドでのダウンロードを増やしていたが、1ファイルずつクローズし、“OnComplete”で何も行わないようにした。

　後半はサーバー側の工夫だ。白猫プロジェクトの特徴のひとつであるマルチプレイで遊んでいる際、複数台のスマートフォンのデータをどうやって同期しているのかを解説していた。


▲登壇したのは、Kuma the Bear開発本部のサーバーエンジニアである廣本洋一氏。


▲白猫プロジェクトは、基本的にAmazon WebServices（AWS）でサーバーを構築している。プレイヤーのスマホから要求されたデータは、ロードバランサー（負荷分散装置）を通じて、ウェブサーバーに投げられ、キャッシュサーバーやデータベースサーバーから引き出される。さらにマルチプレイでは、ウェブソケットサーバーを利用する。

▲白猫プロジェクトは、基本的にAmazon WebServices（AWS）でサーバーを構築している。プレイヤーのスマホから要求されたデータは、ロードバランサー（負荷分散装置）を通じて、ウェブサーバーに投げられ、キャッシュサーバーやデータベースサーバーから引き出される。さらにマルチプレイでは、ウェブソケットサーバーを利用する。


▲マルチプレイのサンプル画面。左がルームを作成したユーザー、右側がそのルームに参加したユーザー。


▲ホストユーザーは、マルチプレイで必要になるマスターデータを持っている。一方でゲストユーザーは、自キャラの位置や動き、アクション結果を除いて、基本的にホストからデータをもらっている。またザコ敵は各ユーザーの端末で自由に動いていて、ダメージや生死を同期しているそうだ。


▲マルチプレイでデータが他のユーザーに届かないと進行不能になるので、通信保証の仕組みを入れて、データが確実に届くようにしたとのこと。