REALITYのライブゲームで新しく採用したDGSの話（リアルタイムサーバーの話）

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

Transcript

1. ジープラ株式会社　　ソフトウェアエンジニア　銭 洋 REALITYのライブゲームで 新しく採用したDGSの話 REALITY株式会社　ソフトウェアエンジニア　山田 達矢
2. •REALITYとは •REALITYのゲーム •#REALITY釣り部 • DGSの紹介 • 技術概要 • 選定基準・理由 • クライアントとの連携 • REALITYならではの技術的工夫 アジェンダ 2

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

4. 作り方によって２種類に分類可能 REALITYのゲーム 4
 • Unityゲーム
 ◦ REALITYアプリのバイナリに内蔵されている
 ◦ REALITYアバターをそのまま使える
 • Webゲーム
 ◦ アプリの更新とは別に配信可能
 ◦ 3Dのアバターを使うことはできない
 → どちらのゲームも複数人で遊べ、視聴者もゲームの画面を見ることがで きる

5. Webでやるゲームか、アバターが出ても会話がメインのゲームだった REALITYのゲーム 5

6. アバターを使って「ゲーム」をやりたい そこでできたのが
7. 2022年8月24日にシーズン1がリリースされた「#REALITY釣り部」 #REALITY釣り部 7

8. 2022年10月26日（水）にシーズン3が開始！ #REALITY釣り部 8

9. #REALITY釣り部 9
 • REALITYの3Dアバターで遊べるUnityゲーム
 • REALITY初の課金要素有りのゲーム
 • REALITY初のアバター報酬有りのゲーム
 • REALITYで初めて独立したリアルタイムサーバーを採 用したゲーム

10. 通常のゲーム開発ではあまり見られない課題がいくつもある 「#REALITY釣り部」技術的な課題 • 配信ゲーム特有の課題
 • REALITYの特徴から発生する課題
 • 「#REALITY釣り部」の仕様特有の課題

11. 通常のゲーム開発ではあまり見られない課題がいくつもある 「#REALITY釣り部」技術的な課題 • 配信ゲーム特有の課題
 ◦ 配信ホスト、コラボ参加者、視聴者とロールが多く、それぞれ実行 するロジックを切り分ける必要がある（※REALITYのゲームでは 映像が配信されるわけではなく、視聴者はロジックを実行して配 信者の画面を再現する）
 ◦ 視聴者の参加タイミングによらずその時点の状態からゲームを視 聴できる必要がある

12. 通常のゲーム開発ではあまり見られない課題がいくつもある 「#REALITY釣り部」技術的な課題 • REALITYの特徴から発生する課題
 ◦ 配信中にアバターを変更できるため、ゲームのプレイ中に変更される 場合を考慮しなければならない
 ◦ 配信中にコラボの出入りが発生することによるプレイヤーの変化に対 応する必要がある
 ◦ 配信中や視聴中にバックグラウンドにしたり、アプリ終了から復帰した りするユーザーがいることを考慮しなければならない
 ◦ スマホ向けメタバースなので、通信状況の悪いモバイル回線での安定 性を意識する必要がある

13. 通常のゲーム開発ではあまり見られない課題がいくつもある 「#REALITY釣り部」技術的な課題 • 「#REALITY釣り部」の仕様特有の課題
 ◦ 同じ釣り場で複数人が同時に釣りをするので、通信のリアルタイ ム性の高さが求められる
 ◦ 課金、ランキング機能が存在するので、チート防止としてサー バーで釣りの状態などを管理する必要がある

14. 既存の仕組みで課題を解決できるのだろうか 「#REALITY釣り部」技術的な課題 列挙した通り、通信関係の課題が多い。
 既存のゲームで使われている仕組みで解決はできないの だろうか。

