メタバースにおけるリアルタイム通信入門

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

Transcript

1. REALITY株式会社　エンジニアマネージャー　髙橋 悠 メタバースにおける リアルタイム通信入門 REALITY株式会社　ソフトウェアエンジニア　古屋 研太
2. • 所属 • REALITY株式会社 • 担当 • エンジニアマネージャー • 経歴 • 2006年 モバイルゲーム会社、新卒入社 • 2018年 グリー株式会社、中途入社 • 2018年 株式会社Wright Flyer Live Entertainment （現REALITY株式会社）出向 自己紹介 2
 髙橋 悠(たかはし ゆたか)
3. • 所属 • REALITY株式会社 • 担当 • ソフトウェアエンジニア • 経歴 • ゲーム会社に新卒入社　VRチームに所属 • フリーランス (VRアプリやVtuber向けシステム開発など) • 2022年5月にREALITYに入社 自己紹介 3
 古屋 研太(ふるや けんた)
4. XR cloud 事業部について https://reality.inc/products/realityxrcloud/ 4
 • REALITY XR cloudとは • あらゆる仮想空間内で行われる バーチャルイベントを実現するためのクラウドソリューションです 有識者によるコンサルティング、累計1,000万DLのプラットフォーム活用、複雑にカスタ マイズが可能な開発エンジン利用、各社とのパートナーシップ等を活かして、法人様向け のメタバースを実現可能にします REALITY World REALITY Spaces
5. 昨年公開したメタバースのトレーラー動画 https://youtu.be/ktMNqFuW6uQ 5

6. 最初に採用したソリューション 6
 • Photon(PUN2) ◦ https://www.photonengine.com/ja-JP/PUN ◦ ドイツのExit Games GmbHが開発・運営している世界中で利用されて いるネットワークエンジン • 採用理由 ◦ メジャーなマルチプレイヤーエンジンで採用実績も開発情報も豊富にある
7. 最初に採用したソリューション 7
 • Vivox ◦ https://unity.com/ja/products/vivox ◦ Unityから提供されているチャットSDK ▪ テキストチャット、ボイスチャットが行える • 採用理由 ◦ 数多くの大型タイトルで採用されている ◦ 2019年にUnityが買収し、公式が提供するソリューションとなった
8. Photon(PUN2)で直面した課題 8
 • メッセージ数の制約 ◦ 1秒当たり500メッセージまでが推奨されており、やり取りできる情報量が 比較的少ない ◦ ただし、補間をすることはできるのである程度カバーできる • 世代交代 ◦ 2022年3月にPhoton Fusionという新しいソリューションがリリースされ、 PUN2自身はメンテナンスモード（新機能が追加されない）となった Photon Fusionへの切り替えが推奨されている 同時接続数を増やすことが難しい
9. Vivox で直面した課題 9
 • ネットワーク環境 ◦ オフィスなどの堅実なネットワーク環境では使用できないケースがある ◦ バーチャルオフィスを開発する際、個人宅で問題なく動作するがオフィスや VPNに接続した状態では動かなくなるということがあった ◦ ※Photonでも同様の現象は発生するが、使用するプロトコルやポートを 変更することが出来たので比較的容易に対応することが出来る
10. 10
 何とかしたい！
11. 11
 • 同時接続数 ◦ もっと沢山の人がルームに入れるようにしたい ◦ でもボイスチャットも必要 • VPN等の特殊な接続環境の問題 ◦ Vivoxは別サーバーで設定できることが少ない 最初に採用したソリューションの課題
12. 12
 Tickレートを15, 100人同時接続, 座標と回転を※20byte程度として試算 受信 座標 : 15 x 100人 = 0.24Mbps 送信 座標 : 15 x 100人 x 99人 = 24Mbps サーバー側でパケットを理想的に結合したら送信は1/50のパケットにできるが… 　　　　　　移動だけでこれだけ使ってしまっては他になにもできないのでは？ 大規模の接続時のデータ試算 アバター座標の同期 100人 24 M bps 200人 (x2) 96 M bps 400人 (x4) 384 M bps ※座標をfloat x 3, 　回転を6bitにQuaternionを圧縮
13. 13
 従量課金のAWSやGCPの場合 平均100Mbps を24時間 動かす => 約1TB AWSであれば 1日1.5万以上…？　200人程度を捌くコストとして高すぎる…？ 転送量制限のあるVPSの場合 低コストでルームサーバーを動かすのであれば検討したい 多くのVPSでは 月の転送量上限が数TB の料金プランが多い 数日動いたら転送量上限に引っかかってしまう… 大規模の接続時のデータ試算 転送量制限や従量課金への影響 単純なデータ送信の仕組みではコスト的にも厳しい
14. 14
 PUN2 での限界 • 座標の同期ですらTickレート15でも6人程度で5x6x15=450になってしまう Broadcast処理では結合してくれるかもしれないがそれでも少なすぎる • 更新頻度を落とせば人数を増やせるものの、アクション要素をワールドに入れたくても できなかったり、VRだと低いTickレートでは体験の質がかなり落ちる 秒間パケット数上限 (1ルームあたり約500packet/秒を推奨 ) サーバー側の制御を実装できない • 前述の見積から考えても、サーバー側で送るデータを工夫する必要がある • サーバー側でアバター間の距離に応じてデータを節約するような処理を実装したいが、単純な リレーサーバーやP2P接続では困難 • チート対策とかもやりにくい
