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

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

Transcript

1. ジープラ株式会社　　ソフトウェアエンジニア　銭 洋
   REALITYのライブゲームで
   新しく採用したDGSの話
   REALITY株式会社　ソフトウェアエンジニア　山田 達矢
   

   View Slide

2. •REALITYとは
   •REALITYのゲーム
   •#REALITY釣り部
   • DGSの紹介
   • 技術概要
   • 選定基準・理由
   • クライアントとの連携
   • REALITYならではの技術的工夫
   アジェンダ
   2

   

   View Slide

3. 3

   スマホひとつでアバター作成、ライブ配信による交流やゲームまで楽しめるスマホ向けメタバース
   アプリ
   REALITYとは
   アバター
 ライブ配信

   コミュニケーション
 ゲーム

   ワールド

   

   View Slide

4. 作り方によって２種類に分類可能
   REALITYのゲーム
   4

   ● Unityゲーム

   ○ REALITYアプリのバイナリに内蔵されている

   ○ REALITYアバターをそのまま使える

   ● Webゲーム

   ○ アプリの更新とは別に配信可能

   ○ 3Dのアバターを使うことはできない

   → どちらのゲームも複数人で遊べ、視聴者もゲームの画面を見ることがで
   きる

   

   View Slide

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

   

   View Slide

6. アバターを使って「ゲーム」をやりたい
   そこでできたのが
   

   View Slide

7. 2022年8月24日にシーズン1がリリースされた「#REALITY釣り部」
   #REALITY釣り部
   7

   

   View Slide

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

   

   View Slide

9. #REALITY釣り部
   9

   • REALITYの3Dアバターで遊べるUnityゲーム

   • REALITY初の課金要素有りのゲーム

   • REALITY初のアバター報酬有りのゲーム

   • REALITYで初めて独立したリアルタイムサーバーを採
   用したゲーム

   

   View Slide

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

    • REALITYの特徴から発生する課題

    • 「#REALITY釣り部」の仕様特有の課題

    

    View Slide

11. 通常のゲーム開発ではあまり見られない課題がいくつもある
    「#REALITY釣り部」技術的な課題
    ● 配信ゲーム特有の課題

    ○ 配信ホスト、コラボ参加者、視聴者とロールが多く、それぞれ実行
    するロジックを切り分ける必要がある（※REALITYのゲームでは
    映像が配信されるわけではなく、視聴者はロジックを実行して配
    信者の画面を再現する）

    ○ 視聴者の参加タイミングによらずその時点の状態からゲームを視
    聴できる必要がある

    

    View Slide

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

    ○ 配信中にアバターを変更できるため、ゲームのプレイ中に変更される
    場合を考慮しなければならない

    ○ 配信中にコラボの出入りが発生することによるプレイヤーの変化に対
    応する必要がある

    ○ 配信中や視聴中にバックグラウンドにしたり、アプリ終了から復帰した
    りするユーザーがいることを考慮しなければならない

    ○ スマホ向けメタバースなので、通信状況の悪いモバイル回線での安定
    性を意識する必要がある

    

    View Slide

13. 通常のゲーム開発ではあまり見られない課題がいくつもある
    「#REALITY釣り部」技術的な課題
    ● 「#REALITY釣り部」の仕様特有の課題

    ○ 同じ釣り場で複数人が同時に釣りをするので、通信のリアルタイ
    ム性の高さが求められる

    ○ 課金、ランキング機能が存在するので、チート防止としてサー
    バーで釣りの状態などを管理する必要がある

    

    View Slide

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

    既存のゲームで使われている仕組みで解決はできないの
    だろうか。

    

    View Slide

15. 既存REALITYゲームの通信の仕組み
    「#REALITY釣り部」技術的な課題
    コラボ
    プラットフォーム
    マルチゲームサーバー
    ホスト
    視聴者
    ▼データを中継するためのサーバー
    マルチゲームサーバーは、ホストから受け取ったデータ
    をコラボ参加者や視聴者に転送したり、あるいは逆にコ
    ラボ参加者のデータをホストに転送したりしてくれる
    ▼ホストが送ったデータはサーバーにバック
    アップされる
    ホストが切断したりアプリ終了したりしてもデータを失わ
    ないように、ホストが送った最終のデータをサーバーが
    保存し、再接続時に受信する仕組みが存在する
    

    View Slide

