見出し画像

Leap Triggerの仮説検証を支えた開発効率を促進させる取り組み

GRAFFITY | ARで、リアルを遊べ。

こんにちは！GraffityのAzukiです

今回は、先日ついに日本でもリリースさせていただいたLeap Triggerの開発を行う上で、ゲームの開発効率を向上させるためにエンジニアチームが取り組んだことについていくつかご紹介します。

企画・仮説検証の話についてはLeap Triggerプロデューサーのしょーたさんに記事を書いていただいているのでよろしければそちらもご覧ください！

Leap Triggerを開発したチーム体制について

Leap Triggerプロジェクトは

  • プロジェクトメンバーは最大10人前後

    • うちエンジニア(非フルタイムメンバー含む)は Unity 4~6人, サーバー 1~2人

  • 開発は2020年の4月ごろスタート

    • USリリースは2021年3月

    • クローズドベータテストをUSで実施し、テスト自体は2020年の6月に実施

という、基本無料・アイテム課金ありの運用型のモバイルゲーム開発においては決して大きくはないチーム、長くはない開発期間でリリースをしています。
そのため開発効率を出来る限り上げていき、面倒な事は全部自動化、開発中のデータの可視化、不具合発生時のコミュニケーションコストの削減に向けた取り組み等を常に行っていました。

今回の記事ではそれらを一部ご紹介します。

ビルドについて

Unityでアプリを開発していると必ず起きる問題として、完成したバイナリをどうやって配布するか、というのがあります。

LeapTriggerプロジェクトではJenkinsを利用し、CI/CD環境を構築しました。

アプリケーションのビルドはブランチ名と配布先環境名を指定するだけで自動でビルド→DeployGateへの配布までを行うようにしました。

roppongi.unityのスライドから抜粋

ビルドする際はビルド用SlackチャンネルよりHubotを経由することで、エンジニア以外がJenkinsを直接触ることが出来ないようにしていました（Jenkinsの設定をうっかり弄られたりすると大変なのと、Jenkins上でユーザー権限絞ったりするのは管理コストが膨れ上がるため）

LeapTriggerではSlackのWorkflowBuilderを使用し、ビルド用のフォームを作成しました。
これにより非エンジニアでもブランチ名さえわかれば自分の環境にアプリをビルドすることができる仕組みを構築しました

また、Graffityではビルドマシンを並列化しており、最大３台同時にビルドを行えるようにしています。この並列化は開発佳境の際でもビルドがすぐ終わるので大変重宝しました。（特に実機での体感チェックはARゲームだと頻発するのでビルド速度は大事です）

LeapTrigger開発を支えたデータビューワーについて

LeapTriggerはゲームエンジンのUnityを使用して開発を行いました。
基本的にクライアントエンジニア以外のサーバーエンジニア、企画職もUnityをインストールし、開発中のクライアントをUnityEditor上で触れるようにしていました。

Unityで開発する時の醍醐味として、Editor拡張があります。
Editor拡張を行うことで便利な開発支援ツールを簡単に作成することが出来ました。実際にメンバーから好評だった物をいくつか紹介します。

WebApiLogViewer

サーバーとの通信のログを閲覧することができるビューワー

LeapTriggerではサーバーとの通信は全て暗号化しており、通信内容が抜かれても基本的に内容が推測できないようになっています。

それ自体はとても良い事なのですが、開発中に通信している内容がわからないと正しいレスポンスが来ているのか、正しくリクエストが送信できているのかを調べるのが苦労してしまうためビューワーを作成しました。

また、サーバーサイドエンジニアが実装したAPIの挙動をアプリ上で確認する際にもとても便利という事で好評でした。

InGameDataViewer

LeapTriggerはマルチプレイで対戦を行うゲームです。そのためインゲームでは様々な情報を送りあうことでバトルを成立させています。

不具合が発生したときなどに内部で持っている現在の情報が把握できないとデバッグが大変というのもあり、ビューワーを作成し詳細な情報をEditor上で確認できるようにしていました。

MasterDataViewer

LeapTriggerも多くのソーシャルゲームと同様、マスターデータをクライアント内で保持して情報を表示したりしています。
データ由来の不具合が発生したときにマスターデータを入力した企画職がチェックできるようにビューワーを作成しました

これだけEditor拡張ではなくアプリ実行中のデバッグ機能として実装しています。実機でバグに気付いたときにすぐにチェックできるので便利です。

当然ですが、本番ビルドにはこのアセットそのものがビルドに入らないようにしています（大事）

多言語化対応について

LeapTriggerプロジェクトでは開発初期から『少なくとも日本以外の国で出す』という事が決まっていた為、プロジェクト初期から多言語化対応前提で進めていました。

多言語化を実現するためにUIやゲーム内で登場するすべてのテキスト（マスターデータ由来の物以外）はテキストのデータベースをGoogleスプレッドシートで作成し、それを参照する作りにしました。

現在ではUnityのローカライズ用のLocalizationというパッケージで同じことが実現できるかもしれませんがLeapTriggerのプロジェクトではI2Localizationというアセットを利用し、テキストを管理していました。

これによりエンジニアはテキストに対応するKeyを入れて企画、デザイナーさんがスプレッドシートでテキストを編集するだけでアプリ内テキストを全て更新することができる様になっていました。