15. 既存REALITYゲームの通信の仕組み 「#REALITY釣り部」技術的な課題 コラボ プラットフォーム マルチゲームサーバー ホスト 視聴者 ▼データを中継するためのサーバー マルチゲームサーバーは、ホストから受け取ったデータ をコラボ参加者や視聴者に転送したり、あるいは逆にコ ラボ参加者のデータをホストに転送したりしてくれる ▼ホストが送ったデータはサーバーにバック アップされる ホストが切断したりアプリ終了したりしてもデータを失わ ないように、ホストが送った最終のデータをサーバーが 保存し、再接続時に受信する仕組みが存在する
16. 釣りに適用すると 「#REALITY釣り部」技術的な課題 コラボ プラットフォーム マルチゲームサーバー ホスト 視聴者 APIサーバー ▼APIサーバーの必要性 課金やランキングがある以上、チート防止のためにサー バーで釣りを管理する必要がある。 ▼APIサーバーの問題点 • リクエスト時のオーバーヘッドがあるので、遅延が大 きい • 情報を都度DBに保存するので、遅延が増加する 上、サーバー側負荷も高くなりがち • 情報を他人に共有するだけでも、 API→ホスト→マ ルチゲームサーバー →コラボのように複雑な経路に なり、さらに遅延が増加する とにかく遅延が大きすぎる データベース 都度参照する
17. 「#REALITY釣り部」技術的な課題 汎用的なAPIサーバーで釣りの状態を管理しようとすると遅延 が大きく、ゲーム体験を著しく損ねてしまう。
 特にホストとコラボ参加者の間で不整合が起きやすくプレイが 困難。
 →リアルタイム性が高く、ロジックの実行できるサーバーが必 要

18. 「#REALITY釣り部」技術的な課題 一方で、視聴者はというと
 ◦ プレイする訳ではないので、リアルタイム性の高さはそこまで大事では ない（音声にも一定の遅延があるので遅れは許容）
 ◦ むしろ安定性の方が求められる
 ◦ 配信枠によって人数が読めず、サーバーに接続させる場合はオートス ケール可能な環境が好ましい
 →既存のマルチゲームサーバーを使った方が理想的である
 ・マルチゲームサーバーはPub/Sub方式を採用したオートスケール可能な環境
 ・一定時間ごとの情報を送信フレームにしてホストが共有し、あえて遅延させる ことで、安定でなめらかな視聴環境を用意できる

19. 「#REALITY釣り部」技術的な課題 まとめると
 ゲームプレイヤー：情報を速やかに同期することが最優先
 →ロジック実行可能なリアルタイムサーバーとお互いに通信したい
 
 視聴者：同期の低遅延よりも、カクツキが少なく安定していることが優先さ れる。また大人数の視聴に耐える環境が重視される。
 →マルチゲームサーバーを利用したい

20. 「#REALITY釣り部」技術的な課題 以上のことから、次の構成に決定
 
 DGS コラボ PF Multigame Server ホスト 視聴者 TCP Socket ▼リアルタイム通信専用のサーバーを用意 ゲーム中のリアルタイム通信を専用サーバーにすること で、高レスポンス、高効率の通信に。 ロジックが実行できるので、釣りの状態も管理可能。 APIサーバーと比べDBアクセスの頻度が低く（ゲーム終 了時などにまとめてDBアクセスする）、遅延の要因も削 減される。 WSS ▼視聴は従来のまま 配信ホストがゲームのデータを一定時間分 まとめて送信フレームにして視聴者に共有。 視聴者はバッファーに一定の受信フレーム が溜まったところで再生することで安定した 視聴が行える。大人数接続の耐性もある。
21. 「#REALITY釣り部」技術的な課題 まだ問題は残っている
 
 コラボ DGS ホスト コラボ 配信A コラボ DGS ホスト コラボ 配信B ▼DGSのインスタンス生成、消去 配信で釣りを遊ぶごとに、専用のDGSインス タンスを生成する必要があり、終了する場合 にはリソースを解放して再利用可能な状態 にする必要がある。また、すぐにプレイできる ように、事前に必要な処理を済ませた待機 中のインスタンスをいくつか用意しておきた い。 ▼使用中DGSの保護 雑にオートスケールの設定を入れたり、手動 でスケールインしたりすると、使用中のイン スタンスを誤って終了する可能性がある。 ▼接続先DGSの割りあて 同じ配信で遊んでいる人は同じサーバーに 接続しなければならない。正しく同じサー バーに振り分ける必要がある。
