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へのラグ補正されたレイキャストを提供し、ディベロッパーの労力を最小限にします。

簡単な比較

機能面の比較

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はネットワーク上のステートの同期を実行するため、サーバーは各クライアントの実際のステートを管理し、チーティングを阻止します。