また、「このKeyってどこで使っているんだっけ？」という事が発生してもすぐに該当のPrefab・ソースコードが特定できるように専用のツールも作成していました。
これにより使わなくなったKeyの棚卸もスムーズに行えました。

結果発表おぉおぉおおお

色情報の管理について

LeapTriggerではゲーム内に登場する様々な色情報もデータベース管理していました。

このように設定ファイルを用意し、Keyを指定するだけでその色を出すことができる、といった機能を用意することにより、色変更を後でデザイナーさんだけで完結できるようにしました。

Assetの自動インポート設定について

LeapTriggerでは大量にリソース画像が存在します。

それらを毎回インポートする度に適切に圧縮設定や解像度設定をUnity上で行うのは非効率＆漏れが発生しやすい為、自動化するツールを作成し、Unityにアセットをインポートした際に自動で設定が行われるようにしています。

本ツールは社内ライブラリとして作成しましたが大変便利だったのでGithub上で公開しています！

詳細については昨年末に弊社エンジニアのcovaが登壇したLTイベントにて紹介しております。
UnityLMに掲載もされてますのでよろしければ是非ご覧ください！

UITestについて

ゲーム開発あるあるですが、画面A用に開発した機能が原因で画面Bが動かなくなる、といった不具合をいち早く検知するためにLeapTriggerではUITestを自動で行うようにしていました。

中国のNetEase社が開発しているAirTestIDEを利用しテストを作成し、毎日深夜に最新ビルドでテストを実行するという仕組みを構築しています。

詳細についてはこちらも昨年度末に私が登壇したLTイベントにて紹介しております。
UnityLMに掲載されていますのでよろしければご覧ください！

GithubActionでのソースコード解析

Graffityではプロダクトのコードレビューが非常に活発に行われています。

レビューにより不具合を事前に防いだり、書き方のアドバイスなどを行っているのですが、さすがに実際に動かすとコンパイルエラーを起こす様なコードが紛れてた場合、気付けないこともあります（checkoutして確認すればいい話ではありますがPRの数も多いといちいちすべてローカルでチェックするというのは非現実的です）

そこでLeapTriggerではコンパイルエラーを検知し、アラートを出してくれるGithubActionを構築しています。

詳細は弊社エンジニアのsada(新卒2年目になりました)が何度かイベント登壇にて紹介しておりますのでよろしければご覧ください!

AddressableAssetSystemを使用したリソース管理

昨今のモバイルゲームはアプリ本体の容量を極力減らし、ランタイムで追加のリソースをダウンロードする仕組みが多いです。LeapTriggerではUnityのAddressableAssetSystemという比較的新しいリソース管理システムを利用しています。

LeapTriggerでのAddressableAssetSystem利用については昨年開催のRoppongi.Unityで私が登壇していますのでよろしければご覧ください

LeapTriggerではAddressableAssetSystemにかなり依存した実装をしており、所謂内部リソース（アプリに最初から入っているリソース）もAddressableAssetSystemを利用して読み込んでいます。読み込む際に必要なアドレスの生成などは全て内製のEditor拡張で自動振り分けするようにしており、リソース登録のコストを削減しています。

また、AddressableAssetSystemでリソースを管理する際、内部リソースが外部リソース（ダウンロードする予定のリソース）の参照を持っている場合、アプリ起動時に参照解決のために勝手にダウンロードが走ってしまうという問題があり（ダウンロードするタイミングは実装側で制御したいため）、そういった事象を未然に防ぐためにGithubActionで外部リソースを参照している内部リソースを検索しアラートを出してくれる機能を実装しています。

LeapTriggerプロジェクトのリポジトリでは基本的にGithubAction（コンパイルエラー検知・リソース参照検知・UnitTest）を全て合格した上でメンバー１名以上のApproveが無い限りはマージできないようにしているため、マージ後に動かなくなるといった問題の発生確率を極限にまで減らす事に成功しています。

実績値で言うとマージ後にコンパイルエラー、アプリ起動不可能な状況に陥ったことは導入後１度もありませんでした。

まとめ

LeapTrigger開発環境についていくつか事例をご紹介しました。
実際はまだ紹介できてない物もいくつかあるのですが、Graffityにおける開発効率化の様子が少しでも伝われば幸いです。

会社の規模が決して大きくはないスタートアップだからこそ、ゲーム開発におけるめんどくさい作業やコミュニケーションコストをマンパワーでの解決は絶対にせずに自動化、効率化で解決しながら進めていけたプロジェクトだったなと、JP版リリースを迎え改めて感じました。

Graffityでは、このような仮説検証力と仮説検証スピードを活かし「最短3か月で“心を動かす”ARエンタメ」をコンセプトに、AR技術に特化したエンタメの企画・開発と、DX化を支援するスタジオ「Graffity AR Studio」を運営しております。

これまで累計23万ダウンロードを突破したARシューティングバトル「ペチャバト」や、グローバルに展開しているARシューティングバトル「Leap Trigger」など、ARゲームを開発・運営しており、これらの知見を活かし、スピード感を持ってARを活用した“心動かす”エンタメの企画から運用までを、ワンストップでサポートいたします。

スピード感を持って仮説検証を通してAR体験をブラッシュアップしたい企業様はぜひ「Graffity AR Studio」へお問い合わせください。


この記事が気に入ったらサポートをしてみませんか？