PUNとBoltの比較

はじめに

PUNとPhoton Boltは、2つの強力なゲームネットワーキング・ミドルウェアです。 2つのうちどちらを使用するかは、むずかしい選択です。 このドキュメントではこれら2つのツールを包括的かつ簡潔に比較しますので、ディベロッパー各自のニーズに応じてどちらのツールが適切かを決める際に活用してください。

PUN

PUN (Photon Unity Networking)はオリジナルのUnityネットワーキングAPIのクローンで、信頼性の高いPhoton基盤によって強化されています。 マッチメイキングに加えて、PUNにはゲームオブジェクトのステートのシリアル化(transform対応の組み込みサポートを含む)や、リモートプロシージャコールなどが含まれます。 PUNを使用すれば、ディベロッパーは何を送受信するか詳細な管理をおこなえます。また、PUNの柔軟性の高いマルチキャストに類似したルームリレー通信モデルはゲームネットワーキングを実施するうえで非常に役立ちます。

Photon Bolt

Photon Boltはより高度なレベルのAPIで、一連のデータ構造(Boltアセットと呼ばれるステート、オブジェクト、イベントおよびコマンドです)によってディベロッパーはネットワーク化が可能なゲームステートを定義できます。また、これらのアセットをゲームオブジェクトのプレハブと連携できます。 コールバックによる増強やイベントおよびコマンドのトリガーによって、Boltのネットワーキングモデルは最新の圧縮やクライアント側での予測、Unityへのラグ補正されたレイキャストを提供し、ディベロッパーの労力を最小限にします。

簡単な比較

  PUN/ PUN+ Bolt
CCU費用 PUN: 無料20CCU
PUN+: ワンタイム 17,339円 = 100CCU(60ヶ月間有効)  
無料20CCU
ワンタイム 17,339円 = 100CCU(60ヶ月間有効)
マッチメイキング
ルームおよびロビーのサポート
フィルタリング
NetCode
ビット圧縮
ラグ補正
ホストマイグレーション (組み込みではない)
自動複製
インタレスト管理 (インタレストグループ) (範囲/優先順位付け)
オフラインモード
接続性
パンチスルー (不要) (STUN)
LAN (ライセンスにインターネットアクセスが必要な場合があります)
Relay (およびSteam/XB1/PSNアドオン)
マルチキャスト
ヘッドレスサーバー
プラットフォームサポート
コンソール (XB1/PSN/Nintendo Switch機能が必要) (XB1/PSNアドオン)
WebGL (WSS)
Steamとのインテグレーション (組み込みではない) (アドオン)
Unityサポート
Unity 4 FREE: ウェブ、スタンドアロン
Unity 4 FREE: iOS、Android (PUN+が必須)
Unity 5
自動Mecanimネットワーキング (一部)
PlayMakerとのインテグレーション (一部)
バックエンド
オーソリテーティブサーバー (Photonオンプレミス)
ゲームサーバープラグイン (エンタープライズクラウドおよびセルフホスティングのみ) (リレー経由のみ)
マスターサーバー
カスタム認証 (リレー経由のみ)
WebhookおよびWebRPC (リレー経由のみ)

機能面の比較

Photon BoltとPUNはそれぞれに強みとその根拠があります。 ここでは、ゲームネットワーキングの類似した分野に影響をおよぼす、それぞれの機能について比較しながらBoltとPUNの重要な相違点を説明します。

ホストクライアント(Bolt)vs. 専用サーバー(PUN)

PUNでは接続可能な専用サーバーがあり、このサーバーにはルームが実際に存在しています。 ルームを作成したクライアントが最初にルームに参加します。 このクライアントはマスタークライアントとして、ルーム内の全員に認識されます。 マスタークライアントはホストでも、サーバーでもありません。他の事柄を実行できる特別なクライアントです(擬似オーソリテーティブ)。

Boltでは、Boltクライアントの1つがサーバーとして作動する必要があります。つまり専用サーバーまたは実際のホストとしてです。 これは少し分かりづらいかもしれませんので、以下で説明します:

  • PUNでは、マスタークライアントが停止すると他のアクター(利用可能な場合)は新たなマスタークライアントとなります。 また、新たなマスタークライアントが設定されるまでクライアントは増加しません。
  • 一方Boltでは、サーバーは「静的」です。ゲームを開始し、サーバーになることを選択した「クライアント」がサーバーとなり、その後もサーバーであり続けます。 ホストクライアント(サーバー)が停止しても、他のクライアントはサーバーにはなりません(そして、当然のことながらこれらはすべて切断されます。)。

まとめると、Boltではホストが切断するとゲームが終了します。 また、pingとレイテンシーはホスティングプレイヤーへの接続に依存します。

