"人がいるメタバース" を実現するREALITYのワールド機能

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

Transcript

1. REALITY株式会社　クライアントエンジニア　三宅広大 "人がいるメタバース" を実現する REALITYのワールド機能
2. • 三宅広大/yaegaki • 2020年 REALITY株式会社 入社 • Unityエンジニア/テックリード • アバター関連 • ビデオ通話 • ワールド • etc 自己紹介 2

3. REALITYについて 3

4. スマホひとつでアバター作成、ライブ配信による交流やゲームまで楽しめるメタバース REALITYについて 4
 アバター
 ライブ配信
 コミュニケーション
 ゲーム
 ワールド

5. REALITYについて 5

6. REALITYについて 6

7. スマホひとつでアバター作成、ライブ配信による交流やゲームまで楽しめるメタバース REALITYについて 7
 アバター
 ライブ配信
 コミュニケーション
 ゲーム
 ワールド

8. ワールドについて 8

9. 9
 ワールドの概要
10. ワールドの概要 10

11. ワールドの機能(特徴) まとめ • REALITYアバターで最大8人で遊べる仮想空間 • 座る機能 • アイテム装着 • 動画配信視聴 • etc 11

12. ワールドの機能(特徴) まとめ • REALITYアバターで最大8人で遊べる仮想空間 • 座る機能 • アイテム装着 • 動画配信視聴 • etc 12

13. ワールドの機能(特徴) まとめ • REALITYアバターで最大8人で遊べる仮想空間 • 座る機能 • アイテム装着 • 動画配信視聴 • etc 13

14. 動画配信視聴 • ワールド内に設置したスクリーンで動画を再生する機能 • HLS(HTTP Live Streaming)を用いたライブストリーミング視聴 にも対応 ◦ ワールドにいる人と一緒に視聴できる • タイムテーブルを用いた動画再生機能 ◦ ライブストリーミングと静的なファイルによるCMを切り替え可能 14

15. 動画配信視聴 15

16. 動画配信視聴 16
 ここがスクリーンに なっていて映像が流 れる
17. ワールドの機能(特徴) まとめ • REALITYアバターで最大8人で遊べる仮想空間 • 座る機能 • アイテム装着 • 動画配信視聴 • etc 17

18. その他機能 • テーマ機能 ◦ 同じワールドで見た目が変わる • アニメーション同期機能 ◦ オブジェクトのアニメーション再生時間を同期する • オブジェクト状態同期機能 ◦ オブジェクトの任意のデータを同期する • SE再生機能 ◦ 特定のタイミングでSEを再生する機能 18

19. ”人がいるメタバース”としてのワールド • 配信とシームレスに繋がっている ◦ 誰かと遊びたかったら配信を開けば”人”がいる • トライアルでは延べ来場者数が400万人*を超える ◦ ”箱”をつくっても”人”がいないを解決 • 世界中のREALITYユーザーに展開が可能 • さまざまな種類のワールドをリリース 19
 *：2022年4月22日～2022年6月12日　自社調べ
20. 桜ワールド これまでにリリースしたワールド 20

21. ミュージックフェスワールド これまでにリリースしたワールド 21

22. 4周年記念ワールド これまでにリリースしたワールド 22

23. これまでにリリースしたワールド 23

24. コラボワールド これまでにリリースしたワールド • 他社様とのコラボワールドを複数リリース 24

25. ワールドの実装 25

26. ワールドの登場人物(ロール) • オーナー ◦ ワールドを起動した配信者 • コラボゲスト ◦ 配信にコラボゲストとして参加しているユーザー • ビジター ◦ 視聴者の内、ワールドに参加しているユーザー ◦ 早い者勝ちで視聴者がワールド内視聴者になる • 視聴者 ◦ ワールドには参加せず視聴だけしているユーザー 26

27. ワールドの登場人物(ロール) • オーナー • コラボゲスト • ビジター • 視聴者 27
 ワールド内にアバターが出現して 動き回れるユーザー 全てをまとめてメンバーと呼ぶ 合計で8人まで
28. ワールドの登場人物(ロール) • オーナー • コラボゲスト • ビジター • 視聴者 28
 配信を見ているだけのユーザー ワールドにアバターが登場せず オーナーと同じ視点になる
29. ワールドの登場人物(ロール) 29
 オーナー コラボゲスト ビジター 視聴者
30. ワールドの登場人物(ロール) 30
 オーナー コラボゲスト ビジター 視聴者 アバターが登場 音声通話可能
