【Unite Tokyo 2019】Unityだったら簡単！マルチプレイ用ゲームサーバ開発～実践編～

2. Unityだったら簡単！マルチプレイ用ゲームサーバ開発～実践編～株式会社ミクシィ小端みより

3. 3 小端みより（ゲームエンジニア）コンシューマゲーム業界から株式会社ミクシィに入社未発表タイトルを含む、複数の新規タイトル開発を行う（すべてがオンラインマルチプレイ対応）自己紹介

4. Unityサーバを作るまで 4

5. 5 リレーサーバを用いたマルチプレイ実装が主流これは結局のところP2P型の通信モデルなので、サーバは原則的にロジックに関与しないつまりクライアント処理型の実装ということこれまでのマルチプレイ実装

6. クライアント処理型 6 リレーサーバを用いたマルチプレイ実装なので次のようなメリットがある — 対応したミドルウェアやサービスが豊富 — クラウド型のサービスならサーバ不要であり手軽 — クライアントで完結するのでプロトタイピングに最適

7. その一方で 7 — クライアント処理なのでチートされやすく通信も不安定になりやすい（ホストマイグレーションなど） — 実装が複雑化しやすい傾向にあり大人数もしくは大規模なタイトルの開発は難しいと決して万能ではない

8. それならば 8 クライアント処理型で難しかった — チート耐性および通信の安定性を備え持ち — リアルタイムで大人数、大規模なマルチプレイゲームこれらを実現するために、専用サーバを用いたサーバ処理型の実装にすればよい？

9. でも専用サーバ開発って 9 — サーバを実装するのって言語とかが違って難しそう — どうやって作ればよいのかわからない — クライアント処理型の手軽さに及ばないこういったネガティブな印象がある気がする・・

10. 極論として 10 PU〇GやF〇rtniteのようなゲームを気軽に開発できるようなそんな便利な方法があったら嬉しいですよね（いや・・そんなことできるのか・・・？？？？？？？）

11. 11 我々にはUnityがあります！

12. Unityサーバは 12 その名の通りUnityで作る専用サーバなので — 我々が得意（ですよね？）とするC#で実装できる — Unityの機能、AnimationやPhysicsやAIを活用できる — サーバとクライアントを同時に単一プロジェクトで開発などなど

13. 13 よさそうですね・・？というわけで実際に作ってみます

14. 目標を高めに設定 14 技術難易度の高いことに挑戦すれば幅広いゲームジャンルに対応できるはず・・という理由で — アクション性の高いオンラインマルチプレイのゲーム — サーバとクライアントを単一Unityプロジェクトで作成（サーバはLinux、クライアントはiOS/Android上で動作） — サーバをクラウド上で動作させ20人以上でマルチプレイ

15. おおまかな設計 15 — サーバ集中処理型の通信モデルを採用し上り/下り共に非同期的に最大で毎秒30回の通信を行う — ゲームは60FPSで動作し（物理は30FPS） DOTSでなく使い慣れたコンポーネントモデルを採用 — サーバ/クライアント間でコードおよびアセットを共有し Editor上で任意にサーバやクライアントを実行可能

16. サーバ集中処理型とは 16 非常にシンプルな構成ですねクライアント A ゲームサーバ 1. 入力を送信 2. アップデート 3. 結果を送信クライアント B 4. 結果を表示

17. ただし 17 次のような懸念点が考えられる — サーバ集中処理型は設計をシンプルにできる一方でネットワーク遅延の影響が大きそう — 特にアクションゲームにおいてどれほど影響を与えるのかそもそもちゃんとゲームプレイが成立するのか

18. 18 と、いう感じで我々は Unityサーバの開発を開始したのであった・・そして、その中で直面した課題とその解決方法について次章で説明していきます

19. Unityサーバ７つの課題と解決法 19