15. 15
 PUN2 での限界 • ホストに様々な処理が集中してしまう 物理演算、 整合性を取らないといけない判定処理 etc… ホストへの負荷の集中 • 上記のようにホストが正として管理しないといけない実装がある場合、切断時の引継ぎなどは工夫 しないといけない • たとえ引継ぎができたとしても、全員が退出してしまうとルーム内の情報を保持することができない ホストの切断時の対応 / ルーム情報の保持の難しさ
16. 16
 単純なリレーサーバーでは限界 独自実装のサーバーが必要そうだがハードルが… • サーバー側の実装が難しそう • 送信データを減らす仕組みが難しそう
17. 17
 手軽に使えるネットワークライブラリ FishNet そこで
18. 18
 FishNetのメリット • [ServerRpc]などの属性をつけるだけでリモートのメソッドを実行できる • Mono.cecilでC#の中間言語を操作するのでGCやboxingを避けつつパケットを作成できる • uNETと比べて設定できる引数が豊富 コード生成で簡単かつ高速なリモートプロシージャルコールができる • Linux向けにHeadlessビルドをすればGCPやAWS上でも動かすことができる • C#でサーバー側の実装をそのまま記述したり、sceneのオブジェクト情報をそのまま持てるので物 理演算や当たり判定をサーバー側で簡単に処理できる HeadlessサーバービルドでUnity C#でサーバー実装できる
19. 19
 FishNetのメリット • 通信をUDPだけではなくWebsocketなど他のプロトコルに差し替えることができる Transport レイヤーを自由に変更できる • オブジェクトの変数を自動で同期する仕組み • 値の変更時だけでなく、途中接続のクライアントにも自動で同期してくれる 再接続 / 途中接続時の同期が比較的容易 • オブジェクトの距離やsceneを元に送信するデータを制限できる AOI(関心領域システムがある) 詳しくは後述
20. 20
 おまけ　手軽なサーバーホスティングサービス • 無料で30分だけ動かせるサーバーをお試しで使える • StoreでダウンロードしEditorWindowからビルドして サーバーにHeadlessビルドをデプロイ可能 • VPSをレンタルするのとそこまで変わらない月額費用で 30分制限なしにサーバーを1台利用できる GCPやAWSはちょっと分からない人でも サーバークライアント型の通信ゲームを作成できる！ PlayFlowCloud　https://playflowcloud.com/
21. 21
 新しい手法で解決できたこと • AOI機能で離れているプレイヤーやオブジェクトの データ量を大幅に削減できる • 近くの人のアバターは問題なく同期するので コミュニケーションに支障がない 大規模接続時の通信量削減 ワールド全体 パケットを受け 取る範囲 • 設定はNetworkObjectに対して NetworkObserverコンポーネントを設定するのみ (DistanceConditionクラスを参考にカスタマイズするのがお勧め ) [注意点] • 範囲外にいる際にはRPCが呼ばれないので、範囲内に入ったときに状態 を同期できるようにSyncVarなどを活用すること
22. 22
 新しい手法で解決できたこと • 音声はDissonance Voice Chatを使用 • FishNet対応するサンプルもあるので対応可能 (一部不具合があるので修正依頼中) • 独自の修正を加えて一定距離離れたクライアントには送信しないことでパケットを節約 • サーバー側で音声の合成はしていない (コミュニケーション目的とする場合、近くの人が同時に喋る というシチュエーションがあまりないためあまり恩恵がない) • FishNetの通信経路をそのまま使用するので、セキュリティの 設定を行いやすい ボイスチャットも可能な大規模接続可能なワールド
23. 23
 新しい手法で解決できたこと 全員が切断してもデータを残すことができる仮想空間 • サーバーが情報を保持しているので、適切に実装すれば 全員が退出した後でも空間の情報を同期することができる。 例) 家具の配置, 作成したアイテム etc… FishNetが ◦ スポーンしたNetworkObject ◦ SyncVar属性をつけた変数 ◦ BufferLast=trueにしたRPCメソッド を接続時に自動で同期してくれるので、容易にワールドの情報を復元することができる
24. 24
 デモ • Tickレート 30 • 80クライアント接続 アバター+両手の座標を同期 • 16クライアントが常時発話
25. 25
 FishNetのデメリット よくも悪くもサーバーの準備が必要 • メリットがそこまでないならサーバーの準備や管理が必要ないPUN2とかの方が圧倒的に楽 ソースコードの変更があればサーバービルドをデプロイしなおす必要がある • コード生成でRPCを実現しているので、クライアントのRPCで使うメソッドの引数などに変更した場合 はサーバー側のビルドしなおさないと正常に動かない • そこまでサーバー側の処理が必要ではないクライアント同士の通信部分の変更でもサーバービル ドの作り直しが必要になる • sceneに配置したNetworkObjectがサーバーとクライアントで違うとエラーになる Addressableなどでsceneを更新できるようにするなどの工夫が必要
26. 26
 それぞれの通信方式のまとめ リレーサーバー (PUN2 etc…) • 開発段階は無料で手軽に始められる • 基本的にはサーバー実装できない (通信量の削減の工夫に限界がある) 低TickRateで 多くて10~20人 Headless ビルドサーバー (FishNet etc…) • サーバー実装を工夫して より大人数の接続に耐えることができる • 物理演算や当たり判定をサーバーで行える • サーバーの運用が難しい 大規模なワールド向け (ワールド毎に様々な 仕組みを作るのは大変)
27. 27
 今後の展望 • 送る/送らないの2段階のAOIではなく、距離に応じて 高TickRate / 低TickRate / 送らない の３段階の送信制御を実装する • サーバービルドを頻繁にしなくてもいいワークフローの構築 ◦ ワールドの背景はAddressableなどで後で変更可能にする ◦ 簡単な制御はC#コードを書かないで実装可能にする
28. 28