31. ワールドの登場人物(ロール) 31
 オーナー コラボゲスト ビジター 視聴者 アバターが登場のみ
32. ワールドの登場人物(ロール) 32
 オーナー コラボゲスト ビジター 視聴者 自分のアバターが 登場しない オーナーと同じ視点
33. ネットワークミドルウェア • 外部ミドルウェアは使用せず独自実装 • WebSocketを用いたリアルタイム通信 • サーバー側はパケットのリレーとステートの保存を行う ◦ ワールドのロジックを持たない 33

34. ワールドのメッセージング • ワールドでの出来事を全ユーザーに共有する方法 ◦ ステート更新パターン ◦ ブロードキャストパターン 34

35. ワールドのメッセージング • ステート更新パターン • ブロードキャストパターン 35

36. ステート更新パターン ワールドのメッセージング • 視聴者のワールド参加の例 ◦ 初めは全てのクライアントは同 じステートを共有している ◦ ステートには参加しているメン バーの情報が保存されている 36
 オーナー ステート:A 視聴者 ステート:A MultiGameServer ステート:A メンバー ステート:A
37. ステート更新パターン ワールドのメッセージング • オーナーにワールド参加を要 求する 37
 オーナー ステート:A 視聴者 ステート:A MultiGameServer ステート:A メンバー ステート:A
38. ステート更新パターン ワールドのメッセージング • 要求が正しければメンバーリ ストを更新する 38
 オーナー ステート:B 視聴者 ステート:A MultiGameServer ステート:A メンバー ステート:A
39. ステート更新パターン ワールドのメッセージング • オーナーがサーバーにステー トを登録する 39
 オーナー ステート:B 視聴者 ステート:A MultiGameServer ステート:B メンバー ステート:A
40. ステート更新パターン ワールドのメッセージング • サーバーがオーナー以外にス テートを送信する 40
 オーナー ステート:B 視聴者 ステート:B MultiGameServer ステート:B メンバー ステート:B
41. ステート更新パターン ワールドのメッセージング • ステートの情報を用いて更新 する ◦ 視聴者が無事メンバーになる 41
 オーナー ステート:B メンバー ステート:B MultiGameServer ステート:B メンバー ステート:B
42. ステート更新パターン ワールドのメッセージング • オーナーのアプリが落ちた場 合 ◦ メモリ上のステートが失われる 42
 オーナー ステート:X メンバー ステート:B MultiGameServer ステート:B メンバー ステート:B
43. ステート更新パターン ワールドのメッセージング • オーナーのアプリが落ちた場 合 ◦ メモリ上のステートが失われる 43
 オーナー ステート:X メンバー ステート:B MultiGameServer ステート:B メンバー ステート:B メンバーリスト 消失の危機
44. ステート更新パターン ワールドのメッセージング • オーナーのアプリが落ちた場 合 ◦ 再接続時にサーバーからス テートが送信される 44
 オーナー ステート:B メンバー ステート:B MultiGameServer ステート:B メンバー ステート:B
45. ステート更新パターン ワールドのメッセージング • オーナーのアプリが落ちた場 合 ◦ サーバーに再接続時にサー バーからステートが送信される 45
 オーナー ステート:B メンバー ステート:B MultiGameServer ステート:B メンバー ステート:B メンバーリスト 消失の危機回避
46. ステート更新パターン ワールドのメッセージング • メリット ◦ 全てのメンバーが同じ状態を共有できる ▪ 競合状態にならない ◦ オーナーのアプリが落ちても情報が失われない • デメリット ◦ オーナーが処理を行うのでレスポンスが悪い ◦ オーナーがいないと処理されない 46

47. ワールドのメッセージング • ステート更新パターン • ブロードキャストパターン 47

48. ブロードキャストパターン ワールドのメッセージング • アイテム装着の例 ◦ メンバーBがアイテムを装着す る場合 48
 オーナー メンバーB MultiGameServer メンバーA
49. ブロードキャストパターン ワールドのメッセージング • メンバーBが装着情報を ブロードキャストする 49
 オーナー メンバーB MultiGameServer メンバーA アイテムAを装着
50. ブロードキャストパターン ワールドのメッセージング • 装着情報を受け取ったメン バーは情報を更新する 50
 オーナー メンバーB MultiGameServer メンバーA メンバーBは アイテムA装着し ている
51. ブロードキャストパターン ワールドのメッセージング • 新しく視聴者が増えた場合 51
 オーナー メンバーB MultiGameServer メンバーA メンバーBは アイテムA装着し ている 視聴者C