16. 釣りに適用すると
    「#REALITY釣り部」技術的な課題
    コラボ
    プラットフォーム
    マルチゲームサーバー
    ホスト
    視聴者
    APIサーバー
    ▼APIサーバーの必要性
    課金やランキングがある以上、チート防止のためにサー
    バーで釣りを管理する必要がある。
    ▼APIサーバーの問題点
    ● リクエスト時のオーバーヘッドがあるので、遅延が大
    きい
    ● 情報を都度DBに保存するので、遅延が増加する
    上、サーバー側負荷も高くなりがち
    ● 情報を他人に共有するだけでも、 API→ホスト→マ
    ルチゲームサーバー →コラボのように複雑な経路に
    なり、さらに遅延が増加する
    とにかく遅延が大きすぎる
    データベース
    都度参照する
    

    View Slide

17. 「#REALITY釣り部」技術的な課題
    汎用的なAPIサーバーで釣りの状態を管理しようとすると遅延
    が大きく、ゲーム体験を著しく損ねてしまう。

    特にホストとコラボ参加者の間で不整合が起きやすくプレイが
    困難。

    →リアルタイム性が高く、ロジックの実行できるサーバーが必
    要

    

    View Slide

18. 「#REALITY釣り部」技術的な課題
    一方で、視聴者はというと

    ○ プレイする訳ではないので、リアルタイム性の高さはそこまで大事では
    ない（音声にも一定の遅延があるので遅れは許容）

    ○ むしろ安定性の方が求められる

    ○ 配信枠によって人数が読めず、サーバーに接続させる場合はオートス
    ケール可能な環境が好ましい

    →既存のマルチゲームサーバーを使った方が理想的である

    ・マルチゲームサーバーはPub/Sub方式を採用したオートスケール可能な環境

    ・一定時間ごとの情報を送信フレームにしてホストが共有し、あえて遅延させる
    ことで、安定でなめらかな視聴環境を用意できる

    

    View Slide

19. 「#REALITY釣り部」技術的な課題
    まとめると

    ゲームプレイヤー：情報を速やかに同期することが最優先

    →ロジック実行可能なリアルタイムサーバーとお互いに通信したい

    

    視聴者：同期の低遅延よりも、カクツキが少なく安定していることが優先さ
    れる。また大人数の視聴に耐える環境が重視される。

    →マルチゲームサーバーを利用したい

    

    View Slide

20. 「#REALITY釣り部」技術的な課題
    以上のことから、次の構成に決定

    

    DGS
    コラボ
    PF Multigame Server
    ホスト
    視聴者
    TCP Socket
    ▼リアルタイム通信専用のサーバーを用意
    ゲーム中のリアルタイム通信を専用サーバーにすること
    で、高レスポンス、高効率の通信に。
    ロジックが実行できるので、釣りの状態も管理可能。
    APIサーバーと比べDBアクセスの頻度が低く（ゲーム終
    了時などにまとめてDBアクセスする）、遅延の要因も削
    減される。
    WSS
    ▼視聴は従来のまま
    配信ホストがゲームのデータを一定時間分
    まとめて送信フレームにして視聴者に共有。
    視聴者はバッファーに一定の受信フレーム
    が溜まったところで再生することで安定した
    視聴が行える。大人数接続の耐性もある。
    

    View Slide

