あるゲームアプリケーションの 構成とアップデートサイクル

飯塚健太郎 DroidKaigi, 2015/04/25

今回お話しすること

• あるゲームアプリの構成

• どのようなゲームを，いかにして作っているか

• アップデートサイクル

• アップデートをいかにして回していくか

• 雑多な Tips 集

あるゲームアプリ開発者のデスク （自己紹介）

• 飯塚健太郎．KLab Inc

Android 4.4

Android 2.3

Android 5.1

Jenkins 用 Mac mini

開発用 MacBook

HHKB

いろいろ用 Windows

24インチモニタ

5.1A USB電源ハブ

HHKB Lite 2

どんなゲームを作っているの？

• Android 2.3 以降対応の音ゲーム

• 自社製ゲームエンジン

• 自社製サーバサイドフレームワーク

• 既に2年くらい運用中

• 2～3ヶ月に1度アップデートを実施

今回は，こんなゲームの運用経験を元にノウハウを共有します

あるゲームアプリの構成

- あるパイプラインエンジニア曰く

“ゲームはソースコードのみにて在るに非ず”

ソース コード

マスターデータ

音声データ

画像 データ

リソースの海

素敵ゲームアプリ

謎の力？

ゲームエンジン

ムービー

いかにして多種多様なリソースからゲームを生成するのか？

API

• 様々なリソースから謎の力で素敵なゲームアプリができるわけではない

• 音声ファイル，画像ファイル，ソースコード，マスターデータ等のリソースをまとめあげてアプリとして具現化するビルドシステムが存在する

• 私達は，主に Jenkins と Github を用いたシステムを構築している（次ページ）

ゲームはソースコードのみにて在るに非ず

様々なリソースを束ねる Jenkins を使ったビルドシステム

APIサーバゲームアプリ(apk)

Jenkins

fetch

ゲーム エンジン

NDK, Gradle

フロントエンド UI

サーバサイド PHP

Jenkins

fetch

追加DL用 音声，画像等

API通信Amazon S3

Jenkins

fetch

deploy upload

マスターデータ

音声，画像等

fetchfetch

DL

• 私達はこのビルドシステムを，「パイプライン」と呼んでいる．そして，パイプラインの整備を専門にする「パイプラインエンジニア」のチームが存在する

• マスターデータのバリデーションやアセットの整合性チェックなども，Jenkins の中で動かしている

• Github や Jenkins マシンが死ぬとプロジェクトが止まるリスクがあったりする

様々なリソースを束ねる Jenkins を使ったビルドシステム

参考書籍

• ゲーム・映像制作パイプライン構築マニュアル

• 2014年

• 税込み約6500円

“ゲームエンジン在らざればゲーム在らず”

- あるパイプラインエンジニア曰く

• 昨今のゲーム開発はゲームエンジンの上でゲームを作ることが非常に多い，と思う

• 私達は Playground というゲームエンジンを使っている．これはOSS でも公開されている

• https://github.com/KLab/PlaygroundOSS/

• 社内にゲームエンジンチームがあって，Playground ゲームエンジンの開発を専門に行っている

• ゲームの UI は，ゲームエンジンに付属する IDE で作れるようになっている

どんなゲームエンジンを使っているのか

エンジン自作の嬉しさと悲しさ

• 音ゲーを作っているので，オーディオ周りなどでハードウェア寄りの細かい制御をできるのはゲームエンジンを作っている強みになっている

• ググっても情報がない．しかし開発者に直に質問可能

• 例えば，新しいバージョンの OS(Lollipop) への対応がスムーズにできたりとか，比較的小回りが効く

ゲームフロントエンド（UI, ゲームロジック）

Open GLOS機能 (ファイルIO，スレッド…)

タスクシステム

アセット管理

知財暗号化

OSごとのポーティング層 (Java, Obj-C) 描画ラッパー

データベース その他

ゲームエンジン (Playground)

(Lua, XML)

(C, C++ 等)

ゲームエンジン Playground の おおざっぱな構成

アップデートサイクル

たった 50MB ぽっち！

- あるパイプラインエンジニア曰く

たった 50MB ぽっち！

• Google Play から Wi-Fi を使わない環境でダウンロードできる apk の最大サイズ

• 多いように感じるかもしれないけど，ゲーム開発をしていると全然足りなくなることもしばしばしばしば

• はみ出したリソースは，追加ダウンロードの仕組みを作って使って対応する(expansion packを使っているゲームも最近は多いですが，ここでは使っていません)

追加ダウンロードのしくみ

全アセット空間 (数百MB～数GB)

アセットリスト (API サーバ)

Amazon S3アセット アップロード

アセットリスト 作成画像

ムービー

音声

