Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
"人がいるメタバース" を実現するREALITYのワールド機能
Search
gree_tech
PRO
October 25, 2022
Technology
1
890
"人がいるメタバース" を実現するREALITYのワールド機能
GREE Tech Conference 2022で発表された資料です。
https://techcon.gree.jp/2022/session/TrackC-4
gree_tech
PRO
October 25, 2022
Tweet
Share
More Decks by gree_tech
See All by gree_tech
REALITY株式会社における開発生産性向上の取り組み: 失敗と成功から学んだこと
gree_tech
PRO
2
160
『ヘブンバーンズレッド』におけるフィールドギミックの裏側
gree_tech
PRO
2
120
セキュリティインシデント対応の体制・運用の試行錯誤 / greetechcon2024-session-a1
gree_tech
PRO
1
120
『アナザーエデン 時空を超える猫』国内海外同時運営実現への道のり ~別々で開発されたアプリを安定して同時リリースするまでの取り組み~
gree_tech
PRO
1
96
『アサルトリリィ Last Bullet』におけるクラウドストリーミング技術を用いたブラウザゲーム化の紹介
gree_tech
PRO
1
120
UnityによるPCアプリの新しい選択肢。「PC版 Google Play Games」への対応について
gree_tech
PRO
1
150
実機ビルドのエラーによる検証ブロッカーを0に!『ヘブンバーンズレッド』のスモークテスト自動化の取り組み
gree_tech
PRO
1
150
"ゲームQA業界の技術向上を目指す! 会社を超えた研究会の取り組み"
gree_tech
PRO
1
170
Jamstack でリニューアルするグリーグループのメディア
gree_tech
PRO
2
340
Other Decks in Technology
See All in Technology
総会員数1,500万人のレストランWeb予約サービスにおけるRustの活用
kymmt90
3
2.8k
間違いだらけのポストモーテム - ホントに役立つレビューはこうだ!
jacopen
5
930
品質管理チームのEMとして大事にしていること / QA EM
nihonbuson
0
370
もう一度、 事業を支えるシステムに。
leveragestech
6
3.1k
Microsoft 365と開発者ツールの素敵な関係
kkamegawa
1
1.4k
開発者向けツールを魔改造してセキュリティ診断ツールを作っている話 - 第1回 セキュリティ若手の会 LT
pizzacat83
0
260
【ASW21-01】STAMPSTPAで導き出した課題に対する対策立案手法の提案
hianraku9498
0
310
.NET のUnified AI Building Blocks 入門...!
okazuki
0
150
12/3(火)のBedrockアプデ速報(re:Invent 2024 Daily re:Cap #2 with AWS Heroes)
minorun365
PRO
4
120
店舗向けSaaSにおける 顧客要望活用の実践アプローチ(20241205_pmconf)
yujirooo
0
1.2k
ARRが3年で10倍になったプロダクト開発とAI活用の軌跡
akiroom
0
210
プロダクトの爆速開発を支える、 「作らない・削る・尖らせる」技術
applism118
5
2.5k
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Making the Leap to Tech Lead
cromwellryan
133
8.9k
Gamification - CAS2011
davidbonilla
80
5k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
YesSQL, Process and Tooling at Scale
rocio
169
14k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
1
230
How to Ace a Technical Interview
jacobian
276
23k
Speed Design
sergeychernyshev
25
640
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
17k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Making Projects Easy
brettharned
116
5.9k
Transcript
REALITY株式会社 クライアントエンジニア 三宅広大 "人がいるメタバース" を実現する REALITYのワールド機能
• 三宅広大/yaegaki • 2020年 REALITY株式会社 入社 • Unityエンジニア/テックリード • アバター関連
• ビデオ通話 • ワールド • etc 自己紹介 2
REALITYについて 3
スマホひとつでアバター作成、ライブ配信による交流やゲームまで楽しめるメタバース REALITYについて 4 アバター ライブ配信 コミュニケーション ゲーム ワールド
REALITYについて 5
REALITYについて 6
スマホひとつでアバター作成、ライブ配信による交流やゲームまで楽しめるメタバース REALITYについて 7 アバター ライブ配信 コミュニケーション ゲーム ワールド
ワールドについて 8
9 ワールドの概要
ワールドの概要 10
ワールドの機能(特徴) まとめ • REALITYアバターで最大8人で遊べる仮想空間 • 座る機能 • アイテム装着 • 動画配信視聴
• etc 11
ワールドの機能(特徴) まとめ • REALITYアバターで最大8人で遊べる仮想空間 • 座る機能 • アイテム装着 • 動画配信視聴
• etc 12
ワールドの機能(特徴) まとめ • REALITYアバターで最大8人で遊べる仮想空間 • 座る機能 • アイテム装着 • 動画配信視聴
• etc 13
動画配信視聴 • ワールド内に設置したスクリーンで動画を再生する機能 • HLS(HTTP Live Streaming)を用いたライブストリーミング視聴 にも対応 ◦ ワールドにいる人と一緒に視聴できる
• タイムテーブルを用いた動画再生機能 ◦ ライブストリーミングと静的なファイルによるCMを切り替え可能 14
動画配信視聴 15
動画配信視聴 16 ここがスクリーンに なっていて映像が流 れる
ワールドの機能(特徴) まとめ • REALITYアバターで最大8人で遊べる仮想空間 • 座る機能 • アイテム装着 • 動画配信視聴
• etc 17
その他機能 • テーマ機能 ◦ 同じワールドで見た目が変わる • アニメーション同期機能 ◦ オブジェクトのアニメーション再生時間を同期する •
オブジェクト状態同期機能 ◦ オブジェクトの任意のデータを同期する • SE再生機能 ◦ 特定のタイミングでSEを再生する機能 18
”人がいるメタバース”としてのワールド • 配信とシームレスに繋がっている ◦ 誰かと遊びたかったら配信を開けば”人”がいる • トライアルでは延べ来場者数が400万人*を超える ◦ ”箱”をつくっても”人”がいないを解決 •
世界中のREALITYユーザーに展開が可能 • さまざまな種類のワールドをリリース 19 *:2022年4月22日~2022年6月12日 自社調べ
桜ワールド これまでにリリースしたワールド 20
ミュージックフェスワールド これまでにリリースしたワールド 21
4周年記念ワールド これまでにリリースしたワールド 22
これまでにリリースしたワールド 23
コラボワールド これまでにリリースしたワールド • 他社様とのコラボワールドを複数リリース 24
ワールドの実装 25
ワールドの登場人物(ロール) • オーナー ◦ ワールドを起動した配信者 • コラボゲスト ◦ 配信にコラボゲストとして参加しているユーザー •
ビジター ◦ 視聴者の内、ワールドに参加しているユーザー ◦ 早い者勝ちで視聴者がワールド内視聴者になる • 視聴者 ◦ ワールドには参加せず視聴だけしているユーザー 26
ワールドの登場人物(ロール) • オーナー • コラボゲスト • ビジター • 視聴者 27
ワールド内にアバターが出現して 動き回れるユーザー 全てをまとめてメンバーと呼ぶ 合計で8人まで
ワールドの登場人物(ロール) • オーナー • コラボゲスト • ビジター • 視聴者 28
配信を見ているだけのユーザー ワールドにアバターが登場せず オーナーと同じ視点になる
ワールドの登場人物(ロール) 29 オーナー コラボゲスト ビジター 視聴者
ワールドの登場人物(ロール) 30 オーナー コラボゲスト ビジター 視聴者 アバターが登場 音声通話可能
ワールドの登場人物(ロール) 31 オーナー コラボゲスト ビジター 視聴者 アバターが登場のみ
ワールドの登場人物(ロール) 32 オーナー コラボゲスト ビジター 視聴者 自分のアバターが 登場しない オーナーと同じ視点
ネットワークミドルウェア • 外部ミドルウェアは使用せず独自実装 • WebSocketを用いたリアルタイム通信 • サーバー側はパケットのリレーとステートの保存を行う ◦ ワールドのロジックを持たない 33
ワールドのメッセージング • ワールドでの出来事を全ユーザーに共有する方法 ◦ ステート更新パターン ◦ ブロードキャストパターン 34
ワールドのメッセージング • ステート更新パターン • ブロードキャストパターン 35
ステート更新パターン ワールドのメッセージング • 視聴者のワールド参加の例 ◦ 初めは全てのクライアントは同 じステートを共有している ◦ ステートには参加しているメン バーの情報が保存されている
36 オーナー ステート:A 視聴者 ステート:A MultiGameServer ステート:A メンバー ステート:A
ステート更新パターン ワールドのメッセージング • オーナーにワールド参加を要 求する 37 オーナー ステート:A 視聴者 ステート:A
MultiGameServer ステート:A メンバー ステート:A
ステート更新パターン ワールドのメッセージング • 要求が正しければメンバーリ ストを更新する 38 オーナー ステート:B 視聴者 ステート:A
MultiGameServer ステート:A メンバー ステート:A
ステート更新パターン ワールドのメッセージング • オーナーがサーバーにステー トを登録する 39 オーナー ステート:B 視聴者 ステート:A
MultiGameServer ステート:B メンバー ステート:A
ステート更新パターン ワールドのメッセージング • サーバーがオーナー以外にス テートを送信する 40 オーナー ステート:B 視聴者 ステート:B
MultiGameServer ステート:B メンバー ステート:B
ステート更新パターン ワールドのメッセージング • ステートの情報を用いて更新 する ◦ 視聴者が無事メンバーになる 41 オーナー ステート:B
メンバー ステート:B MultiGameServer ステート:B メンバー ステート:B
ステート更新パターン ワールドのメッセージング • オーナーのアプリが落ちた場 合 ◦ メモリ上のステートが失われる 42 オーナー ステート:X
メンバー ステート:B MultiGameServer ステート:B メンバー ステート:B
ステート更新パターン ワールドのメッセージング • オーナーのアプリが落ちた場 合 ◦ メモリ上のステートが失われる 43 オーナー ステート:X
メンバー ステート:B MultiGameServer ステート:B メンバー ステート:B メンバーリスト 消失の危機
ステート更新パターン ワールドのメッセージング • オーナーのアプリが落ちた場 合 ◦ 再接続時にサーバーからス テートが送信される 44 オーナー
ステート:B メンバー ステート:B MultiGameServer ステート:B メンバー ステート:B
ステート更新パターン ワールドのメッセージング • オーナーのアプリが落ちた場 合 ◦ サーバーに再接続時にサー バーからステートが送信される 45 オーナー
ステート:B メンバー ステート:B MultiGameServer ステート:B メンバー ステート:B メンバーリスト 消失の危機回避
ステート更新パターン ワールドのメッセージング • メリット ◦ 全てのメンバーが同じ状態を共有できる ▪ 競合状態にならない ◦ オーナーのアプリが落ちても情報が失われない
• デメリット ◦ オーナーが処理を行うのでレスポンスが悪い ◦ オーナーがいないと処理されない 46
ワールドのメッセージング • ステート更新パターン • ブロードキャストパターン 47
ブロードキャストパターン ワールドのメッセージング • アイテム装着の例 ◦ メンバーBがアイテムを装着す る場合 48 オーナー メンバーB
MultiGameServer メンバーA
ブロードキャストパターン ワールドのメッセージング • メンバーBが装着情報を ブロードキャストする 49 オーナー メンバーB MultiGameServer メンバーA
アイテムAを装着
ブロードキャストパターン ワールドのメッセージング • 装着情報を受け取ったメン バーは情報を更新する 50 オーナー メンバーB MultiGameServer メンバーA
メンバーBは アイテムA装着し ている
ブロードキャストパターン ワールドのメッセージング • 新しく視聴者が増えた場合 51 オーナー メンバーB MultiGameServer メンバーA メンバーBは
アイテムA装着し ている 視聴者C
ブロードキャストパターン ワールドのメッセージング • 新しく視聴者が増えた場合 52 オーナー メンバーB MultiGameServer メンバーA メンバーBは
アイテムA装着し ている 視聴者C メンバーBは なにも装着 していない
ブロードキャストパターン ワールドのメッセージング • 新しく視聴者が増えた場合 53 オーナー メンバーB MultiGameServer メンバーA メンバーBは
アイテムA装着し ている 視聴者C メンバーBは なにも装着 していない データ不整合
ブロードキャストパターン ワールドのメッセージング • 定期的に情報を再送信する 54 オーナー メンバーB MultiGameServer メンバーA 視聴者C
アイテムAを装着
ブロードキャストパターン ワールドのメッセージング • 装着情報を受け取ったメン バーは情報を更新する 55 オーナー メンバーB MultiGameServer メンバーA
視聴者C メンバーBは アイテムA装着し ている
ブロードキャストパターン ワールドのメッセージング • 装着情報を受け取ったメン バーは情報を更新する 56 オーナー メンバーB MultiGameServer メンバーA
視聴者C メンバーBは アイテムA装着し ている データ不整合解消
ブロードキャストパターン ワールドのメッセージング • メンバーBのアプリが落ちた場 合 57 オーナー メンバーB MultiGameServer メンバーA
視聴者C メンバーBは アイテムA装着し ている
ブロードキャストパターン ワールドのメッセージング • メンバーBのアプリが落ちた場 合 58 オーナー メンバーB MultiGameServer メンバーA
視聴者C メンバーBは アイテムA装着し ている メンバーBは なにも装着 していない
ブロードキャストパターン ワールドのメッセージング • メンバーBのアプリが落ちた場 合 59 オーナー メンバーB MultiGameServer メンバーA
視聴者C メンバーBは アイテムA装着し ている メンバーBは なにも装着 していない データ不整合?
ブロードキャストパターン ワールドのメッセージング • 定期的に情報を再送信する 60 オーナー メンバーB MultiGameServer メンバーA 視聴者C
装着なし
ブロードキャストパターン ワールドのメッセージング • 装着情報を受け取ったメン バーは情報を更新する 61 オーナー メンバーB MultiGameServer メンバーA
視聴者C メンバーBは なにも装着 していない
ブロードキャストパターン ワールドのメッセージング • 定期的に情報を再送信する 62 オーナー メンバーB MultiGameServer メンバーA 視聴者C
メンバーBは アイテムA装着し ている (情報は失われるが) データ不整合解消
ブロードキャストパターン ワールドのメッセージング • メリット ◦ オーナーを経由しないのでレスポンスが早い ◦ オーナーがいなくても情報を更新できる • デメリット
◦ データを定期的に送信する必要がある ◦ アプリが落ちると情報が失われる 63
位置同期 • ブロードキャストパターン ◦ オーナーが状態を管理しない • 定期的に現在の位置、入力の情報をブロードキャストする ◦ 変更がなければ送らない ◦
現在は100ms毎に送信する設定 • データが2つ溜まった時点で位置を予測する ◦ 他のユーザーからは少し遅れて見える 64
メッセージのシリアライズ/デシリアライズ • シリアライズ/デシリアライズにはProtocol buffersを使用 ◦ Googleが開発 ◦ IDLで構造を定義してコードの自動生成ができる ◦ バイナリ形式で出力できる
65
メッセージのシリアライズ/デシリアライズ 66 message WorldAvatarSyncData { int32 timestamp = 1; Habanero.ProtobufVector3
position = 2; Habanero.ProtobufVector3 rotationEuler = 3; Habanero.ProtobufVector2 velocity = 4; int32 motionState = 5; bool startEntryMotion = 6; bool startExitMotion = 7; } サンプル
Protocol buffersのメリットデメリット メッセージのシリアライズ/デシリアライズ • メリット ◦ テキスト形式のJSONよりサイズが小さくなる ◦ 互換性を保ったまま拡張できる ◦
Dictionary(Map)が使える • デメリット ◦ 定義が面倒 ◦ ヒューマンリーダブルではない 67
Protocol buffersのメリットデメリット メッセージのシリアライズ/デシリアライズ • メリット ◦ テキスト形式のJSONよりサイズが小さくなる ◦ 互換性を保ったまま拡張できる ◦
Dictionary(Map)が使える • デメリット ◦ 定義が面倒 ◦ ヒューマンリーダブルではない 68 キー名などの情報が ない 値がバイナリ
Protocol buffersのメリットデメリット メッセージのシリアライズ/デシリアライズ • メリット ◦ テキスト形式のJSONよりサイズが小さくなる ◦ 互換性を保ったまま拡張できる ◦
Dictionary(Map)が使える • デメリット ◦ 定義が面倒 ◦ ヒューマンリーダブルではない 69 重要なので後述
Protocol buffersのメリットデメリット メッセージのシリアライズ/デシリアライズ • メリット ◦ テキスト形式のJSONよりサイズが小さくなる ◦ 互換性を保ったまま拡張できる ◦
Dictionary(Map)が使える • デメリット ◦ 定義が面倒 ◦ ヒューマンリーダブルではない 70 Unity標準のJSONシ リアライザでは使えな い
Protocol buffersのメリットデメリット メッセージのシリアライズ/デシリアライズ • メリット ◦ テキスト形式のJSONよりサイズが小さくなる ◦ 互換性を保ったまま拡張できる ◦
Dictionary(Map)が使える • デメリット ◦ 定義が面倒 ◦ ヒューマンリーダブルではない 71 IDLを書いてコード生 成しないといけないの で少し手間 開発初期はJSONを 使う、生成のフロー整 備でましになる
Protocol buffersのメリットデメリット メッセージのシリアライズ/デシリアライズ • メリット ◦ テキスト形式のJSONよりサイズが小さくなる ◦ 互換性を保ったまま拡張できる ◦
Dictionary(Map)が使える • デメリット ◦ 定義が面倒 ◦ ヒューマンリーダブルではない 72 データがテキストでは ないのでどんな値か 分かりにくい
互換性の話 メッセージのシリアライズ/デシリアライズ • 配信者と視聴者で別のバージョンのアプリを使用している可能性 がある ◦ 古いバージョンと新しいバージョン の組み合わせでも動作する必要がある 73 配信者
バージョン: 1.1 視聴者 バージョン: 1.0 MultiGameServer
Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • field名の変更ができる • fieldの追加ができる 74
Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • field名の変更ができる • fieldの追加ができる 75
Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • field名の変更ができる 76 message SampleMessage { int32
hoga = 1; } { "hoga": 999 } Protobuf JSON
Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • field名の変更ができる 77 message SampleMessage { int32
hoga = 1; } { "hoga": 999 } Protobuf JSON hogeにしたいのにhogaにしてしまった!
Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • field名の変更ができる 78 message SampleMessage { int32
hoge = 1; } { "hoga": 999 } Protobuf JSON データにはフィールド名が含まれず、 フィールド番号のみ含まれるので変更が可能
Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • field名の変更ができる 79 message SampleMessage { int32
hoge = 1; } { "hoga": 999 } Protobuf JSON フィールド名がデータに含まれるので変更すると 古いバージョンのアプリで読み込めなくなる
Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • field名の変更ができる • fieldの追加ができる 80
Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • fieldの追加ができる 81 message SampleMessage { int32
hoga = 1; } Protobuf
Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • fieldの追加ができる 82 message SampleMessage { int32
hoga = 1; int32 fuga = 2; } Protobuf fieldを追加できる 古いバージョンのアプリでは無 視される
Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • fieldの追加ができる 83 message SampleMessage { int32
hoga = 1; int32 fuga = 2; } Protobuf 独自バイナリフォーマットを採 用するとこれができない可能性 がある
新規ワールドの開発 84
新規ワールドの開発 • 既存機能のみを使用する場合はアセットの更新のみで新規ワール ドを作成可能 ◦ アプリのアップデートなしで新規ワールドをリリース可能 ◦ アセット側でワールドの細かい挙動を制御できるようになっている • アセットで制御できる例
◦ アバターの出現位置 ◦ ギフトの出現位置 ◦ 装着アイテムの制御情報 ◦ etc 85
アバターの出現位置 新規ワールドの開発 86
アバターの出現位置 新規ワールドの開発 87 ワールド起動時に この付近に アバターが出現
ギフトの出現位置 新規ワールドの開発 88
ギフトの出現位置 新規ワールドの開発 89 机の上に視聴者から 送られたギフトが 出現
装着アイテムの装着情報 新規ワールドの開発 90
プロップの装着情報 新規ワールドの開発 91 デバッグ情報
プロップの装着情報 新規ワールドの開発 92 装着情報 • アニメーションあ り/なし • どこに装着するか •
アイコン
新規機能の開発 • 既存の機能で実現不可能な場合は新規機能を実装する • 4周年記念ワールドで新規実装した機能 ◦ ワールド内視聴者登場機能 ◦ 座る機能 ◦
動画配信視聴機能 ◦ アニメーション同期機能 ◦ etc 93
新規機能の開発 • 新規機能を実装する際は互換性を注意する ◦ 新規ワールドをリリースした時に古いアプリで既存のワールドが遊べなくな ることは避ける 94
新規機能の開発 • 新規機能を実装する際は互換性を注意する 95
新規機能の開発 • 新規機能を実装する際は互換性を注意する 96 既存ワールド 新アプリのリリース後 でも古いアプリでも遊 べる
新規機能の開発 • 新規機能を実装する際は互換性を注意する 97 新規機能を実装した ワールド 新しいアプリでしか遊 べない
新規機能の開発 • 古いアプリで新規機能を使用する ワールドを起動する場合 ◦ バージョンガード機能で起動を防ぐ ▪ Webから最低起動バージョンを 指定することができる 98
新規機能の開発 • バージョンガードTips ◦ アプリリリース後すぐはアップデートしてない人がいる ▪ 基本的にREALITYは月曜にアプリリリース、水曜にワールドリリース ◦ 新規機能を必要なワールドをリリースする前に 余裕をもって対応バージョンのアプリをリリースしておく
99
新規ワールドのリリースフロー 100
新規ワールドのリリースフロー • 企画 • アセット作成 • アセットの配置 • ワールドの公開 101
新規ワールドのリリースフロー • 企画 • アセット作成 • アセットの配置 • ワールドの公開 102
企画 • どのようなワールドを作成するか • 作成するワールドのイメージを作成 ◦ 構成や雰囲気がわかるもの 103 桜ワールド初期構成案
新規ワールドのリリースフロー • 企画 • アセット作成 • アセットの配置 • ワールドの公開 104
アセットの作成 • アセットの仮作成 • アセットの本作成 105
アセットの作成 • アセットの仮作成 • アセットの本作成 106
アセットの仮作成 アセットの作成 • ワールドのレベルデザインが確認できる状態 ◦ 歩ける状態 • 企画とワールドの方針を確認する 107
アセットの仮作成 アセットの作成 108
アセットの作成 • アセットの仮作成 • アセットの本作成 109
アセットの本作成 アセットの作成 • 本番で使用するアセットを作成する • 完成したアセットは開発用リポジトリにpushする 110
アセットの本作成 アセットの作成 111
新規ワールドのリリースフロー • 企画 • アセット作成 • アセットの配置 • ワールドの公開 112
アセットの配置 • 完成したアセットをビルドしてAssetBundleにする • ビルドしたAssetBundleの情報をサーバーに登録 ◦ AssetBundleのメタ情報を管理サーバーに登録 • ビルドしたAssetBundleをGCSに配置する ◦
この段階ではまだアプリからアクセスできない 113
アセットの配置 • Jenkinsで自動化 ◦ iOS/Androidビルド ◦ サーバーに登録 ◦ GCSに配置 114
新規ワールドのリリースフロー • 企画 • アセット作成 • アセットの配置 • ワールドの公開 115
ワールドの公開 • ワールドの公開設定を行う • AssetBundle公開設定を行う 116
ワールドの公開 • ワールドの公開設定を行う • AssetBundle公開設定を行う 117
ワールドの公開 • ワールドの公開設定を行う ◦ ゲーム一覧に表示されるようにする ◦ Webから設定する 118
ワールドの公開 • ワールドの公開設定を行う 119
ワールドの公開 • ワールドの公開設定を行う • AssetBundle公開設定を行う 120
ワールドの公開 • AssetBundle公開設定を行う ◦ アプリからAssetBundleがダウンロードできるようになる ◦ Webから設定する 121
ワールドの公開 • AssetBundle公開設定を行う 122
まとめ 123
まとめ • REALITYがなぜ”人がいるメタバース”なのか ◦ 配信と融合したワールド ◦ 全世界の人と遊べる • ワールドの実装方式 ◦
現状はシンプルな実装 ◦ 今後さらに拡張予定 124
お知らせ 125
126