52. ブロードキャストパターン ワールドのメッセージング • 新しく視聴者が増えた場合 52
 オーナー メンバーB MultiGameServer メンバーA メンバーBは アイテムA装着し ている 視聴者C メンバーBは なにも装着 していない
53. ブロードキャストパターン ワールドのメッセージング • 新しく視聴者が増えた場合 53
 オーナー メンバーB MultiGameServer メンバーA メンバーBは アイテムA装着し ている 視聴者C メンバーBは なにも装着 していない データ不整合
54. ブロードキャストパターン ワールドのメッセージング • 定期的に情報を再送信する 54
 オーナー メンバーB MultiGameServer メンバーA 視聴者C アイテムAを装着
55. ブロードキャストパターン ワールドのメッセージング • 装着情報を受け取ったメン バーは情報を更新する 55
 オーナー メンバーB MultiGameServer メンバーA 視聴者C メンバーBは アイテムA装着し ている
56. ブロードキャストパターン ワールドのメッセージング • 装着情報を受け取ったメン バーは情報を更新する 56
 オーナー メンバーB MultiGameServer メンバーA 視聴者C メンバーBは アイテムA装着し ている データ不整合解消
57. ブロードキャストパターン ワールドのメッセージング • メンバーBのアプリが落ちた場 合 57
 オーナー メンバーB MultiGameServer メンバーA 視聴者C メンバーBは アイテムA装着し ている
58. ブロードキャストパターン ワールドのメッセージング • メンバーBのアプリが落ちた場 合 58
 オーナー メンバーB MultiGameServer メンバーA 視聴者C メンバーBは アイテムA装着し ている メンバーBは なにも装着 していない
59. ブロードキャストパターン ワールドのメッセージング • メンバーBのアプリが落ちた場 合 59
 オーナー メンバーB MultiGameServer メンバーA 視聴者C メンバーBは アイテムA装着し ている メンバーBは なにも装着 していない データ不整合?
60. ブロードキャストパターン ワールドのメッセージング • 定期的に情報を再送信する 60
 オーナー メンバーB MultiGameServer メンバーA 視聴者C 装着なし
61. ブロードキャストパターン ワールドのメッセージング • 装着情報を受け取ったメン バーは情報を更新する 61
 オーナー メンバーB MultiGameServer メンバーA 視聴者C メンバーBは なにも装着 していない
62. ブロードキャストパターン ワールドのメッセージング • 定期的に情報を再送信する 62
 オーナー メンバーB MultiGameServer メンバーA 視聴者C メンバーBは アイテムA装着し ている (情報は失われるが) データ不整合解消
63. ブロードキャストパターン ワールドのメッセージング • メリット ◦ オーナーを経由しないのでレスポンスが早い ◦ オーナーがいなくても情報を更新できる • デメリット ◦ データを定期的に送信する必要がある ◦ アプリが落ちると情報が失われる 63

64. 位置同期 • ブロードキャストパターン ◦ オーナーが状態を管理しない • 定期的に現在の位置、入力の情報をブロードキャストする ◦ 変更がなければ送らない ◦ 現在は100ms毎に送信する設定 • データが2つ溜まった時点で位置を予測する ◦ 他のユーザーからは少し遅れて見える 64

65. メッセージのシリアライズ/デシリアライズ • シリアライズ/デシリアライズにはProtocol buffersを使用 ◦ Googleが開発 ◦ IDLで構造を定義してコードの自動生成ができる ◦ バイナリ形式で出力できる 65

66. メッセージのシリアライズ/デシリアライズ 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; } サンプル
67. Protocol buffersのメリットデメリット メッセージのシリアライズ/デシリアライズ • メリット ◦ テキスト形式のJSONよりサイズが小さくなる ◦ 互換性を保ったまま拡張できる ◦ Dictionary(Map)が使える • デメリット ◦ 定義が面倒 ◦ ヒューマンリーダブルではない 67

68. Protocol buffersのメリットデメリット メッセージのシリアライズ/デシリアライズ • メリット ◦ テキスト形式のJSONよりサイズが小さくなる ◦ 互換性を保ったまま拡張できる ◦ Dictionary(Map)が使える • デメリット ◦ 定義が面倒 ◦ ヒューマンリーダブルではない 68
 キー名などの情報が ない 値がバイナリ
