全社総会における「REALITY Spaces」の活用と、Addressableを用いたコンテンツ配信技術について

GREE Tech Conference 2023で発表された資料です。
https://techcon.gree.jp/2023/session/TrackC-1

Transcript

1. 全社総会における「REALITY Spaces」の活用と、 Addressableを用いたコンテンツ配信技術について REALITY XR cloud株式会社 エンジニアマネージャー 横内 優作 REALITY XR cloud株式会社 クライアントエンジニア 古屋 研太
2. 横内 優作 自己紹介 • 経歴 ◦ 前職はモバイルゲームの開発エンジニア。 2020年グリーグループにジョイン。 ◦ toB向けの事業部でエンジニアとして UnityをはじめReactやCocosCreatorな どを利用した案件を複数担当。 ◦ 現在はエンジニアマネージャーと案件の開 発責任者を兼任。 2
3. 古屋研太 自己紹介 • 経歴 ◦ インディーゲームからゲーム開発を始め、 ゲーム会社やフリーランスとしてXRコンテ ンツの開発を経験。 ◦ 主にリアルタイム通信を活用したVR対戦 ゲームなど経験を活かし、現在は法人向け メタバース事業に従事。 3
4. REALITY Spacesの活用事例と概要 4
5. REALITY XR Cloud社について 5 https://reality-xrcloud.inc/ メタバース事業で法人向け(toB)のソリューションやサービスの提供をしています 

