PUN Classic (also called PUN1) is the original and first major version of PUN. It is now replaced by PUN2 which is refactored and enhanced. We highly recommend starting new projects with PUN2 and if possible migrating existing ones from PUN1 to PUN2 by following our "Migration Notes". PUN Classic will be maintained for the coming months. We will fix important bugs and support new Unity versions but new features will be added only to PUN2.

PUNとBoltの比較

はじめに

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

Back To Top

PUN

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

Back To Top

Photon Bolt

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

Back To Top

簡単な比較

  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 (リレー経由のみ)

Back To Top

機能面の比較

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

Back To Top

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

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

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

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

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

Back To Top

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

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

Back To Top

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

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

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

Back To Top

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

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

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

Back To Top

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

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

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

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

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

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

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

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

To Document Top