69. Protocol buffersのメリットデメリット メッセージのシリアライズ/デシリアライズ • メリット ◦ テキスト形式のJSONよりサイズが小さくなる ◦ 互換性を保ったまま拡張できる ◦ Dictionary(Map)が使える • デメリット ◦ 定義が面倒 ◦ ヒューマンリーダブルではない 69
 重要なので後述
70. Protocol buffersのメリットデメリット メッセージのシリアライズ/デシリアライズ • メリット ◦ テキスト形式のJSONよりサイズが小さくなる ◦ 互換性を保ったまま拡張できる ◦ Dictionary(Map)が使える • デメリット ◦ 定義が面倒 ◦ ヒューマンリーダブルではない 70
 Unity標準のJSONシ リアライザでは使えな い
71. Protocol buffersのメリットデメリット メッセージのシリアライズ/デシリアライズ • メリット ◦ テキスト形式のJSONよりサイズが小さくなる ◦ 互換性を保ったまま拡張できる ◦ Dictionary(Map)が使える • デメリット ◦ 定義が面倒 ◦ ヒューマンリーダブルではない 71
 IDLを書いてコード生 成しないといけないの で少し手間 開発初期はJSONを 使う、生成のフロー整 備でましになる
72. Protocol buffersのメリットデメリット メッセージのシリアライズ/デシリアライズ • メリット ◦ テキスト形式のJSONよりサイズが小さくなる ◦ 互換性を保ったまま拡張できる ◦ Dictionary(Map)が使える • デメリット ◦ 定義が面倒 ◦ ヒューマンリーダブルではない 72
 データがテキストでは ないのでどんな値か 分かりにくい
73. 互換性の話 メッセージのシリアライズ/デシリアライズ • 配信者と視聴者で別のバージョンのアプリを使用している可能性 がある ◦ 古いバージョンと新しいバージョン の組み合わせでも動作する必要がある 73
 配信者 バージョン: 1.1 視聴者 バージョン: 1.0 MultiGameServer
74. Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • field名の変更ができる • fieldの追加ができる 74

75. Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • field名の変更ができる • fieldの追加ができる 75

76. Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • field名の変更ができる 76
 message SampleMessage { int32 hoga = 1; } { "hoga": 999 } Protobuf JSON
77. Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • field名の変更ができる 77
 message SampleMessage { int32 hoga = 1; } { "hoga": 999 } Protobuf JSON hogeにしたいのにhogaにしてしまった！
78. Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • field名の変更ができる 78
 message SampleMessage { int32 hoge = 1; } { "hoga": 999 } Protobuf JSON データにはフィールド名が含まれず、 フィールド番号のみ含まれるので変更が可能
79. Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • field名の変更ができる 79
 message SampleMessage { int32 hoge = 1; } { "hoga": 999 } Protobuf JSON フィールド名がデータに含まれるので変更すると 古いバージョンのアプリで読み込めなくなる
80. Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • field名の変更ができる • fieldの追加ができる 80

81. Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • fieldの追加ができる 81
 message SampleMessage { int32 hoga = 1; } Protobuf
82. Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • fieldの追加ができる 82
 message SampleMessage { int32 hoga = 1; int32 fuga = 2; } Protobuf fieldを追加できる 古いバージョンのアプリでは無 視される
83. Protocol buffersの互換性 メッセージのシリアライズ/デシリアライズ • fieldの追加ができる 83
 message SampleMessage { int32 hoga = 1; int32 fuga = 2; } Protobuf 独自バイナリフォーマットを採 用するとこれができない可能性 がある
84. 新規ワールドの開発 84

85. 新規ワールドの開発 • 既存機能のみを使用する場合はアセットの更新のみで新規ワール ドを作成可能 ◦ アプリのアップデートなしで新規ワールドをリリース可能 ◦ アセット側でワールドの細かい挙動を制御できるようになっている • アセットで制御できる例 ◦ アバターの出現位置 ◦ ギフトの出現位置 ◦ 装着アイテムの制御情報 ◦ etc 85

86. アバターの出現位置 新規ワールドの開発 86

87. アバターの出現位置 新規ワールドの開発 87
 ワールド起動時に この付近に アバターが出現
88. ギフトの出現位置 新規ワールドの開発 88

89. ギフトの出現位置 新規ワールドの開発 89
 机の上に視聴者から 送られたギフトが 出現
90. 装着アイテムの装着情報 新規ワールドの開発 90

91. プロップの装着情報 新規ワールドの開発 91
 デバッグ情報
92. プロップの装着情報 新規ワールドの開発 92
 装着情報 • アニメーションあ り/なし • どこに装着するか • アイコン
