【Unite Tokyo 2019】Unityだったら簡単！マルチプレイ用ゲームサーバ開発 ～実践編～
•
16 likes•65,507 views
2019/9/25-6に開催されたUnite Tokyo 2019の講演スライドです。 小端 みより（株式会社ミクシィ） こんな人におすすめ ・Unityでより本格的なマルチプレイのゲームを作りたい方 ・そもそも通信や同期処理ってどうやって実装するの？という方 受講者が得られる知見 ・Unityで専用サーバを開発するメリットやその方法 ・Unityでサーバとクライアントを同時に開発するテクニック ・通信に関する知識、専用サーバを運用する方法 Unityのイベント資料はこちらから： https://www.slideshare.net/UnityTechnologiesJapan/clipboards
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 【Unite Tokyo 2019】Unityだったら簡単！マルチプレイ用ゲームサーバ開発 ～実践編～
Similar to 【Unite Tokyo 2019】Unityだったら簡単！マルチプレイ用ゲームサーバ開発 ～実践編～ (20)
More from UnityTechnologiesJapan002
More from UnityTechnologiesJapan002 (20)
Recently uploaded
Recently uploaded (10)
【Unite Tokyo 2019】Unityだったら簡単！マルチプレイ用ゲームサーバ開発 ～実践編～
- 6. クライアント処理型 6 リレーサーバを用いたマルチプレイ実装なので 次のようなメリットがある — 対応したミドルウェアやサービスが豊富 — クラウド型のサービスならサーバ不要であり手軽 — クライアントで完結するのでプロトタイピングに最適
- 7. その一方で 7 — クライアント処理なのでチートされやすく 通信も不安定になりやすい （ホストマイグレーションなど） — 実装が複雑化しやすい傾向にあり大人数もしくは 大規模なタイトルの開発は難しい と決して万能ではない
- 9. でも専用サーバ開発って 9 — サーバを実装するのって言語とかが違って難しそう — どうやって作ればよいのかわからない — クライアント処理型の手軽さに及ばない こういったネガティブな印象がある気がする・・
- 12. Unityサーバは 12 その名の通りUnityで作る専用サーバなので — 我々が得意（ですよね？）とするC#で実装できる — Unityの機能、AnimationやPhysicsやAIを活用できる — サーバとクライアントを同時に単一プロジェクトで開発 などなど
- 14. 目標を高めに設定 14 技術難易度の高いことに挑戦すれば幅広いゲームジャンルに 対応できるはず・・という理由で — アクション性の高いオンラインマルチプレイのゲーム — サーバとクライアントを単一Unityプロジェクトで作成 （サーバはLinux、クライアントはiOS/Android上で動作） — サーバをクラウド上で動作させ20人以上でマルチプレイ
- 15. おおまかな設計 15 — サーバ集中処理型の通信モデルを採用し 上り/下り共に非同期的に最大で毎秒30回の通信を行う — ゲームは60FPSで動作し （物理は30FPS） DOTSでなく使い慣れたコンポーネントモデルを採用 — サーバ/クライアント間でコードおよびアセットを共有し Editor上で任意にサーバやクライアントを実行可能
- 16. サーバ集中処理型とは 16 非常にシンプルな構成ですね クライアント A ゲームサーバ 1. 入力を送信 2. アップデート 3. 結果を送信 クライアント B 4. 結果を表示
- 20. ７つの課題とは 20 Q1 どの通信ライブラリを使えばいい？ Q2 TCPとUDPどっちを使う？ Q3 再送制御による遅延を回避するには？ Q4 MTUって何？ Q5 ラグはなくせるのか？ Q6 サーバとクライアント同一プロジェクトで管理できる？ Q7 専用サーバをどうやって運用したらいい？
- 22. Unity公式のもの 22 （UNETのことはもう忘れよう・・） — Unity Transport Package （com.unity.transport） https://github.com/Unity-Technologies/multiplayer — マニュアルやサンプルプロジェクトを見れば簡単 — DOTSなどの新機能にも対応 — ただし現時点においてプレビュー版である点に注意
- 23. 非公式ライブラリ 23 非公式のC#で書かれた通信ライブラリも利用可能 — 例としてはLiteNetLib https://github.com/RevenantX/LiteNetLib — RUDP（TCPライクに扱えるUDP）通信ライブラリ — 認証付きコネクションやMTU探索、IPv6にも対応 — こちらもシンプルで扱いやすい
- 24. Unity公式ブログに 24 ゲーム設計によってどんな実装を行うのが望ましいかという フローチャートがあるのでこちらもご覧ください Navigating Unity’s multiplayer Netcode transition https://blogs.unity3d.com/2019/06/13/navigating-unitys- multiplayer-netcode-transition/
- 27. 初めて使うならTCP 27 — ポピュラーなので情報が多い（HTTPやWebSocketもこれ） — プロトコルとしての信頼性が高く扱いやすい — なので通信実装の入門用に最適 ただし — リアルタイム性を要求される通信において問題がある
- 29. 再送制御による遅延の問題 29 一旦パケットロスが生じて再送制御が行われている間、 順序制御により以後の受信がドミノ倒し的に遅延してしまう 受信側 送信側 1 2 3 4 5 6 1 （2はまだ・・？） 2 2,3,4,5
- 30. TCPの設計思想は 30 ”どんなに遅れても順序通り必ず届く” なので仕方がない しかしこの特性は 毎秒何十回という頻度で通信を行い、即時到達性が要求 されるゲーム用途において、非常に致命的である
- 31. 結論 31 — 情報の充実性や信頼性においてTCPは優れており、 入門用に最適である — 一方遅延を生じやすい性質のため、 アクション性を重視するゲームジャンルに適さず 我々はTCPを採用しなかった
- 33. そこで出番のUDP 33 — データグラムと呼ばれるシンプルな通信操作のみ行える — コネクション処理も再送制御も順序制御も存在しない — だから遅延が生じにくい — 逆に信頼性を要求される用途では工夫が必要
- 36. 冗長化の例 3636 受信側 送信側 1,-,- 1 2 3,4 5 2,1,- 3,2,1 4,3,2 5,4,3 再送制御なしでも冗長性の範囲ならメッセージを復元できる
- 37. 結論 37 — UDPは低遅延である一方で信頼性に問題がある — しかしUDPとメッセージの冗長化を組み合わせることで TCPでは難しかった低遅延と信頼性が両立できるので 我々はこの方法を採用した
- 38. 38 Q4 MTUって何？
- 39. MTUとは 39 — 1回の通信で転送可能なデータグラムの上限サイズ ≒ メッセージサイズの上限 — そのサイズわずか576～1500バイト （通信経路によって変動する） — 超過した場合はパケットの分割が行われるか そもそも到達しない
- 40. つまり 40 一度に送信できるメッセージのサイズは限られる上に、 前記の冗長化テクニックと組み合わせるとさらに少なくなる （MTU 1500 / 3 で１フレームあたり 500バイト以下とか・・） なのでメッセージサイズをギリギリまで削減する必要がある
- 41. メッセージサイズを削減するには 41 — プレイヤーの視界外のオブジェクトをカリングする — 対象オブジェクトとの距離や優先順位に応じて 通信頻度を落とし、通信のタイミングを分散させる — データそのものを圧縮する float -> half 変換などが定番 （値域と精度に注意）
- 46. 46 Q5 ラグはなくせるのか？
- 47. ラグはなぜ発生するのか 47 一般に ”ラグ ＝ 通信遅延” と思われがちだが 近年の通信環境の改善により、国内であれば通信遅延は 非常に小さい （東京都内～データセンタ間で1、2ミリ秒） 実際には、前記の再送制御により生じる一時的な遅延や 通信サイクルに起因する遅延の影響が大きい
- 48. そもそもオフラインゲームでは 48 タイミング次第で入力の反映に17ミリ秒の揺れ幅が生じる 17ミリ秒 （＝ 1000 / 60） アップデート レンダリング待機ダリング 待機 入力の反映
- 51. 時刻差異を利用する例 51 — サーバと各クライアント間でゲーム時刻を同調しておく — サーバでは送信する際にメッセージにその時点の ゲーム時刻を書き出しておく — クライアントはこのメッセージ上の時刻とクライアントの 時刻の差異を利用し、体感上のラグを相殺できる
- 52. 例えば位置予測 52 #1: 0.00秒 （0.0, 0.0) #2: 0.10秒 （2.0, 1.0) 今（予測）: 0.15秒 （3.0, 1.5) 前回の時刻および座標から、現時点の位置を予測できる
- 58. コードの分割 58 — サーバとクライアント間で共有したくないコードは AssemblyDefinition を使用すれば除外することができる （ただし異なるアセンブリ間は循環参照できないので注意） — ただし現状（Unity2019.1）、DefineConstraints （シンボル定義に応じ含める/含めないを切り替えられる） の挙動が怪しいので今後の修正に期待したい
- 61. ホスティングサービスの利用 61 — 例としてはAWSのGameLiftというサービス https://aws.amazon.com/jp/gamelift/ — ゲームサーバのホスティングに特化されている — サーバのバイナリをアップロードすれば、起動や監視 オートスケーリングなどの運用を自動でやってくれる — Unity向けのSDKも提供されている
- 66. これらは結局どうだった？ 66 — クライアント処理型で難しかった チート耐性や通信の安定性、大人数や大規模なゲーム — 専用サーバのネガティブな印象 言語、作り方がわからない、手軽さが損なわれないか — サーバ集中処理型の懸念点 遅延がどの程度影響するのか、ゲームとして成立するのか
- 67. これらは結局どうだった？ 67 — クライアント処理型で難しかった チート耐性や通信の安定性、大人数や大規模なゲーム — 専用サーバのネガティブな印象 言語、作り方がわからない、手軽さが損なわれないか — サーバ集中処理型の懸念点 遅延がどの程度影響するのか、ゲームとして成立するのか
- 69. 通信の安定性は 69 — ほんとうに通信状態が悪い場合、を除き安定的に動作した — とはいえ WiFi <-> キャリア回線 の切り替わりなどでは 切断を生じるため、再接続および復帰処理の実装が重要
- 71. これらは結局どうだった？ 71 — クライアント処理型で難しかった チート耐性や通信の安定性、大人数や大規模なゲーム — 専用サーバのネガティブな印象 言語、作り方がわからない、手軽さが損なわれないか — サーバ集中処理型の懸念点 遅延がどの程度影響するのか、ゲームとして成立するのか
- 72. やってみると意外に簡単 72 — やはりC#や.NETなど普段から使い慣れているUnityの 開発環境がそのまま使えるメリットは大きい — もちろんネットワークの知識は必要とされるものの そこを身に着けさえすれば、通常の開発とそう大差はない — Unityだからこそのデバッグのしやすさもある
- 73. 手軽さも損なわれない 73 — サーバとクライアントが単一プロジェクトで完結できる という点では手軽 — もっとも、ホスティングサービス上でサーバを動作させる ため更新の都度、バイナリをデプロイする必要があり手間 — ローカル環境上でサーバを起動し、クライアントから 直接接続できるしくみを用意しておくと捗る
- 74. これらは結局どうだった？ 74 — クライアント処理型で難しかった チート耐性や通信の安定性、大人数や大規模なゲーム — 専用サーバのネガティブな印象 言語、作り方がわからない、手軽さが損なわれないか — サーバ集中処理型の懸念点 遅延がどの程度影響するのか、ゲームとして成立するのか
- 75. 遅延も対策すれば怖くない 75 — 通信ライブラリのドロップ＆遅延シミュレーションの機能で 低品質な通信環境を前提としたテストが行える — これによりUDP＋冗長化や、位置予測などの遅延対策が 正しく動作することを確認できた — ダメ元で50ms程度遅延させてみたところ・・ “まあ、すごくラグいけど操作できなくもない”
- 77. 77 そして・・
- 78. 社内プレイ会のもよう 78
- 79. その他ここがよかった 79 — 使い慣れた言語＆エンジンなので、通信のハードルさえ 乗り越えればゲームロジックの実装に集中できる — Editor上で直接サーバとクライアントをデバッグや プロファイリングできるので作業効率が高かった — Unityを扱える企画メンバーがゲームを直接、拡張できる