Advertisement

More Related Content

Slideshows for you(20)

Viewers also liked(20)

Advertisement

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

Recently uploaded(20)

Advertisement

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

  1. あるゲームアプリケーションの 構成とアップデートサイクル 飯塚健太郎 DroidKaigi, 2015/04/25
  2. 今回お話しすること • あるゲームアプリの構成 • どのようなゲームを,いかにして作っているか • アップデートサイクル • アップデートをいかにして回していくか • 雑多な Tips 集
  3. あるゲームアプリ開発者のデスク (自己紹介) • 飯塚健太郎.KLab Inc Android 4.4 Android 2.3 Android 5.1 Jenkins 用 Mac mini 開発用 MacBook HHKB いろいろ用 Windows 24インチモニタ 5.1A USB電源ハブ HHKB Lite 2
  4. どんなゲームを作っているの? • Android 2.3 以降対応の音ゲーム • 自社製ゲームエンジン • 自社製サーバサイドフレームワーク • 既に2年くらい運用中 • 2∼3ヶ月に1度アップデートを実施 今回は,こんなゲームの運用経験を元にノウハウを共有します
  5. あるゲームアプリの構成
  6. - あるパイプラインエンジニア曰く ゲームはソースコードのみにて在るに非ず
  7. ソース コード マスターデータ 音声 データ 画像 データ リソースの海 素敵ゲームアプリ の力? ゲームエンジン ムービー いかにして多種多様なリソースからゲームを生成するのか? API
  8. • 様々なリソースから の力で素敵なゲームアプリができる わけではない • 音声ファイル,画像ファイル,ソースコード,マスターデー タ等のリソースをまとめあげてアプリとして具現化するビ ルドシステムが存在する • 私達は,主に Jenkins と Github を用いたシステムを構 築している(次ページ) ゲームはソースコードのみにて在るに非ず
  9. 様々なリソースを束ねる Jenkins を使ったビルドシステム APIサーバゲームアプリ(apk) Jenkins fetch ゲーム エンジン NDK, Gradle フロントエンド UI サーバサイド PHP Jenkins fetch 追加DL用 音声,画像等 API通信 Amazon S3 Jenkins fetch deploy upload マスターデータ 音声,画像等 fetchfetch DL
  10. • 私達はこのビルドシステムを,「パイプライン」と呼んで いる.そして,パイプラインの整備を専門にする「パイプ ラインエンジニア」のチームが存在する • マスターデータのバリデーションやアセットの整合性 チェックなども,Jenkins の中で動かしている • Github や Jenkins マシンが死ぬとプロジェクトが止まる リスクがあったりする 様々なリソースを束ねる Jenkins を使ったビルドシステム
  11. 参考書籍 • ゲーム・映像制作パイプラ イン構築マニュアル • 2014年 • 税込み約6500円
  12. ゲームエンジン在らざればゲーム在らず - あるパイプラインエンジニア曰く
  13. • 昨今のゲーム開発はゲームエンジンの上でゲームを作るこ とが非常に多い,と思う • 私達は Playground というゲームエンジンを使ってい る.これはOSS でも公開されている • https://github.com/KLab/PlaygroundOSS/ • 社内にゲームエンジンチームがあって,Playground ゲー ムエンジンの開発を専門に行っている • ゲームの UI は,ゲームエンジンに付属する IDE で作れる ようになっている どんなゲームエンジンを使っているのか
  14. エンジン自作の嬉しさと悲しさ • 音ゲーを作っているので,オーディオ周りなどでハードウェ ア寄りの細かい制御をできるのはゲームエンジンを作って いる強みになっている • ググっても情報がない.しかし開発者に直に質問可能 • 例えば,新しいバージョンの OS(Lollipop) への対応がス ムーズにできたりとか,比較的小回りが効く
  15. ゲームフロントエンド(UI, ゲームロジック) Open GLOS機能 (ファイルIO,スレッド…) タスクシステム アセット管理 知財暗号化 OSごとのポーティング層 (Java, Obj-C) 描画ラッパー データベース その他 ゲームエンジン (Playground) (Lua, XML) (C, C++ 等) ゲームエンジン Playground の おおざっぱな構成
  16. アップデートサイクル
  17. たった 50MB ぽっち! - あるパイプラインエンジニア曰く
  18. たった 50MB ぽっち! • Google Play から Wi-Fi を使わない環境でダウンロード できる apk の最大サイズ • 多いように感じるかもしれないけど,ゲーム開発をしてい ると全然足りなくなることもしばしばしばしば • はみ出したリソースは,追加ダウンロードの仕組みを作っ て使って対応する(expansion packを使っているゲームも 最近は多いですが,ここでは使っていません)
  19. 追加ダウンロードのしくみ 全アセット空間 (数百MB∼数GB) アセットリスト (API サーバ) Amazon S3 アセット アップロード アセットリスト 作成 画像 ムービー 音声 UI 情報 その他 apk (50MB) ダウンロード リスト取得 アセット ダウンロード リソース 抽出 • API サーバにアセットのリストを作っておいて,アセット自体は Amazon S3 からダウンロードする仕組みになっている
  20. 追加ダウンロードのしくみ を使ってアップデート アセットリスト (API サーバ) Amazon S3 差分アセット アップロード アセット差分 リスト作成 apk ver 1.0 -> 1.1 差分 リスト取得 差分アセット ダウンロード リソース 抽出 • 追加DLの仕組みを応用してアセットのアップデートもできる ver 1.0 アセット集合 ver 1.1 アセット集合 差分アセット集合
  21. アップデートはゲームアプリの呼吸なり - あるパイプラインエンジニア曰く
  22. アップデートはゲームアプリの呼吸だ • ゲームを面白く新鮮に保つためには,アップデートが必要 • 新機能追加,新キャラ追加,UI改修,性能チューニ ング • スムーズにアップデートを回していくためにどうしたら良 いのだろうか?ということを話す • 前置き:アップデートには 2 種類ある
  23. 2 種類のアップデート アップデート方法 期間 更新内容 関連エンジニア Google Play 数ヶ月単位 (コードの改修) ・ゲームロジック改修 ・ゲームエンジン改修 ・フロントエンド ・ゲームエンジン ・サーバサイド 追加 ダウンロード 数週間単位 (リソースの追加) ・アイテム追加 ・キャラクター追加 ・サーバサイド ・運用エンジニア •今回話すのは主に Google Play からのアップデートのほう
  24. • アップデートには想像されるように様々なフェーズが存在 する • 仕様策定,実装,レビュー,動作テスト,リリース • それらをどうつなぎあわせてリリースまでもっていくか は,実は自明ではない • 次ページで仕様策定からリリースまでの一連の流れの例 をあげる アップデートサイクル
  25. 仕様策定 アップデートテスト 実装 コードレビュー テスト(開発者) リリース テストエンジニア レビューパス テストパス コメント・修正 フィードバック テストパス バグ報告 ユニットテスト, 手元テスト リリースリハーサル リハーサル 成功 ユーザサポート クラッシュ レポート リリース後 こんなものを作りたい という気持ち 明文化 アップデートサイクルの一連の流れの例
  26. • デイリーで apk を作成してテストエンジニアへ • テストサイクルがうまく回るかどうかは,アップデートの成否に 関わる問題 • テストを上手くまわすための技術開発に工数を使うことも積極的 に検討 • UIパーツやゲームロジックといったゲームフロントエンド は差し替えずに,ゲームエンジンだけを入れ替えてテスト できるようにしてみたり… • 通信速度あげるために有線 LAN アダプタを挿してみたり… テストの比重は重い
  27. デバッグのための2種類のapk アセット apk サイズ テスト内容 FULL版 全部 apk 内 数百MB∼数GB ・新機能 ・バグフィックス DL版 最小限 + 追加DL 50MB ・追加DL ・Google Play α版 ・Google Play β版 •新機能テストのとき,いちいち数百MBの追加ダウンロードはやってられ ないため,すべてのアセットを含んだ FULL版 と呼ばれる巨大な apk が使われる
  28. 実装者下暗し - あるテストエンジニア曰く
  29. • View 部分の動作テストは自動化が非常に難しい • テストエンジニアによる動作テストは必須 • 実装者自身は動作テストを都合の良いように最適化してし まう(ことがある) • テストエンジニアは,実装者が見落としてしまいそうな遷 移の不具合を,仕様と優れたメソッド(企業秘密)で発 見してくれる テストエンジニアによるテストの価値
  30. プロの手によって発見されたバグ再現手順の例 電源ボタンでゲームをバックグラウンドにし,即座にフォア グラウンドに戻すと発生するバグ このようなバグは開発者の動作テストでは見つかる確率低
  31. • リリース後はクラッシュレポートでユーザの手元で起こったクラッ シュを監視 • Developer Console のクラッシュレポートはあまり参考になら ない • クラッシュレポートツール選び • 遅延なくでクラッシュを監視できるか? • NDK 部分と Java 部分で起こったクラッシュを分けて分 析できるか クラッシュレポートコレクターになろう
  32. まとめ • あるゲームアプリの構成 • Jenkins と Github を多用したパイプラインを構築している • Playground というゲームエンジンを使用している • アップデートサイクル • Google Play, 追加DL の2種類のアップデートがある • テストの比重は比較的重い.テストをいろいろ工夫する • テストエンジニアのテストは必須 • 外部のクラッシュレポートツールを使ってクラッシュを監視
  33. PR • CodeLunch.fm というポッドキャストに出たりしてます • http://codelunch.fm/
Advertisement