Slide 1

Slide 1 text

全社総会における「REALITY Spaces」の活用と、 Addressableを用いたコンテンツ配信技術について REALITY XR cloud株式会社 エンジニアマネージャー 横内 優作 REALITY XR cloud株式会社 クライアントエンジニア 古屋 研太

Slide 2

Slide 2 text

横内 優作 自己紹介 ● 経歴 ○ 前職はモバイルゲームの開発エンジニア。 2020年グリーグループにジョイン。 ○ toB向けの事業部でエンジニアとして UnityをはじめReactやCocosCreatorな どを利用した案件を複数担当。 ○ 現在はエンジニアマネージャーと案件の開 発責任者を兼任。 2

Slide 3

Slide 3 text

古屋研太 自己紹介 ● 経歴 ○ インディーゲームからゲーム開発を始め、 ゲーム会社やフリーランスとしてXRコンテ ンツの開発を経験。 ○ 主にリアルタイム通信を活用したVR対戦 ゲームなど経験を活かし、現在は法人向け メタバース事業に従事。 3

Slide 4

Slide 4 text

REALITY Spacesの活用事例と概要 4

Slide 5

Slide 5 text

REALITY XR Cloud社について 5 https://reality-xrcloud.inc/ メタバース事業で法人向け(toB)のソリューションやサービスの提供をしています 


Slide 6

Slide 6 text

REALITY Spacesとは ● XRcloud社の社内ソリューション ○ 法人向けに空間の提供 ● 1つのアプリで複数の空間にアクセス ○ Win/Mac/Android/iOS ● 空間内でのコミュニケーション ○ テキストチャット/ボイスチャット /エモート ● ライブ動画再生や画面共有機能など 6

Slide 7

Slide 7 text

全社総会でのREALITY Spacesの活用 ● 2023年7月21日 グリー全社総会で XRcloud社のREALITY Spacesを活用して 実施いただきました! ○ 参加者は最大400人弱でした ● 株主総会も同会場で実施いたしました 7

Slide 8

Slide 8 text

REALITY Spacesのシステム構成 ● Unity ○ クライアントアプリ ○ リアルタイムサーバー ■ GCE ● Go ○ APIサーバー ■ CloudRun 8 前年の発表: メタバースにおけるリアルタイム通信入門

Slide 9

Slide 9 text

クライアントアプリケーションの技術 ● Unity ○ リアルタイム通信全般 ■ FishNet (OSS) ○ ボイスチャット ■ DissonanceVoiceChat (有料アセット) ○ 動画再生 ■ AVPro (有料アセット) ○ コンテンツ配信 ■ Addressable (Unity標準機能) 9

Slide 10

Slide 10 text

Spacesにおけるコンテンツ管理 実行ファイルを更新せずにコンテンツを更新する必要がある ● ルーム内に表示する画像や音声、動画を変更したい ● 全く新しいルームの背景を追加したい ● 前者は画像や動画はWebRequestで簡単に取得/表示できる ● 後者はAddressable Asset System で対応 今回は Addressable にフォーカス 10

Slide 11

Slide 11 text

Addressable Asset System とは “AssetBundleをより簡単に管理できる” ● 動的なロード/アンロード ○ アドレスによるアセットのロード ○ 参照カウンタによるアンロード管理 ● AssetBundleのビルド管理 ○ Group/Label毎にパッキング ● ロード方法の切替 ○ Editorではビルドなしでsimulation ○ リモートコンテンツとしての更新機能 Unity道場 より https://learning.unity3d.jp/2272/ 11

Slide 12

Slide 12 text

基本的なコンテンツ更新機能の利用法① ● 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

Slide 13

Slide 13 text

基本的なコンテンツ更新機能の利用法② ● まずはNew Buildを実行しBuildPathに出 力されたファイルをアップロードする ○ RemoteLoadPathに対応するように置くこと ● 実行ファイルをビルドして動作確認 ● 更新したいアセットを修正したらUpdate Buildを実行して再アップロード ● 実行ファイルをビルドしないで起動して動作 確認 => 修正が反映される 13 BuildPath に出力されたフォルダを LoadPath のサーバーにアップロードする

Slide 14

Slide 14 text

そのまま利用した場合の課題 運用を想定するとこのままの設定では扱うことができない ● 本番環境を変えずに開発環境のアセットを更新したい ● 同じ開発環境ビルドを使って並行して別のルームを開発できない ○ ダウンロード先が同じだと、定期的にコンテンツをビルドするまで実機確認できない ● ビルド環境が変わったときにUpdateビルドができない ○ そもそもupdateビルドに必要なファイルはどれ? 実はAddressableの機能だけで対応可能 14

Slide 15

Slide 15 text