21. 「#REALITY釣り部」技術的な課題
    まだ問題は残っている

    

    コラボ
    DGS
    ホスト コラボ
    配信A
    コラボ
    DGS
    ホスト コラボ
    配信B
    ▼DGSのインスタンス生成、消去
    配信で釣りを遊ぶごとに、専用のDGSインス
    タンスを生成する必要があり、終了する場合
    にはリソースを解放して再利用可能な状態
    にする必要がある。また、すぐにプレイできる
    ように、事前に必要な処理を済ませた待機
    中のインスタンスをいくつか用意しておきた
    い。
    ▼使用中DGSの保護
    雑にオートスケールの設定を入れたり、手動
    でスケールインしたりすると、使用中のイン
    スタンスを誤って終了する可能性がある。
    ▼接続先DGSの割りあて
    同じ配信で遊んでいる人は同じサーバーに
    接続しなければならない。正しく同じサー
    バーに振り分ける必要がある。
    

    View Slide

22. 「#REALITY釣り部」技術的な課題
    ▼DGSのインスタンス生成、消去
    配信で釣りを遊ぶごとに、専用の
    DGSインスタンスを
    生成する必要があり、終了する場合にはリソースを解
    放して再利用可能な状態にする必要がある。また、す
    ぐにプレイできるように、事前に必要な処理を済ませた
    待機中のインスタンスをいくつか用意しておきたい。
    ▼使用中DGSの保護
    雑にオートスケールの設定を入れたり、手動でスケー
    ルインしたりすると、使用中のインスタンスを誤って終
    了する可能性がある。
    ▼接続先DGSの割りあて
    同じ配信で遊んでいる人は同じサーバーに接続しなけ
    ればならない。正しく同じサーバーに振り分ける必要が
    ある。
    この辺をいい感じにやってくれる
    

    View Slide

23. 「#REALITY釣り部」で使っているAgones
    Fleet
    Agones System
    (FleetAutoScaler)
    DGS
    Allocated
    DGS
    Allocated
    ・

    ・

    ・

    DGS
    Ready
    DGS
    Shutdown
    ▼Fleet
    Fleetは、ここでいうDGSのセットのようなもの。 

    

    主要な状態として、Ready・Allocated・Shutdownがある。 

    

    FleetAutoScalerにより、オートスケールが行われる。 

    

    

    View Slide

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
    

    View Slide

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
    

    View Slide

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に接続
    

    View Slide

27. DGSとクライアントの連携の話
    このDGSの仕組みを
    クライアント側でどう対応、反映しているか
    

    View Slide

28. DGSとクライアントとの連携
    DGSから受け取ったイベントを元に実行していく
    1. 魚の出現
    2. 魚とのバトル・ファイトの開始
    3. 釣果の表示
    4. イベントの実行
    

    View Slide

29. DGSとクライアントとの連携（個別の釣り）
    1. DGSからイベントを送る
    a. ゲームの開始
    b. イベントの開始通知
    c. イベントの終了通知（厳密には終了イベントの開始通知）
    d. 魚影の移動情報、形の情報
    2. クライアントからDGSにイベントを送る
    a. 魚が餌に食いついた
    b. 魚とのバトルの開始リクエスト
    

    View Slide

30. DGSに送ってそうで送っていないもの
    1. ウキの現在位置
    2. 現在のアバターのアニメーションの情報
    3. UIの開いている情報
    4. 持っているメダルの情報
    これらはマルチゲームサーバで管理している
    

    View Slide

31. 釣りの成功判定
    1. 魚の移動情報はDGSで管理しているがウキはDGS管理していな
    い
    2. 食いつきの判定はクライアント側で判定
    3. DGSはクライアントからつついたことを受け取りステータスの更
    新。つつきの成功をクライアントに送る
    4. クライアントはつつきが成功していたらタップでヒットができる
    5. DGSはヒットを受け取ったらバトルの開始イベントを送る
    

    View Slide

32. 食いつきからバトルまでの流れ
    釣り人
    DGS
    食いついた！
    釣り人
    DGS
    食いついてOK!
    釣り人
    DGS
    タップした！
    釣り人
    DGS
    バトル開始！
    

    View Slide

33. なぜこのようにしているか
    1. サーバで管理している魚の位置は、あくまで「次の移動先」をやっ
    ているにすぎない
    2. ラグなどによりサーバで見ている魚の情報とクライアントの情報は
    ずれることがある
    3. 見た目的なところはクライアントに任せ、DGSでは整合性が取れ
    ているかを確認する
    a. 特に他の人と同じ魚を釣ろうとしていないか、などをチェックしている
    

    View Slide