93. 新規機能の開発 • 既存の機能で実現不可能な場合は新規機能を実装する • 4周年記念ワールドで新規実装した機能 ◦ ワールド内視聴者登場機能 ◦ 座る機能 ◦ 動画配信視聴機能 ◦ アニメーション同期機能 ◦ etc 93

94. 新規機能の開発 • 新規機能を実装する際は互換性を注意する ◦ 新規ワールドをリリースした時に古いアプリで既存のワールドが遊べなくな ることは避ける 94

95. 新規機能の開発 • 新規機能を実装する際は互換性を注意する 95

96. 新規機能の開発 • 新規機能を実装する際は互換性を注意する 96
 既存ワールド 新アプリのリリース後 でも古いアプリでも遊 べる
97. 新規機能の開発 • 新規機能を実装する際は互換性を注意する 97
 新規機能を実装した ワールド 新しいアプリでしか遊 べない
98. 新規機能の開発 • 古いアプリで新規機能を使用する ワールドを起動する場合 ◦ バージョンガード機能で起動を防ぐ ▪ Webから最低起動バージョンを 指定することができる 98

99. 新規機能の開発 • バージョンガードTips ◦ アプリリリース後すぐはアップデートしてない人がいる ▪ 基本的にREALITYは月曜にアプリリリース、水曜にワールドリリース ◦ 新規機能を必要なワールドをリリースする前に 余裕をもって対応バージョンのアプリをリリースしておく 99

100. 新規ワールドのリリースフロー 100

101. 新規ワールドのリリースフロー • 企画 • アセット作成 • アセットの配置 • ワールドの公開 101

102. 新規ワールドのリリースフロー • 企画 • アセット作成 • アセットの配置 • ワールドの公開 102

103. 企画 • どのようなワールドを作成するか • 作成するワールドのイメージを作成 ◦ 構成や雰囲気がわかるもの 103
 桜ワールド初期構成案
104. 新規ワールドのリリースフロー • 企画 • アセット作成 • アセットの配置 • ワールドの公開 104

105. アセットの作成 • アセットの仮作成 • アセットの本作成 105

106. アセットの作成 • アセットの仮作成 • アセットの本作成 106

107. アセットの仮作成 アセットの作成 • ワールドのレベルデザインが確認できる状態 ◦ 歩ける状態 • 企画とワールドの方針を確認する 107

108. アセットの仮作成 アセットの作成 108

109. アセットの作成 • アセットの仮作成 • アセットの本作成 109

110. アセットの本作成 アセットの作成 • 本番で使用するアセットを作成する • 完成したアセットは開発用リポジトリにpushする 110

111. アセットの本作成 アセットの作成 111

112. 新規ワールドのリリースフロー • 企画 • アセット作成 • アセットの配置 • ワールドの公開 112

113. アセットの配置 • 完成したアセットをビルドしてAssetBundleにする • ビルドしたAssetBundleの情報をサーバーに登録 ◦ AssetBundleのメタ情報を管理サーバーに登録 • ビルドしたAssetBundleをGCSに配置する ◦ この段階ではまだアプリからアクセスできない 113

114. アセットの配置 • Jenkinsで自動化 ◦ iOS/Androidビルド ◦ サーバーに登録 ◦ GCSに配置 114

115. 新規ワールドのリリースフロー • 企画 • アセット作成 • アセットの配置 • ワールドの公開 115

116. ワールドの公開 • ワールドの公開設定を行う • AssetBundle公開設定を行う 116

117. ワールドの公開 • ワールドの公開設定を行う • AssetBundle公開設定を行う 117

118. ワールドの公開 • ワールドの公開設定を行う ◦ ゲーム一覧に表示されるようにする ◦ Webから設定する 118

119. ワールドの公開 • ワールドの公開設定を行う 119

120. ワールドの公開 • ワールドの公開設定を行う • AssetBundle公開設定を行う 120

121. ワールドの公開 • AssetBundle公開設定を行う ◦ アプリからAssetBundleがダウンロードできるようになる ◦ Webから設定する 121

122. ワールドの公開 • AssetBundle公開設定を行う 122

123. まとめ 123

124. まとめ • REALITYがなぜ”人がいるメタバース”なのか ◦ 配信と融合したワールド ◦ 全世界の人と遊べる • ワールドの実装方式 ◦ 現状はシンプルな実装 ◦ 今後さらに拡張予定 124

125. お知らせ 125