マルチプレイヤーゲームの Client-Server 設計

2019-04-12   (Updated : 2019-04-22)

(この記事は現在執筆中です)

はじめに

2019 年現在、スマートフォンゲームでもマルチプレイに対応したものが増えてきた。 現代を生きるゲーム開発者にとって、「他のプレイヤーと同期的な通信を行う」ゲームの Client-Server がきちんと作れるようになっておくことは重要だ。

ここでは「スマフォで動くライトな MOBA を作る」という要件で具体的な設計と技術選定を行い、 オンラインゲーム開発の周辺技術や知識を整理する。

要件

一口にマルチプレイと言っても求められる同期性のレベルによって、最適なアーキテクチャは変わってくる。 ここでは「リアルタイムに他のユーザの座標を同期する」ような、 ある程度アクション性のあるゲームを想定する。例としては:

その他の要件は、現在の市場のニーズを鑑みつつ、以下のように設定する:

  • 日本向け(日本の通信インフラを前提とする)
  • iOS / Android で動く
    • Client は Unity (2018 以降) / C# (6 以降) で書く
  • プレイヤーはインターネットを介して通信する(キャリア回線 or 自宅 Wi-Fi)
  • Server を自分で立てる場合のインフラは AWS
  • ゲームは主にプレイヤーの管理画面と、メインのマルチプレイの 2 シーンを想定する
    • 一般的なソシャゲ向けの API サーバと、マルチプレイ用の速いサーバが必要になる
  • マルチプレイは 3 on 3 のチーム戦とする
    • ゆっくりめに移動してショットを撃ちあう
    • ゲーム中にはキャラクターと壁と、何かしら作用のあるオブジェクトが存在する
シーン遷移のイメージ

シーン遷移のイメージ

要件には含めないもの

  • ターンベースで待ち合わせを行えばよいタイプのゲーム (Hearthstone やモンスターストライクのようなゲーム)は対象としない
  • 同時プレイの規模感も MMO ではなく MO とする
    • 最大でも 10 人程度
    • PUBG や Fortnite のような 100 人のバトルロイヤルも要件には含めない
  • 対戦格闘のようなシビアな同期性が求められるものも対象としない

周辺知識の整理

周辺技術や世の事例については以下にまとめた:

  • 基礎知識 / ネットワークモデル / HTTP2 / gRPC
  • 参考になる書籍 / Web 上の記事 / 事例集
  • Photon / UNET / モノビットエンジン / MagicOnion

ネットワークモデル

どのネットワーク構成にするか、ゲームロジックをどこに置くか、などを比較検討する。

評価指標

指標 詳細
到達可能性(Reachability) どういう環境で通信が成立するか
レイテンシ / RTT 通信速度。通信経路の長さやロジックの処理時間
スケーラビリティ 1 マッチで同時に何人プレイできるか
/ ゲーム全体で同時に何人さばけるか
ユーザ体験 プレイヤーが楽しく快適に遊べるか
セキュリティ / チート耐性 ゲームがチートされないか / ユーザが安全か
経済的コスト サーバの運用費など、金銭的なランニングコスト
開発・運用コスト(認知コスト / 複雑さ) 実装・環境構築の難易度
/ 保守・運用にエンジニアの労力がどれだけ必要か

P2P (Peer-to-Peer)

※ LAN 経由や、Bluetooth によるローカルプレイは今回は対象としない

スマフォ同士が直接通信する形式。 プレイヤーの一人が Host になって Guest は Host だけに接続するスター型と、 互いに情報を送り合うフルメッシュ型がある。

  • Host-Guest 形式は Host に負荷と通信量が集中する
  • フルメッシュ型の場合でも、アイテム取得などの排他的な処理を調停する調停役は必要である
Peer-to-Peer

Peer-to-Peer

  • 大抵の端末はインターネットに直接つながってはいないので、 NAT によってグローバル ip アドレスから変換されたプライベート ip アドレスを持つ
    • そのため、アドレスを直接指定して接続する P2P を実現するには NAT 越えを行う必要がある
NAT 越え

NAT 越え

P2P 形式の最大の利点はサーバ代がかからないことだが、課題やデメリットも多い:

指標 詳細
到達可能性(Reachability) NAT 越えが必要
レイテンシ / RTT 通信経路は最短になる
フルメッシュ型では全体の通信量が多くなり通信効率が悪い
スケーラビリティ ゲーム全体のプレイ人数に対してはスケールする
1 マッチの最大人数は多くできない
ユーザ体験 サーバ形式に比べ同期処理が安定しない
セキュリティ / チート耐性 Client がロジックを持つためチート耐性が無い
経済的コスト 最も安い。サーバが無いので、プレイ人数が増えても費用が増えない
開発・運用コスト NAT 越えの解決が必要
フルメッシュ型では各プレイヤーの同期が大変
動作確認や通信のデバッグが大変そう

P2P は 1 vs 1 の格闘ゲームのような、人数が少なく同期性が重視されるゲーム向きと考えてよいだろう。 今回は基本的に P2P ではなく間にサーバを設ける形式を考える。

Client-Server モデル

単にパケットを中継するだけのリレーサーバを置く形式と、 サーバ側でゲームロジックを処理する専用サーバ形式がある:

Client-Server モデル

Client-Server モデル

Client-Server という呼び方にすると不明瞭になる場合がありそうなので、 ここではどこにロジックが置かれるかという観点で 「クライアントホスト型」 「専用サーバ型」 という呼び分けをする。

※(Web の文献を見ていると図中左のリレーサーバ形式を P2P と呼ぶ場合もあるため。 また、Client-Server と言ってもスマフォ端末がサーバを兼ねるケースもあってややこしいため)


(A) クライアントホスト型

  • ゲームロジックが Client のランタイム上に置かれる(Unity 側で実装される)
  • Client のうち一台がゲームの調停役となる(Host-Guest 方式)
  • Server はリレーサーバで、単にパケットを中継するだけ

Photon Realtime(および PUN)、 UNETモノビットエンジンクラウド などの形式。

リレーサーバのサービスを使えば Client 側だけで実装が完結するため、 マルチプレイ実装の入門として選ばれることが多そう。

指標 詳細
到達可能性(Reachability) NAT を越える
レイテンシ / RTT ホストのネットワーク環境に性能が左右される
スケーラビリティ サーバ側のスケールは容易
ホストに負荷が集中するので、1 マッチの最大人数に制約がかかる
ユーザ体験 通信が不安定な場合にゲームが継続不可能になりやすい
  また、離脱時の復帰(途中参加)が実現しづらい
ホストが有利になる(ゲストよりも先に状態の更新を知る)
セキュリティ / チート耐性 Client がロジックを持つためチート耐性が無い
経済的コスト 専用サーバと比べ、サーバ代が安く済む
開発・運用コスト Server が汎用的なもので済む
 (Client の実装だけ考えれば良くなる)
Server の知識は要らないが、Client には Host / Guest があり
  実装はそれなりに複雑になる
ホスト離脱時、ホストマイグレーションを考える必要がある


(B) 専用サーバ型

  • ゲームロジックが専用のゲームサーバ(Dedicated Game Server)上に置かれる
  • 各 Client は Server が返す情報を正として、基本的にはブラウザのように振る舞う

Unity の新しいネットワーク機能はこの方針。 世のミドルウェアを利用する場合は Photon ServerMonobit Revolution Server が対象になる。

指標 詳細
到達可能性(Reachability) NAT を越える
レイテンシ / RTT ホスト型よりは、他のプレイヤーの通信環境の影響を受けにくくなる
スケーラビリティ サーバ側を適切に負荷分散すればスケールする。
  サーバが強ければ 1 マッチの最大人数も増やせる
ユーザ体験 サーバがコントロール下にあるという意味で、安定した
  プレイ環境を提供しやすい。復帰処理が実現しやすい
セキュリティ / チート耐性 サーバでロジックが完結するのでチート耐性がある
経済的コスト リレーサーバよりもサーバの処理コストが上がるのでサーバ代がかかる
開発・運用コスト Client は Host / Guest を意識しなくて済む
Server やインフラの知見・管理コストが少なからず必要になる
Client / Server 双方の実装が必要になり、複雑度は上がる

どちらを採用するか

執筆中…