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

by gree_tech

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

「#REALITY釣り部」技術的な課題汎用的なAPIサーバーで釣りの状態を管理しようとすると遅延が大きく、ゲーム体験を著しく損ねてしまう。  特にホストとコラボ参加者の間で不整合が起きやすくプレイが困難。  →リアルタイム性が高く、ロジックの実行できるサーバーが必要 

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

「#REALITY釣り部」で使っているAgones Fleet Agones System (FleetAutoScaler) DGS Allocated DGS Allocated ・  ・  ・  DGS Ready DGS Shutdown ▼Fleet Fleetは、ここでいうDGSのセットのようなもの。     主要な状態として、Ready・Allocated・Shutdownがある。     FleetAutoScalerにより、オートスケールが行われる。    

Slide 24

Slide 24 text

「#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

Slide 25

Slide 25 text

「#REALITY釣り部」で使っているAgones Fleet DGS Shutdown   ・  ・  DGS Ready DGS Ready Buffer Size Fleet ・  ・  ・  DGS Ready DGS Ready Buffer Size 使用完了したShutdownのサーバーは削除されるが、Allocatedはオートスケールから保護される。 DGS Allocated DGS Allocated

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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