20. ７つの課題とは 20 Q1 どの通信ライブラリを使えばいい？ Q2 TCPとUDPどっちを使う？ Q3 再送制御による遅延を回避するには？ Q4 MTUって何？ Q5 ラグはなくせるのか？ Q6 サーバとクライアント同一プロジェクトで管理できる？ Q7 専用サーバをどうやって運用したらいい？

21. 21 Q1 どの通信ライブラリを使えばよい？

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/

25. 結論 25 — 公式のMultiplayerパッケージがわかりやすく新機能もサポートしているが、まだ開発中なので注意 — 現時点においてはLiteNetLibのようなライブラリが選択肢となるため、我々はこれを採用した

26. 26 Q2 TCPとUDPどっちを使う？

27. 初めて使うならTCP 27 — ポピュラーなので情報が多い（HTTPやWebSocketもこれ） — プロトコルとしての信頼性が高く扱いやすい — なので通信実装の入門用に最適ただし — リアルタイム性を要求される通信において問題がある

28. なぜTCPは信頼できる？ 28 — 確認応答(Ack)および再送制御相手に届いたことが確認できるまで送信を繰り返すのでコネクションが維持されている限り必ず届く — 順序制御受信時シーケンス番号をもとに並び替えが行われるので送信順序と受信順序が必ず一致する

29. 再送制御による遅延の問題 29 一旦パケットロスが生じて再送制御が行われている間、順序制御により以後の受信がドミノ倒し的に遅延してしまう受信側送信側 1 2 3 4 5 6 1 （2はまだ・・？） 2 2,3,4,5

30. TCPの設計思想は 30 ”どんなに遅れても順序通り必ず届く” なので仕方がないしかしこの特性は毎秒何十回という頻度で通信を行い、即時到達性が要求されるゲーム用途において、非常に致命的である

31. 結論 31 — 情報の充実性や信頼性においてTCPは優れており、入門用に最適である — 一方遅延を生じやすい性質のため、アクション性を重視するゲームジャンルに適さず我々はTCPを採用しなかった

32. 32 Q3 再送制御による遅延を回避するには？

33. そこで出番のUDP 33 — データグラムと呼ばれるシンプルな通信操作のみ行える — コネクション処理も再送制御も順序制御も存在しない — だから遅延が生じにくい — 逆に信頼性を要求される用途では工夫が必要

34. UDPで信頼性を得るには 34 RUDP（ReliableUDP）として知られる実装が有効ただしこれは一般に、再送制御や順序制御をUDP上で実装したものであって TCP同様に再送制御による遅延が発生するではどうするか・・？

35. “Redundant”UDP 35 — 送信メッセージを冗長化させることにより一定のパケットロス耐性を持たせた実装 — ただし冗長性を上回る量のパケットロスが発生した場合対処できないため別途、復帰処理を実装する必要がある

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 変換などが定番（値域と精度に注意）

42. カリングおよび通信分散 42 プレイヤーキャラクタやNPC、近くのオブジェクトを優先 2 3 4 1

43. デルタ圧縮 43 その他にはデルタ圧縮というテクニックもある — 送信内容をキャッシュしておく — 次回の送信時にキャッシュと比較し更新されたオブジェクトやプロパティのみを送信する（全く更新されていないなら、そもそも送信を行わない）

44. またZlibなどの 44 圧縮ライブラリを組み合わせる手もあるが・・ — 圧縮後のサイズがわからないと使いづらい（逐次圧縮可能なライブラリならあるいは） — 前記のテクニックにより元々のデータが効率的な配列になっている場合はあまり有効でなかったりする

45. 結論 45 — UDPのメッセージサイズはMTUに依存するだけでなく冗長化テクニックにより、さらに制限される — 我々はカリングやデルタ圧縮などのテクニックを組み合わせることにより、メッセージサイズを削減することにした

46. 46 Q5 ラグはなくせるのか？