6. REALITY Spacesとは • XRcloud社の社内ソリューション ◦ 法人向けに空間の提供 • 1つのアプリで複数の空間にアクセス ◦ Win/Mac/Android/iOS • 空間内でのコミュニケーション ◦ テキストチャット/ボイスチャット /エモート • ライブ動画再生や画面共有機能など 6
7. 全社総会でのREALITY Spacesの活用 • 2023年7月21日 グリー全社総会で XRcloud社のREALITY Spacesを活用して 実施いただきました！ ◦ 参加者は最大400人弱でした • 株主総会も同会場で実施いたしました 7
8. REALITY Spacesのシステム構成 • Unity ◦ クライアントアプリ ◦ リアルタイムサーバー ▪ GCE • Go ◦ APIサーバー ▪ CloudRun 8 前年の発表: メタバースにおけるリアルタイム通信入門
9. クライアントアプリケーションの技術 • Unity ◦ リアルタイム通信全般 ▪ FishNet (OSS) ◦ ボイスチャット ▪ DissonanceVoiceChat (有料アセット) ◦ 動画再生 ▪ AVPro (有料アセット) ◦ コンテンツ配信 ▪ Addressable (Unity標準機能) 9
10. Spacesにおけるコンテンツ管理 実行ファイルを更新せずにコンテンツを更新する必要がある • ルーム内に表示する画像や音声、動画を変更したい • 全く新しいルームの背景を追加したい • 前者は画像や動画はWebRequestで簡単に取得/表示できる • 後者はAddressable Asset System で対応 今回は Addressable にフォーカス 10
11. Addressable Asset System とは “AssetBundleをより簡単に管理できる” • 動的なロード/アンロード ◦ アドレスによるアセットのロード ◦ 参照カウンタによるアンロード管理 • AssetBundleのビルド管理 ◦ Group/Label毎にパッキング • ロード方法の切替 ◦ Editorではビルドなしでsimulation ◦ リモートコンテンツとしての更新機能 Unity道場 より https://learning.unity3d.jp/2272/ 11
12. 基本的なコンテンツ更新機能の利用法① • SettingsのRemote Catalogを有効化 ◦ アドレスとアセットのロードの場所を管理するカタロ グが更新可能になる • Groupの Build/LoadPathをRemoteに ◦ Can Change Post Releaseにすること • ProfileのRemoteLoadPathを 任意のサーバーのURLに変更する ◦ GCSとかであればパブリック公開に設定した bucketを指定し、そこにuploadすればOK https://storage.googleapis.com/(BUCKET_NAME)/(OBJECT_NAME) 12
13. 基本的なコンテンツ更新機能の利用法② • まずはNew Buildを実行しBuildPathに出 力されたファイルをアップロードする ◦ RemoteLoadPathに対応するように置くこと • 実行ファイルをビルドして動作確認 • 更新したいアセットを修正したらUpdate Buildを実行して再アップロード • 実行ファイルをビルドしないで起動して動作 確認 => 修正が反映される 13 BuildPath に出力されたフォルダを LoadPath のサーバーにアップロードする
14. そのまま利用した場合の課題 運用を想定するとこのままの設定では扱うことができない • 本番環境を変えずに開発環境のアセットを更新したい • 同じ開発環境ビルドを使って並行して別のルームを開発できない ◦ ダウンロード先が同じだと、定期的にコンテンツをビルドするまで実機確認できない • ビルド環境が変わったときにUpdateビルドができない ◦ そもそもupdateビルドに必要なファイルはどれ？ 実はAddressableの機能だけで対応可能 14
15. リリース/開発環境切替機能 環境ごとにProfileを切り替える • Profileは複数作成できる ◦ 左上のCreateから Profileを選択する ◦ それぞれのProfileでRemoteBuildPathと RemoteLoadPathを変更することで違う保存先とダウンロード先を指定できる • 最低3つは作成しておくのが吉 ◦ リリース環境と開発環境に加えて、安定板の開発環境を作成しておくとよい ▪ 後述の並行して別のルーム を作成するフローを考えた際、ベースになる開発環境が頻繁に 更新されると追従するのが難しい ▪ Prod / Stable / Devの３つを作成してして運用 15
16. コンテンツ切替 機能 (1/3) Profileの切替だけの限界 • Profileの切替のみだとProfileの数しかコンテンツを切り替えられない ◦ 同時に複数のルーム作成を進行する場合、こまめなテストプレイがしにくい ▪ Stable/Dev環境にマージされるまで実機で検証ができない… • 開発ブランチ毎に違うコンテンツをビルドしてアップロード • 実行中にコンテンツのダウンロード先を切り替える 16 　Prod環境 　Stable環境 　RoomA開発 　RoomB開発 マージまで待つ？ いちいちマージしないでもコンテ ンツビルドしたい
17. ProfileのPATHの記法 前述の課題の解決のためコンテンツのダウンロード先を変更可能にしたい ⇒ Profileに記載したパスを柔軟に変更出来ればよい • [] でビルド時にStatic変数を埋め込む ◦ https://test.com/[HogeNameSpace.FugaClass.BooString]/ServerData/… のように記述すれば適用できる　初期設定でも使われているので見覚えがあるはず • {}で実行時にStatic変数を埋め込む ◦ []ではなく {}で囲んだ場合はアプリ実行時に変更できる ◦ Addressableの初期化後に変数を変更した場合は反映されないので注意 ▪ Addressable.Load** メソッドを使用しても自動で初期化されるので意図しない初期化に注 意する　(Addressables.ResourceLocators.Count() が0以上になっているかどうかで初 期化が意図しないタイミングでしているかを調べておくと吉 ) 17
18. コンテンツ切替 機能 (2/3) 切替をstatic変数を使うことで回避する • RemoteBuildPath には [] 内に記述してビルド時に解決する ◦ Editor拡張でAddressableのビルド前にstatic変数に値を入れる ◦ 出力フォルダにそれぞれのブランチコンテンツのビルドが分かれて保存される ◦ ServerDataフォルダをそのままファイルサーバーにアップロードすれば OK 　 • RemoteLoadPath には {}内に記述実行時に解決する ◦ BuildPathで分けたフォルダを読み込めるように {}で記述する ◦ 実行時に変更できるので、デバッグコマンドで変更すれば読み替えられる • リリース環境でもABテストとかにも利用可能 18
19. コンテンツ切替 機能 (3/3) Profileの例 テスト動画 19
20. 別環境でのビルド&アップロード (1/3) • 複数のビルドマシンを使う場合や、故障などで移行することを考える必要 ◦ 故障したためUpdate Buildができずが配布できないとかがあってはいけない ◦ 別の環境でもUpdate Buildが引き継げるように最低限の情報をバージョン管理したい 　　　　　　　addressables_content_state.bin が鍵 • New Buildした際に生成されるこのファイルだけあれば良い ◦ BuildPathにあるコンテンツファイル自体はなくても Update Buildが作成可能 ◦ デフォルトだとAssets/AddressableAssetsDataフォルダに上書き保存してしまうので変更 ▪ 初期設定だと環境切替で Profileを変えると 前のを上書きして消してしまう ▪ ビルドしたコンテンツのフォルダにあれば Profile毎に保存されるので RemoteBuildPathに設定する 20
21. 別環境でのビルド&アップロード (2/3) Updateビルドフロー 1. New Buildで生成されたaddressables_content_state.binファイルは バージョン管理などで保管する 2. UpdateBuildをする場合、binファイルがなければ(=New Build環境とは別の環 境でビルドしている) 保管して置いたbinファイルを取得し、RemoteBuildPathで 指定したフォルダに移動する 3. Update Buildを実行する 4. 出力されたコンテンツをアップロードすればOK Group設定でBundleNamingModeをAppendHashToFileNameに しておくのがおススメ (変更があった場合hash値が変わるので、重複 しないファイルだけアップロードするとかがやり易い ) 21
22. 別環境でのビルド&アップロード (3/3) jenkinsなどのCI環境も複数の開発が並行すると混んでしまうことがあるが、 個人PCでもビルドができる • binファイルを取得すればいいので、個人PC上でもUpdate Buildができる • コンテンツ切替機能で別のコンテンツとして設定しておけば、ルームを作成するデ ザイナー自身が確認したいときにビルドして実機確認も可能 ◦ 確認したいPlatformだけビルドできるようにしておくと良い ◦ Headlessビルドサーバーがある場合はサーバー側のコンテンツ更新を忘れずに 22
23. 今回の手法の総括 • Addressable Asset Systemはそのままでも工夫次第でぜんぜん使える • リリース環境のアセットに影響与えず開発環境の更新ができる • ブランチ切替機能で並行してルームの開発/確認ができる • ビルドサーバーの混雑を気にしないでローカル環境でビルドも可能 今後の課題 • 別プロジェクトのコンテンツカタログの読み込み ◦ リポジトリの肥大化を抑制する ◦ ルーム背景製作などを外部製作でできるように 23
24. ご清聴ありがとうございました 24