リリース/開発環境切替機能 環境ごとにProfileを切り替える ● Profileは複数作成できる ○ 左上のCreateから Profileを選択する ○ それぞれのProfileでRemoteBuildPathと RemoteLoadPathを変更することで違う保存先とダウンロード先を指定できる ● 最低3つは作成しておくのが吉 ○ リリース環境と開発環境に加えて、安定板の開発環境を作成しておくとよい ■ 後述の並行して別のルーム を作成するフローを考えた際、ベースになる開発環境が頻繁に 更新されると追従するのが難しい ■ Prod / Stable / Devの3つを作成してして運用 15

Slide 16

Slide 16 text

コンテンツ切替 機能 (1/3) Profileの切替だけの限界 ● Profileの切替のみだとProfileの数しかコンテンツを切り替えられない ○ 同時に複数のルーム作成を進行する場合、こまめなテストプレイがしにくい ■ Stable/Dev環境にマージされるまで実機で検証ができない… ● 開発ブランチ毎に違うコンテンツをビルドしてアップロード ● 実行中にコンテンツのダウンロード先を切り替える 16  Prod環境  Stable環境  RoomA開発  RoomB開発 マージまで待つ? いちいちマージしないでもコンテ ンツビルドしたい

Slide 17

Slide 17 text

ProfileのPATHの記法 前述の課題の解決のためコンテンツのダウンロード先を変更可能にしたい ⇒ Profileに記載したパスを柔軟に変更出来ればよい ● [] でビルド時にStatic変数を埋め込む ○ https://test.com/[HogeNameSpace.FugaClass.BooString]/ServerData/… のように記述すれば適用できる 初期設定でも使われているので見覚えがあるはず ● {}で実行時にStatic変数を埋め込む ○ []ではなく {}で囲んだ場合はアプリ実行時に変更できる ○ Addressableの初期化後に変数を変更した場合は反映されないので注意 ■ Addressable.Load** メソッドを使用しても自動で初期化されるので意図しない初期化に注 意する (Addressables.ResourceLocators.Count() が0以上になっているかどうかで初 期化が意図しないタイミングでしているかを調べておくと吉 ) 17

Slide 18

Slide 18 text

コンテンツ切替 機能 (2/3) 切替をstatic変数を使うことで回避する ● RemoteBuildPath には [] 内に記述してビルド時に解決する ○ Editor拡張でAddressableのビルド前にstatic変数に値を入れる ○ 出力フォルダにそれぞれのブランチコンテンツのビルドが分かれて保存される ○ ServerDataフォルダをそのままファイルサーバーにアップロードすれば OK   ● RemoteLoadPath には {}内に記述実行時に解決する ○ BuildPathで分けたフォルダを読み込めるように {}で記述する ○ 実行時に変更できるので、デバッグコマンドで変更すれば読み替えられる ● リリース環境でもABテストとかにも利用可能 18

Slide 19

Slide 19 text

コンテンツ切替 機能 (3/3) Profileの例 テスト動画 19

Slide 20

Slide 20 text

別環境でのビルド&アップロード (1/3) ● 複数のビルドマシンを使う場合や、故障などで移行することを考える必要 ○ 故障したためUpdate Buildができずが配布できないとかがあってはいけない ○ 別の環境でもUpdate Buildが引き継げるように最低限の情報をバージョン管理したい        addressables_content_state.bin が鍵 ● New Buildした際に生成されるこのファイルだけあれば良い ○ BuildPathにあるコンテンツファイル自体はなくても Update Buildが作成可能 ○ デフォルトだとAssets/AddressableAssetsDataフォルダに上書き保存してしまうので変更 ■ 初期設定だと環境切替で Profileを変えると 前のを上書きして消してしまう ■ ビルドしたコンテンツのフォルダにあれば Profile毎に保存されるので RemoteBuildPathに設定する 20

Slide 21

Slide 21 text

別環境でのビルド&アップロード (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

Slide 22

Slide 22 text

別環境でのビルド&アップロード (3/3) jenkinsなどのCI環境も複数の開発が並行すると混んでしまうことがあるが、 個人PCでもビルドができる ● binファイルを取得すればいいので、個人PC上でもUpdate Buildができる ● コンテンツ切替機能で別のコンテンツとして設定しておけば、ルームを作成するデ ザイナー自身が確認したいときにビルドして実機確認も可能 ○ 確認したいPlatformだけビルドできるようにしておくと良い ○ Headlessビルドサーバーがある場合はサーバー側のコンテンツ更新を忘れずに 22

Slide 23

Slide 23 text

今回の手法の総括 ● Addressable Asset Systemはそのままでも工夫次第でぜんぜん使える ● リリース環境のアセットに影響与えず開発環境の更新ができる ● ブランチ切替機能で並行してルームの開発/確認ができる ● ビルドサーバーの混雑を気にしないでローカル環境でビルドも可能 今後の課題 ● 別プロジェクトのコンテンツカタログの読み込み ○ リポジトリの肥大化を抑制する ○ ルーム背景製作などを外部製作でできるように 23

Slide 24

Slide 24 text

ご清聴ありがとうございました 24