イベント(Bolt)vs. RPCs (PUN)

PUN(およびその他の多くのUnity対応ネットワーキングソリューション)とBoltのもっとも顕著な違いは、BoltにはRPC(すなわち「リモートプロシージャコール」)の概念がない点です。 PUNでは、RPCはすべての(または選択した)クライアントに「このメソッドをすぐに実行してください」と伝えるための方法です。 一方Boltは、同じ機能を実行するのに「イベント」を使用します。

自動ステート複製(Bolt)vs. 柔軟性(PUN)

Boltでは、シリアル化コードを書く必要がありません。 ゲームステートの表示用に作成したアセットにもとづき、Boltのコンパイラーによってすべて生成されます。 これによりコーディングの時間が大幅に短縮され、圧縮などその他の機能も利用できるようになります。 ただし、これは何がどのようにネットワークに送信されるかについて、完全な管理はおこなえないという点も意味しています。

PUNでは独自のシリアル化ルーチンを記述し、何を送受信するかを決定します。 こうしてカスタムの予測機能を記述でき、どのクライアントがそれぞれの情報を受信するのかを独自のコードで決定できます。

ビット圧縮(Bolt)とメッセージ効率性(PUN)

Boltのコード生成はオブジェクトステートのシリアル化を考慮するため、最新の圧縮を利用できます。これによって複雑なゲームステートをネットワーキングする際のトラフィックを大幅に節減できます。 しかし、Boltのメッセージは常にホスティングマシンを経由しなければなりません。リレー経由でゲームを実行し、オーソリテーティブなサーバーロジックを使用していない場合も該当します。 これによって、Boltにもとづいて開発されたゲームではさらにレイテンシーが追加されます。

PUNはこういった影響を受けません。これはデフォルトでPUNのシリアル化コードがクライアントから他のすべてのピアへ、リレー経由でデータを送信するためです(マスタークライアントを経由する必要はありません)。 ここでPUNに発生する問題は、ディベロッパーは独自のシリアル化コードを書くため、デフォルトのままでは最新の圧縮を利用できない点です(プログラマーは自身で実装をおこなう必要があります)。

クライアント側での予測とラグ補正(Bolt)vs. オーソリテーティブサーバーの可能性 (PUN)

一般的にチーティングを阻止するにはオーソリテーティブなサーバーコードの記述が必要で、これはどのゲームネットワークディベロッパーも直面する問題です。 つまり、サーバーの制御はクライアント側からおこなえます。また、必要に応じてクライアントに返送するデータを修正できます。

Boltを使用すれば、クライアント側の予測アーキテクチャ(コマンドおよびレスポンス)とラグ補正されたシューティングの第1レイキャストによって、オーソリテーティブサーバーゲームの実装が飛躍的に単純化します(サーバー時間の近似ヒットボックスバッファにもとづきます)。 結果的にディベロッパーは分かりやすいAPIを使用するだけで、業界で長年培われてきたFPSとアクションゲームの実績を自動的に利用することができます。

このような完全にオーソリテーティブ(しばしば専用)サーバーを用いる方法で問題になるのがコストです。 複雑なシミュレーションに対応するため高いCPU負荷を処理する必要があるサーバーをホスティングすると、ゲームのレンダリングのコストが増大する可能性があります。

PUNを使用すれば、クライアントからのすべてのカスタムのシリアル化メッセージに1対1で適合する サーバーサイドのプラグイン を記述することができます。このプラグインは遮断できるため、他の者に渡される前にブロックまたは修正することが可能です。 これは非常に柔軟性の高いAPIで、Photonサーバー自体への実装に必要なロジックは最小限におさえられます。このため、サーバーコストをさらに容易に管理できるようになります。

Boltのメッセージパッキングと圧縮の場合、このアプローチは不可能ではありませんが実行は困難です。

PUNでは、理論上はサーバープラグインを使用せずマスタークライアントにもとづいて擬似的なオーソリテーティブ機能を実現することが可能です。 ただし、この場合はマスタークライアント(およびマスタークライアントになる可能性があるものすべて)は各クライアントのステートを完全に正しく維持する必要があります。これは非常に困難です。 この問題を解決するためにBoltが用いるものこそが、クライアントステートです。

FPSゲームでは、典型的な「プレイヤーステート」には各プレイヤーの位置、速度、カメラピッチなどが含まれます。 BoltではこれらのステートはBolt独自のUnityエディター拡張で定義されるため、すべてがユーザーフレンドリーとなります、また処理面では型安全が保たれます。 Boltはネットワーク上のステートの同期を実行するため、サーバーは各クライアントの実際のステートを管理し、チーティングを阻止します。

 ドキュメントのトップへ戻る