22. 「#REALITY釣り部」技術的な課題 ▼DGSのインスタンス生成、消去 配信で釣りを遊ぶごとに、専用の DGSインスタンスを 生成する必要があり、終了する場合にはリソースを解 放して再利用可能な状態にする必要がある。また、す ぐにプレイできるように、事前に必要な処理を済ませた 待機中のインスタンスをいくつか用意しておきたい。 ▼使用中DGSの保護 雑にオートスケールの設定を入れたり、手動でスケー ルインしたりすると、使用中のインスタンスを誤って終 了する可能性がある。 ▼接続先DGSの割りあて 同じ配信で遊んでいる人は同じサーバーに接続しなけ ればならない。正しく同じサーバーに振り分ける必要が ある。 この辺をいい感じにやってくれる
23. 「#REALITY釣り部」で使っているAgones Fleet Agones System (FleetAutoScaler) DGS Allocated DGS Allocated ・
 ・
 ・
 DGS Ready DGS Shutdown ▼Fleet Fleetは、ここでいうDGSのセットのようなもの。 
 
 主要な状態として、Ready・Allocated・Shutdownがある。 
 
 FleetAutoScalerにより、オートスケールが行われる。 
 

24. 「#REALITY釣り部」で使っているAgones Fleet DGS Allocated ・
 ・
 ・
 DGS Ready DGS Ready Fleet DGS Allocated ・
 ・
 ・
 DGS Allocated DGS Ready Fleet DGS Allocated ・
 ・
 ・
 DGS Allocated DGS Ready DGS Ready 割り当て要求時に、Readyのサーバーを Allocatedにしてクライアントと接続させる Readyの数が常に一定（ Buffer Size）になるよう に、割り当て後には新規でインスタンスが立ち上が る Buffer Size Buffer Size
25. 「#REALITY釣り部」で使っているAgones Fleet DGS Shutdown 
 ・
 ・
 DGS Ready DGS Ready Buffer Size Fleet ・
 ・
 ・
 DGS Ready DGS Ready Buffer Size 使用完了したShutdownのサーバーは削除されるが、Allocatedはオートス ケールから保護される。 DGS Allocated DGS Allocated