UI 情報

その他apk (50MB)

ダウンロード リスト取得

アセット ダウンロード

リソース 抽出

• API サーバにアセットのリストを作っておいて，アセット自体は Amazon S3 からダウンロードする仕組みになっている

追加ダウンロードのしくみ を使ってアップデート

アセットリスト (API サーバ)

Amazon S3差分アセット アップロード

アセット差分 リスト作成

apk ver 1.0 -> 1.1

差分 リスト取得

差分アセット ダウンロード

リソース 抽出

• 追加DLの仕組みを応用してアセットのアップデートもできる

ver 1.0 アセット集合

ver 1.1 アセット集合

差分アセット集合

“アップデートはゲームアプリの呼吸なり”

- あるパイプラインエンジニア曰く

アップデートはゲームアプリの呼吸だ

• ゲームを面白く新鮮に保つためには，アップデートが必要

• 新機能追加，新キャラ追加，UI改修，性能チューニング

• スムーズにアップデートを回していくためにどうしたら良いのだろうか？ということを話す

• 前置き：アップデートには 2 種類ある

2 種類のアップデート

アップデート方法 期間 更新内容 関連エンジニア

Google Play 数ヶ月単位

（コードの改修） ・ゲームロジック改修 ・ゲームエンジン改修

・フロントエンド ・ゲームエンジン ・サーバサイド

追加 ダウンロード 数週間単位

（リソースの追加） ・アイテム追加

・キャラクター追加

・サーバサイド ・運用エンジニア

•今回話すのは主に Google Play からのアップデートのほう

• アップデートには想像されるように様々なフェーズが存在する

• 仕様策定，実装，レビュー，動作テスト，リリース

• それらをどうつなぎあわせてリリースまでもっていくかは，実は自明ではない

• 次ページで仕様策定からリリースまでの一連の流れの例をあげる

アップデートサイクル

仕様策定

アップデートテスト

実装

コードレビュー

テスト（開発者）

リリース

テストエンジニアレビューパス

テストパス

コメント・修正

フィードバック

テストパス

バグ報告

ユニットテスト, 手元テスト

リリースリハーサル

リハーサル 成功

ユーザサポート

クラッシュ レポート

リリース後

こんなものを作りたい という気持ち

明文化

アップデートサイクルの一連の流れの例

• デイリーで apk を作成してテストエンジニアへ

• テストサイクルがうまく回るかどうかは，アップデートの成否に関わる問題

• テストを上手くまわすための技術開発に工数を使うことも積極的に検討

• UIパーツやゲームロジックといったゲームフロントエンドは差し替えずに，ゲームエンジンだけを入れ替えてテストできるようにしてみたり…

• 通信速度あげるために有線 LAN アダプタを挿してみたり…

テストの比重は重い

デバッグのための2種類のapk

アセット apk サイズ テスト内容

FULL版 全部 apk 内

数百MB～数GB ・新機能 ・バグフィックス

DL版最小限 +

追加DL50MB

・追加DL ・Google Play α版 ・Google Play β版

•新機能テストのとき，いちいち数百MBの追加ダウンロードはやってられないため，すべてのアセットを含んだ”FULL版”と呼ばれる巨大な apk が使われる

“実装者下暗し”

- あるテストエンジニア曰く

• View 部分の動作テストは自動化が非常に難しい

• テストエンジニアによる動作テストは必須

• 実装者自身は動作テストを都合の良いように最適化してしまう（ことがある）

• テストエンジニアは，実装者が見落としてしまいそうな遷移の不具合を，仕様と優れたメソッド（企業秘密）で発見してくれる

テストエンジニアによるテストの価値

プロの手によって発見されたバグ再現手順の例

電源ボタンでゲームをバックグラウンドにし，即座にフォアグラウンドに戻すと発生するバグ

このようなバグは開発者の動作テストでは見つかる確率低

• リリース後はクラッシュレポートでユーザの手元で起こったクラッシュを監視

• Developer Console のクラッシュレポートはあまり参考にならない

• クラッシュレポートツール選び

• 遅延なくでクラッシュを監視できるか？

• NDK 部分と Java 部分で起こったクラッシュを分けて分析できるか

クラッシュレポートコレクターになろう

まとめ

• あるゲームアプリの構成

• Jenkins と Github を多用したパイプラインを構築している

• Playground というゲームエンジンを使用している

• アップデートサイクル

• Google Play, 追加DL の2種類のアップデートがある

• テストの比重は比較的重い．テストをいろいろ工夫する

• テストエンジニアのテストは必須

• 外部のクラッシュレポートツールを使ってクラッシュを監視

PR• CodeLunch.fm というポッドキャストに出たりしてます

• http://codelunch.fm/