34. DGSとクライアントとの連携（全体イベント）
    1. DGSからイベントを受け取ったら、クライアント側は受け取ったと
    いうメッセージ(pop)をDGSに返す
    2. これによりDGSでは接続が担保されたとみなし次のイベントを実
    行する
    ではクライアントが受け取ったメッセージを返せなかったら？
    

    View Slide

35. REALITYならではの技術的工夫
    1. REALITYのアプリは画面配信では無い
    2. バックグラウンドに行った際にマイクなどは動くがUnity部分は動
    かない
    3. なのでバックグラウンド中の釣りのイベントを補完する必要がある
    4. そのためにDGSのイベント制御を細かく行っている
    

    View Slide

36. REALITYならではの技術的工夫
    1. REALITYは配信アプリ
    2. 視聴者がリアルタイムで配信を見にくる
    3. コラボ参加をする他の配信者もいる
    いつ、誰が配信を見に来ても、抜けても動作の担保が必要！
    

    View Slide

37. 視聴者・コラボ配信者の工夫
    REALITYには配信を見る視聴者と、一緒に参加するコラボ参加者が
    いる
    ・視聴者はいつ入ってもゲームを見れる
    →どのタイミングであってもゲームの再現をする必要がある
    ・コラボ参加者はいつでも抜けられる
    →ホスト以外の誰がいつ抜けてもゲームの動作を担保する必要があ
    る
    

    View Slide

38. ゲームの視聴者
    1. DGSはホストが受け取った情報を視聴者に流すようにしている
    2. 視聴者はDGSに接続はしていない
    3. DGSの負荷としてはゲームに参加している人のみ
    ホスト
    コラボ 視聴者
    DGS
    

    View Slide

39. コラボ参加者の接続が切れた場合
    1. コラボ参加者はDGSに接続し、メッセージを受け取ったらpopを
    返す
    2. 全員がpopをするまでDGSでは次のイベントを送らない
    3. コラボ参加者が途中で抜けた場合、DGSではその人をpop済とし
    て扱う
    コラボ参加者は途中で抜けてもゲームが進む
    ホスト
    コラボ 視聴者
    DGS
    

    View Slide

40. コラボ参加者が途中で抜けた場合
    1. popができなくなる
    2. 接続が切れたことをDGSが検知
    3. REALITY配信アプリからの退出のイベントから接続情報をアップ
    デート
    4. そのプレイヤーが復帰することを想定しつつもイベントは進む
    ホスト
    コラボ
    視聴者
    DGS
    pop
    しとこう
    

    View Slide

41. ホストが途中で抜けた場合
    1. DGSとのやりとりができなくなる
    2. ホストの復帰をDGSは待つ
    3. ホストが復帰したら再開
    ホスト
    コラボ
    視聴者
    DGS
    ホストの
    復帰を
    待とう
    

    View Slide

42. 演出の再生の同期
    1. 演出を再生して次のイベントに行く際にバックグラウンドなどにい
    て演出が見れないプレイヤーが想定される
    2. イベントを開始していいかをプレイヤーに通知し、プレイヤー全員
    の準備が整っているかをpopイベントで受け取る
    3. DGSは全員からイベントのpopを受け取ることでイベントの開始
    をスタートする
    4. その間は他のプレイヤーは釣りに関わる操作ができない
    これにより重要なイベントは取り残されることを防げる
    

    View Slide

43. イベントの流れのまとめ
    ホスト
    コラボ
    視聴者
    DGS
    ホスト
    コラボ
    視聴者
    DGS
    ①このイベント再生して
    OK？
    ③全員OK！　再生する
    ね！
    ②OK!
    ②OK!
    

    View Slide

44. まとめ
    1. DGSを使うことで配信ごとにゲームのインスタンスサーバを立て
    られる
    2. クライアントから必要な情報は別途送ることが可能
    3. ユーザ一人一人を管理して途中の入退出を管理
    DGSはいいぞ！
    

    View Slide

45. View Slide