47. ラグはなぜ発生するのか 47 一般に ”ラグ＝通信遅延” と思われがちだが近年の通信環境の改善により、国内であれば通信遅延は非常に小さい（東京都内～データセンタ間で1、2ミリ秒）実際には、前記の再送制御により生じる一時的な遅延や通信サイクルに起因する遅延の影響が大きい

48. そもそもオフラインゲームでは 48 タイミング次第で入力の反映に17ミリ秒の揺れ幅が生じる 17ミリ秒（＝ 1000 / 60）アップデートレンダリング待機ダリング待機入力の反映

49. 通信サイクルによる遅延 49 通信サイクルが33ミリ秒の場合、タイミング次第で遅延に最大66ミリ秒の振れ幅が生じる Server Client ベストワースト

50. というわけで 50 オンラインゲームは宿命としてラグが発生するものであってまた遅延量に、かなりの振れ幅があるということ（遅延が一定であると見なしてはいけない）これを踏まえた上で、体感上のラグを打ち消すためのテクニックを利用したい

51. 時刻差異を利用する例 51 — サーバと各クライアント間でゲーム時刻を同調しておく — サーバでは送信する際にメッセージにその時点のゲーム時刻を書き出しておく — クライアントはこのメッセージ上の時刻とクライアントの時刻の差異を利用し、体感上のラグを相殺できる

52. 例えば位置予測 52 #1: 0.00秒（0.0, 0.0) #2: 0.10秒（2.0, 1.0) 今（予測）: 0.15秒（3.0, 1.5) 前回の時刻および座標から、現時点の位置を予測できる

53. 結論 53 — オンラインゲームにおいてラグは宿命であり、なおかつ遅延の量は常に一定ではない — 我々はサーバとクライアント間の時刻差異を利用した位置予測などのテクニックで体感上のラグを打ち消すことにした

54. 54 Q6 サーバとクライアント同一プロジェクトで管理できる？

55. 同一プロジェクトだと 55 — サーバとクライアントで使用するアセットやコードが混在 — しかしサーバ実行時にTextureやAudioClipは必要ない（消費メモリやロード時間が長くなるだけ）つまりビルド設定に応じて使用するアセットを切り替えられることが望ましい

56. シーンおよびアセットは 56 — その名称だけでサーバ用なのかクライアント用かを区別できるようにしておく（名称に”_Client”のようなサフィックスを含めるなど） — こうしておけばビルド用のスクリプトで対象外のアセットを除外することができる

57. 57 サーバ実行時のシーンビュー（Rendererなどを除去）クライアント実行時の Editorシーンビュー

58. コードの分割 58 — サーバとクライアント間で共有したくないコードは AssemblyDefinition を使用すれば除外することができる（ただし異なるアセンブリ間は循環参照できないので注意） — ただし現状（Unity2019.1）、DefineConstraints （シンボル定義に応じ含める/含めないを切り替えられる）の挙動が怪しいので今後の修正に期待したい

59. 結論 59 — 各シーンやアセットがサーバ用かクライアント用か判別できるようにしおけば、ビルド時に切り替えられる — AssemblyDefinitionを使えば使用するコードの切替も可能であり、我々はビルド用スクリプトでそれらを切り替えられるようにした

60. 60 Q7 専用サーバをどうやって運用したらいい？

61. ホスティングサービスの利用 61 — 例としてはAWSのGameLiftというサービス https://aws.amazon.com/jp/gamelift/ — ゲームサーバのホスティングに特化されている — サーバのバイナリをアップロードすれば、起動や監視オートスケーリングなどの運用を自動でやってくれる — Unity向けのSDKも提供されている

62. 注意点として 62 — 一般的なEC2インスタンスではGPUをサポートしていないので、サーバはHeadlessモードでビルドする必要がある

63. その他にも 63 Azureなどホスティングサービスの選択肢があり、今後はUnity公式のホスティングサービスも開始されるはず専用サーバの利用はより手軽になっていくことが予想される

64. 結論 64 — ホスティングサービスを利用することで、専用サーバは比較的手軽に運用することができる — 我々はホスティングサービスのうちのひとつである GameLiftを利用する事にした