26. 「#REALITY釣り部」で使っているAgones Agones System ① ② Dedicated Game Server Pod (GameServer) API Server ③ ④ ⑤ ⑥ ▼ゲームを開始するまでの処理 ①クライアントからAPIサーバーにDGSの割 り当てを要求 ②APIサーバーからAgones SystemにDGS の割り当てを要求 ③Agones SystemがDGSの割り当て （Allocate）を行う ④⑤Agones SystemからAPIサーバーを経 由して接続先のホスト名とポート番号をクラ イアントに通知 ⑥クライアントがDGSに接続
27. DGSとクライアントの連携の話 このDGSの仕組みを クライアント側でどう対応、反映しているか
28. DGSとクライアントとの連携 DGSから受け取ったイベントを元に実行していく 1. 魚の出現 2. 魚とのバトル・ファイトの開始 3. 釣果の表示 4. イベントの実行
29. DGSとクライアントとの連携（個別の釣り） 1. DGSからイベントを送る a. ゲームの開始 b. イベントの開始通知 c. イベントの終了通知（厳密には終了イベントの開始通知） d. 魚影の移動情報、形の情報 2. クライアントからDGSにイベントを送る a. 魚が餌に食いついた b. 魚とのバトルの開始リクエスト
30. DGSに送ってそうで送っていないもの 1. ウキの現在位置 2. 現在のアバターのアニメーションの情報 3. UIの開いている情報 4. 持っているメダルの情報 これらはマルチゲームサーバで管理している
31. 釣りの成功判定 1. 魚の移動情報はDGSで管理しているがウキはDGS管理していな い 2. 食いつきの判定はクライアント側で判定 3. DGSはクライアントからつついたことを受け取りステータスの更 新。つつきの成功をクライアントに送る 4. クライアントはつつきが成功していたらタップでヒットができる 5. DGSはヒットを受け取ったらバトルの開始イベントを送る
32. 食いつきからバトルまでの流れ 釣り人 DGS 食いついた！ 釣り人 DGS 食いついてOK! 釣り人 DGS タップした！ 釣り人 DGS バトル開始！
33. なぜこのようにしているか 1. サーバで管理している魚の位置は、あくまで「次の移動先」をやっ ているにすぎない 2. ラグなどによりサーバで見ている魚の情報とクライアントの情報は ずれることがある 3. 見た目的なところはクライアントに任せ、DGSでは整合性が取れ ているかを確認する a. 特に他の人と同じ魚を釣ろうとしていないか、などをチェックしている
34. DGSとクライアントとの連携（全体イベント） 1. DGSからイベントを受け取ったら、クライアント側は受け取ったと いうメッセージ(pop)をDGSに返す 2. これによりDGSでは接続が担保されたとみなし次のイベントを実 行する ではクライアントが受け取ったメッセージを返せなかったら？
35. REALITYならではの技術的工夫 1. REALITYのアプリは画面配信では無い 2. バックグラウンドに行った際にマイクなどは動くがUnity部分は動 かない 3. なのでバックグラウンド中の釣りのイベントを補完する必要がある 4. そのためにDGSのイベント制御を細かく行っている
36. REALITYならではの技術的工夫 1. REALITYは配信アプリ 2. 視聴者がリアルタイムで配信を見にくる 3. コラボ参加をする他の配信者もいる いつ、誰が配信を見に来ても、抜けても動作の担保が必要！
37. 視聴者・コラボ配信者の工夫 REALITYには配信を見る視聴者と、一緒に参加するコラボ参加者が いる ・視聴者はいつ入ってもゲームを見れる →どのタイミングであってもゲームの再現をする必要がある ・コラボ参加者はいつでも抜けられる →ホスト以外の誰がいつ抜けてもゲームの動作を担保する必要があ る
38. ゲームの視聴者 1. DGSはホストが受け取った情報を視聴者に流すようにしている 2. 視聴者はDGSに接続はしていない 3. DGSの負荷としてはゲームに参加している人のみ ホスト コラボ 視聴者 DGS
39. コラボ参加者の接続が切れた場合 1. コラボ参加者はDGSに接続し、メッセージを受け取ったらpopを 返す 2. 全員がpopをするまでDGSでは次のイベントを送らない 3. コラボ参加者が途中で抜けた場合、DGSではその人をpop済とし て扱う コラボ参加者は途中で抜けてもゲームが進む ホスト コラボ 視聴者 DGS
40. コラボ参加者が途中で抜けた場合 1. popができなくなる 2. 接続が切れたことをDGSが検知 3. REALITY配信アプリからの退出のイベントから接続情報をアップ デート 4. そのプレイヤーが復帰することを想定しつつもイベントは進む ホスト コラボ 視聴者 DGS pop しとこう
41. ホストが途中で抜けた場合 1. DGSとのやりとりができなくなる 2. ホストの復帰をDGSは待つ 3. ホストが復帰したら再開 ホスト コラボ 視聴者 DGS ホストの 復帰を 待とう
42. 演出の再生の同期 1. 演出を再生して次のイベントに行く際にバックグラウンドなどにい て演出が見れないプレイヤーが想定される 2. イベントを開始していいかをプレイヤーに通知し、プレイヤー全員 の準備が整っているかをpopイベントで受け取る 3. DGSは全員からイベントのpopを受け取ることでイベントの開始 をスタートする 4. その間は他のプレイヤーは釣りに関わる操作ができない これにより重要なイベントは取り残されることを防げる
43. イベントの流れのまとめ ホスト コラボ 視聴者 DGS ホスト コラボ 視聴者 DGS ①このイベント再生して OK？ ③全員OK！　再生する ね！ ②OK! ②OK!
44. まとめ 1. DGSを使うことで配信ごとにゲームのインスタンスサーバを立て られる 2. クライアントから必要な情報は別途送ることが可能 3. ユーザ一人一人を管理して途中の入退出を管理 DGSはいいぞ！