Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
REALITYのライブゲームで新しく採用したDGSの話(リアルタイムサーバーの話)
gree_tech
PRO
October 25, 2022
Technology
0
290
REALITYのライブゲームで新しく採用したDGSの話(リアルタイムサーバーの話)
GREE Tech Conference 2022で発表された資料です。
https://techcon.gree.jp/2022/session/TrackC-1
gree_tech
PRO
October 25, 2022
Tweet
Share
More Decks by gree_tech
See All by gree_tech
基調講演-サステナブルなチームであるために-
gree_tech
PRO
0
280
クリエイターツール「QUANT」の開発の話 & クライアントに寄り添ったデータ分析基盤の構築
gree_tech
PRO
0
220
爆速で成長するおでかけ情報サービスの成長を支えるデザインと開発の取り組みについて
gree_tech
PRO
0
360
グリーの新卒1年目が半年間働いて感じたグリーのカルチャー 〜新卒でもこんなに任せて貰えるんですか!?〜
gree_tech
PRO
0
360
クラウド - オンプレ間の通信品質向上作戦!〜ネットワーク編〜
gree_tech
PRO
0
200
よくわかる!「データアナリスト」の作り方 〜とある新卒の成長物語〜
gree_tech
PRO
0
420
事業環境の変化に対応するインフラ組織 その取り組みと現状
gree_tech
PRO
0
280
簡単!Slack+GAS+GCPでIT棚卸自動化
gree_tech
PRO
0
260
GREE VR Studio Laboratory - UXDev R&D Summary 2022
gree_tech
PRO
0
680
Other Decks in Technology
See All in Technology
OpenShiftのリリースノートを整理してみた
loftkun
2
450
AI Services 概要 / AI Services overview
oracle4engineer
PRO
0
180
NGINXENG JP#2 - 1-NGINX-エンジニアリング勉強会-きょうの見どころ
hiropo20
0
120
私見「UNIXの考え方」/20230124-kameda-unix-phylosophy
opelab
1
180
OPENLOGI Company Profile
hr01
0
12k
目指せCoverage100%! AutoScale環境におけるSavings Plans購入戦略 / JAWS-UG_SRE_Coverage
taishin
0
530
CUEとKubernetesカスタムオペレータを用いた新しいネットワークコントローラをつくってみた
hrk091
1
300
OpenShiftでスポットVMを使おう.pdf
jpishikawa
1
410
地方自治体業務あるある ーアナログ最適化編-
y150saya
1
300
AWS re:Invent 2022で発表された新機能を試してみた ~Cloud OperationとSecurity~ / New Cloud Operation and Security Features Announced at AWS reInvent 2022
yuj1osm
1
220
モバイルモーションキャプチャーデバイス「mocopi」を軽く試してみた / IoTLT vol.95 (新年会IoTLTラジオ)
you
0
100
💰年度末予算消化祭💰 Large Memory Instance で 画像分類してみた
__allllllllez__
0
120
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
8
3.2k
Faster Mobile Websites
deanohume
295
29k
Become a Pro
speakerdeck
PRO
6
3.2k
Stop Working from a Prison Cell
hatefulcrawdad
263
18k
What's in a price? How to price your products and services
michaelherold
233
9.7k
How to Ace a Technical Interview
jacobian
270
21k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
227
16k
We Have a Design System, Now What?
morganepeng
37
6k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
109
16k
Keith and Marios Guide to Fast Websites
keithpitt
407
21k
How to train your dragon (web standard)
notwaldorf
66
4.3k
Six Lessons from altMBA
skipperchong
15
2.3k
Transcript
ジープラ株式会社 ソフトウェアエンジニア 銭 洋 REALITYのライブゲームで 新しく採用したDGSの話 REALITY株式会社 ソフトウェアエンジニア 山田 達矢
•REALITYとは •REALITYのゲーム •#REALITY釣り部 • DGSの紹介 • 技術概要 • 選定基準・理由 •
クライアントとの連携 • REALITYならではの技術的工夫 アジェンダ 2
3 スマホひとつでアバター作成、ライブ配信による交流やゲームまで楽しめるスマホ向けメタバース アプリ REALITYとは アバター ライブ配信 コミュニケーション ゲーム ワールド
作り方によって2種類に分類可能 REALITYのゲーム 4 • Unityゲーム ◦ REALITYアプリのバイナリに内蔵されている ◦ REALITYアバターをそのまま使える •
Webゲーム ◦ アプリの更新とは別に配信可能 ◦ 3Dのアバターを使うことはできない → どちらのゲームも複数人で遊べ、視聴者もゲームの画面を見ることがで きる
Webでやるゲームか、アバターが出ても会話がメインのゲームだった REALITYのゲーム 5
アバターを使って「ゲーム」をやりたい そこでできたのが
2022年8月24日にシーズン1がリリースされた「#REALITY釣り部」 #REALITY釣り部 7
2022年10月26日(水)にシーズン3が開始! #REALITY釣り部 8
#REALITY釣り部 9 • REALITYの3Dアバターで遊べるUnityゲーム • REALITY初の課金要素有りのゲーム • REALITY初のアバター報酬有りのゲーム • REALITYで初めて独立したリアルタイムサーバーを採
用したゲーム
通常のゲーム開発ではあまり見られない課題がいくつもある 「#REALITY釣り部」技術的な課題 • 配信ゲーム特有の課題 • REALITYの特徴から発生する課題 • 「#REALITY釣り部」の仕様特有の課題
通常のゲーム開発ではあまり見られない課題がいくつもある 「#REALITY釣り部」技術的な課題 • 配信ゲーム特有の課題 ◦ 配信ホスト、コラボ参加者、視聴者とロールが多く、それぞれ実行 するロジックを切り分ける必要がある(※REALITYのゲームでは 映像が配信されるわけではなく、視聴者はロジックを実行して配 信者の画面を再現する) ◦
視聴者の参加タイミングによらずその時点の状態からゲームを視 聴できる必要がある
通常のゲーム開発ではあまり見られない課題がいくつもある 「#REALITY釣り部」技術的な課題 • REALITYの特徴から発生する課題 ◦ 配信中にアバターを変更できるため、ゲームのプレイ中に変更される 場合を考慮しなければならない ◦ 配信中にコラボの出入りが発生することによるプレイヤーの変化に対 応する必要がある
◦ 配信中や視聴中にバックグラウンドにしたり、アプリ終了から復帰した りするユーザーがいることを考慮しなければならない ◦ スマホ向けメタバースなので、通信状況の悪いモバイル回線での安定 性を意識する必要がある
通常のゲーム開発ではあまり見られない課題がいくつもある 「#REALITY釣り部」技術的な課題 • 「#REALITY釣り部」の仕様特有の課題 ◦ 同じ釣り場で複数人が同時に釣りをするので、通信のリアルタイ ム性の高さが求められる ◦ 課金、ランキング機能が存在するので、チート防止としてサー バーで釣りの状態などを管理する必要がある
既存の仕組みで課題を解決できるのだろうか 「#REALITY釣り部」技術的な課題 列挙した通り、通信関係の課題が多い。 既存のゲームで使われている仕組みで解決はできないの だろうか。
既存REALITYゲームの通信の仕組み 「#REALITY釣り部」技術的な課題 コラボ プラットフォーム マルチゲームサーバー ホスト 視聴者 ▼データを中継するためのサーバー マルチゲームサーバーは、ホストから受け取ったデータ をコラボ参加者や視聴者に転送したり、あるいは逆にコ
ラボ参加者のデータをホストに転送したりしてくれる ▼ホストが送ったデータはサーバーにバック アップされる ホストが切断したりアプリ終了したりしてもデータを失わ ないように、ホストが送った最終のデータをサーバーが 保存し、再接続時に受信する仕組みが存在する
釣りに適用すると 「#REALITY釣り部」技術的な課題 コラボ プラットフォーム マルチゲームサーバー ホスト 視聴者 APIサーバー ▼APIサーバーの必要性 課金やランキングがある以上、チート防止のためにサー
バーで釣りを管理する必要がある。 ▼APIサーバーの問題点 • リクエスト時のオーバーヘッドがあるので、遅延が大 きい • 情報を都度DBに保存するので、遅延が増加する 上、サーバー側負荷も高くなりがち • 情報を他人に共有するだけでも、 API→ホスト→マ ルチゲームサーバー →コラボのように複雑な経路に なり、さらに遅延が増加する とにかく遅延が大きすぎる データベース 都度参照する
「#REALITY釣り部」技術的な課題 汎用的なAPIサーバーで釣りの状態を管理しようとすると遅延 が大きく、ゲーム体験を著しく損ねてしまう。 特にホストとコラボ参加者の間で不整合が起きやすくプレイが 困難。 →リアルタイム性が高く、ロジックの実行できるサーバーが必 要
「#REALITY釣り部」技術的な課題 一方で、視聴者はというと ◦ プレイする訳ではないので、リアルタイム性の高さはそこまで大事では ない(音声にも一定の遅延があるので遅れは許容) ◦ むしろ安定性の方が求められる ◦ 配信枠によって人数が読めず、サーバーに接続させる場合はオートス ケール可能な環境が好ましい
→既存のマルチゲームサーバーを使った方が理想的である ・マルチゲームサーバーはPub/Sub方式を採用したオートスケール可能な環境 ・一定時間ごとの情報を送信フレームにしてホストが共有し、あえて遅延させる ことで、安定でなめらかな視聴環境を用意できる
「#REALITY釣り部」技術的な課題 まとめると ゲームプレイヤー:情報を速やかに同期することが最優先 →ロジック実行可能なリアルタイムサーバーとお互いに通信したい 視聴者:同期の低遅延よりも、カクツキが少なく安定していることが優先さ れる。また大人数の視聴に耐える環境が重視される。 →マルチゲームサーバーを利用したい
「#REALITY釣り部」技術的な課題 以上のことから、次の構成に決定 DGS コラボ PF Multigame Server ホスト 視聴者
TCP Socket ▼リアルタイム通信専用のサーバーを用意 ゲーム中のリアルタイム通信を専用サーバーにすること で、高レスポンス、高効率の通信に。 ロジックが実行できるので、釣りの状態も管理可能。 APIサーバーと比べDBアクセスの頻度が低く(ゲーム終 了時などにまとめてDBアクセスする)、遅延の要因も削 減される。 WSS ▼視聴は従来のまま 配信ホストがゲームのデータを一定時間分 まとめて送信フレームにして視聴者に共有。 視聴者はバッファーに一定の受信フレーム が溜まったところで再生することで安定した 視聴が行える。大人数接続の耐性もある。
「#REALITY釣り部」技術的な課題 まだ問題は残っている コラボ DGS ホスト コラボ 配信A コラボ DGS
ホスト コラボ 配信B ▼DGSのインスタンス生成、消去 配信で釣りを遊ぶごとに、専用のDGSインス タンスを生成する必要があり、終了する場合 にはリソースを解放して再利用可能な状態 にする必要がある。また、すぐにプレイできる ように、事前に必要な処理を済ませた待機 中のインスタンスをいくつか用意しておきた い。 ▼使用中DGSの保護 雑にオートスケールの設定を入れたり、手動 でスケールインしたりすると、使用中のイン スタンスを誤って終了する可能性がある。 ▼接続先DGSの割りあて 同じ配信で遊んでいる人は同じサーバーに 接続しなければならない。正しく同じサー バーに振り分ける必要がある。
「#REALITY釣り部」技術的な課題 ▼DGSのインスタンス生成、消去 配信で釣りを遊ぶごとに、専用の DGSインスタンスを 生成する必要があり、終了する場合にはリソースを解 放して再利用可能な状態にする必要がある。また、す ぐにプレイできるように、事前に必要な処理を済ませた 待機中のインスタンスをいくつか用意しておきたい。 ▼使用中DGSの保護 雑にオートスケールの設定を入れたり、手動でスケー
ルインしたりすると、使用中のインスタンスを誤って終 了する可能性がある。 ▼接続先DGSの割りあて 同じ配信で遊んでいる人は同じサーバーに接続しなけ ればならない。正しく同じサーバーに振り分ける必要が ある。 この辺をいい感じにやってくれる
「#REALITY釣り部」で使っているAgones Fleet Agones System (FleetAutoScaler) DGS Allocated DGS Allocated ・
・ ・ DGS Ready DGS Shutdown ▼Fleet Fleetは、ここでいうDGSのセットのようなもの。 主要な状態として、Ready・Allocated・Shutdownがある。 FleetAutoScalerにより、オートスケールが行われる。
「#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
「#REALITY釣り部」で使っているAgones Fleet DGS Shutdown ・ ・ DGS Ready DGS
Ready Buffer Size Fleet ・ ・ ・ DGS Ready DGS Ready Buffer Size 使用完了したShutdownのサーバーは削除されるが、Allocatedはオートス ケールから保護される。 DGS Allocated DGS Allocated
「#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に接続
DGSとクライアントの連携の話 このDGSの仕組みを クライアント側でどう対応、反映しているか
DGSとクライアントとの連携 DGSから受け取ったイベントを元に実行していく 1. 魚の出現 2. 魚とのバトル・ファイトの開始 3. 釣果の表示 4. イベントの実行
DGSとクライアントとの連携(個別の釣り) 1. DGSからイベントを送る a. ゲームの開始 b. イベントの開始通知 c. イベントの終了通知(厳密には終了イベントの開始通知) d.
魚影の移動情報、形の情報 2. クライアントからDGSにイベントを送る a. 魚が餌に食いついた b. 魚とのバトルの開始リクエスト
DGSに送ってそうで送っていないもの 1. ウキの現在位置 2. 現在のアバターのアニメーションの情報 3. UIの開いている情報 4. 持っているメダルの情報 これらはマルチゲームサーバで管理している
釣りの成功判定 1. 魚の移動情報はDGSで管理しているがウキはDGS管理していな い 2. 食いつきの判定はクライアント側で判定 3. DGSはクライアントからつついたことを受け取りステータスの更 新。つつきの成功をクライアントに送る 4.
クライアントはつつきが成功していたらタップでヒットができる 5. DGSはヒットを受け取ったらバトルの開始イベントを送る
食いつきからバトルまでの流れ 釣り人 DGS 食いついた! 釣り人 DGS 食いついてOK! 釣り人 DGS タップした!
釣り人 DGS バトル開始!
なぜこのようにしているか 1. サーバで管理している魚の位置は、あくまで「次の移動先」をやっ ているにすぎない 2. ラグなどによりサーバで見ている魚の情報とクライアントの情報は ずれることがある 3. 見た目的なところはクライアントに任せ、DGSでは整合性が取れ ているかを確認する
a. 特に他の人と同じ魚を釣ろうとしていないか、などをチェックしている
DGSとクライアントとの連携(全体イベント) 1. DGSからイベントを受け取ったら、クライアント側は受け取ったと いうメッセージ(pop)をDGSに返す 2. これによりDGSでは接続が担保されたとみなし次のイベントを実 行する ではクライアントが受け取ったメッセージを返せなかったら?
REALITYならではの技術的工夫 1. REALITYのアプリは画面配信では無い 2. バックグラウンドに行った際にマイクなどは動くがUnity部分は動 かない 3. なのでバックグラウンド中の釣りのイベントを補完する必要がある 4. そのためにDGSのイベント制御を細かく行っている
REALITYならではの技術的工夫 1. REALITYは配信アプリ 2. 視聴者がリアルタイムで配信を見にくる 3. コラボ参加をする他の配信者もいる いつ、誰が配信を見に来ても、抜けても動作の担保が必要!
視聴者・コラボ配信者の工夫 REALITYには配信を見る視聴者と、一緒に参加するコラボ参加者が いる ・視聴者はいつ入ってもゲームを見れる →どのタイミングであってもゲームの再現をする必要がある ・コラボ参加者はいつでも抜けられる →ホスト以外の誰がいつ抜けてもゲームの動作を担保する必要があ る
ゲームの視聴者 1. DGSはホストが受け取った情報を視聴者に流すようにしている 2. 視聴者はDGSに接続はしていない 3. DGSの負荷としてはゲームに参加している人のみ ホスト コラボ 視聴者
DGS
コラボ参加者の接続が切れた場合 1. コラボ参加者はDGSに接続し、メッセージを受け取ったらpopを 返す 2. 全員がpopをするまでDGSでは次のイベントを送らない 3. コラボ参加者が途中で抜けた場合、DGSではその人をpop済とし て扱う コラボ参加者は途中で抜けてもゲームが進む
ホスト コラボ 視聴者 DGS
コラボ参加者が途中で抜けた場合 1. popができなくなる 2. 接続が切れたことをDGSが検知 3. REALITY配信アプリからの退出のイベントから接続情報をアップ デート 4. そのプレイヤーが復帰することを想定しつつもイベントは進む
ホスト コラボ 視聴者 DGS pop しとこう
ホストが途中で抜けた場合 1. DGSとのやりとりができなくなる 2. ホストの復帰をDGSは待つ 3. ホストが復帰したら再開 ホスト コラボ 視聴者
DGS ホストの 復帰を 待とう
演出の再生の同期 1. 演出を再生して次のイベントに行く際にバックグラウンドなどにい て演出が見れないプレイヤーが想定される 2. イベントを開始していいかをプレイヤーに通知し、プレイヤー全員 の準備が整っているかをpopイベントで受け取る 3. DGSは全員からイベントのpopを受け取ることでイベントの開始 をスタートする
4. その間は他のプレイヤーは釣りに関わる操作ができない これにより重要なイベントは取り残されることを防げる
イベントの流れのまとめ ホスト コラボ 視聴者 DGS ホスト コラボ 視聴者 DGS ①このイベント再生して
OK? ③全員OK! 再生する ね! ②OK! ②OK!
まとめ 1. DGSを使うことで配信ごとにゲームのインスタンスサーバを立て られる 2. クライアントから必要な情報は別途送ることが可能 3. ユーザ一人一人を管理して途中の入退出を管理 DGSはいいぞ!
45