65. Unityサーバを開発してみてまとめ 65

66. これらは結局どうだった？ 66 — クライアント処理型で難しかったチート耐性や通信の安定性、大人数や大規模なゲーム — 専用サーバのネガティブな印象言語、作り方がわからない、手軽さが損なわれないか — サーバ集中処理型の懸念点遅延がどの程度影響するのか、ゲームとして成立するのか

68. チート耐性は 68 — サーバ集中処理型はクライアント側で行える操作が限られるため基本的にチート耐性は高いと考えられる — とはいえ、パケット分析による自動化ツール作成などが想定されるため、通信の暗号化を行う必要がある

69. 通信の安定性は 69 — ほんとうに通信状態が悪い場合、を除き安定的に動作した — とはいえ WiFi <-> キャリア回線の切り替わりなどでは切断を生じるため、再接続および復帰処理の実装が重要

70. 大人数や大規模なゲームにも 70 — プロファイラを使用しサーバの通信処理を最適化最終的に1スレッドあたり40人程度まで捌けるように — 無論このあたりの数値はゲームデザインに依存するものであり、逆にリアルタイム性が重視されないジャンルならば 100人規模であっても対応できるのではないか

72. やってみると意外に簡単 72 — やはりC#や.NETなど普段から使い慣れているUnityの開発環境がそのまま使えるメリットは大きい — もちろんネットワークの知識は必要とされるもののそこを身に着けさえすれば、通常の開発とそう大差はない — Unityだからこそのデバッグのしやすさもある

73. 手軽さも損なわれない 73 — サーバとクライアントが単一プロジェクトで完結できるという点では手軽 — もっとも、ホスティングサービス上でサーバを動作させるため更新の都度、バイナリをデプロイする必要があり手間 — ローカル環境上でサーバを起動し、クライアントから直接接続できるしくみを用意しておくと捗る

75. 遅延も対策すれば怖くない 75 — 通信ライブラリのドロップ＆遅延シミュレーションの機能で低品質な通信環境を前提としたテストが行える — これによりUDP＋冗長化や、位置予測などの遅延対策が正しく動作することを確認できた — ダメ元で50ms程度遅延させてみたところ・・ “まあ、すごくラグいけど操作できなくもない”

76. むしろ・・ 76 モバイル機器では負荷の高いPhysicsなどの処理をオフロードでき、クライアントの負荷を軽減できる

77. 77 そして・・

78. 社内プレイ会のもよう 78

79. その他ここがよかった 79 — 使い慣れた言語＆エンジンなので、通信のハードルさえ乗り越えればゲームロジックの実装に集中できる — Editor上で直接サーバとクライアントをデバッグやプロファイリングできるので作業効率が高かった — Unityを扱える企画メンバーがゲームを直接、拡張できる

80. 今後の課題 80 — サーバとクライアントのコードが混在しているがゆえの紛らわしさがあるため、より分離性のある設計にしたい — Unityサーバ開発を基盤化し、他のプロジェクトでも手軽に扱えるようにしたい今後、機会があればもっとUnity寄りの話などできれば・・

81. 81 本講演は以上です皆様もぜひ試してみてください

82. ご清聴ありがとうございました 82 Ver. 2019_09_24_1

【Unite Tokyo 2019】Unityだったら簡単！マルチプレイ用ゲームサーバ開発～実践編～

【Unite Tokyo 2019】Unityだったら簡単！マルチプレイ用ゲームサーバ開発～実践編～

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente(20)

Similar a 【Unite Tokyo 2019】Unityだったら簡単！マルチプレイ用ゲームサーバ開発～実践編～

Similar a 【Unite Tokyo 2019】Unityだったら簡単！マルチプレイ用ゲームサーバ開発～実践編～(20)

Más de UnityTechnologiesJapan002

Más de UnityTechnologiesJapan002(20)

Último

Último(9)