Engine続行するにはJavascriptを有効化してください。Realtimeインディーかプロのディベロッパーかを問わず、誰でもリアルタイムマルチプレイヤーゲームを開発してグローバルに配信可能です。PUNインディーかプロのディベロッパーかを問わず、誰でもリアルタイムマルチプレイヤーゲームを開発してグローバルに配信可能です。Quantumマルチプレイヤーゲーム開発の革新に参加しよう!MOBA、ブローラー、RTS、戦闘ゲーム、スポーツゲームを迅速な予測ネットワーキングエンジンで開発できます。Chat同時接続数をスケールできるクロスプラットフォームのチャットシステムをあなたのアプリに簡単に統合できます。Voice大規模かつインターナショナルな最先端のライブボイスチャット。すべてのマルチプレイヤーエンジンと併用可能。Classic(PUN1とも呼ばれます)はPUNのはじめの主要バージョンです。現在は、リファクタリングおよび機能拡張されたPUN2に切り替わっています。新しいプロジェクトはPUN2をご利用いただき、また可能であれば既存のプロジェクトについてもPUN1からPUN2へ移行していただくよう強く推奨しています。Cloassicは今後数か月メンテナンスされます。重要なバグの修正や新しいUnityバージョンのサポートは行いますが、新機能の追加はPUN2のみとなります。Boltは、2つの強力なゲームネットワーキング・ミドルウェアです。2つのうちどちらを使用するかは、むずかしい選択です。このドキュメントではこれら2つのツールを包括的かつ簡潔に比較しますので、ディベロッパー各自のニーズに応じてどちらのツールが適切かを決める際に活用してください。Networking)はオリジナルのUnityネットワーキングAPIのクローンで、信頼性の高いPhoton基盤によって強化されています。マッチメイキングに加えて、PUNにはゲームオブジェクトのステートのシリアル化(transform対応の組み込みサポートを含む)や、リモートプロシージャコールなどが含まれます。PUNを使用すれば、ディベロッパーは何を送受信するか詳細な管理をおこなえます。PUNの柔軟性の高いマルチキャストに類似したルームリレー通信モデルはゲームネットワーキングを実施するうえで非常に役立ちます。Boltはより高度なレベルのAPIで、一連のデータ構造(Boltアセットと呼ばれるステート、オブジェクト、イベントおよびコマンドです)によってディベロッパーはネットワーク化が可能なゲームステートを定義できます。これらのアセットをゲームオブジェクトのプレハブと連携できます。コールバックによる増強やイベントおよびコマンドのトリガーによって、Boltのネットワーキングモデルは最新の圧縮やクライアント側での予測、Unityへのラグ補正されたレイキャストを提供し、ディベロッパーの労力を最小限にします。BoltとPUNはそれぞれに強みとその根拠があります。ここでは、ゲームネットワーキングの類似した分野に影響をおよぼす、それぞれの機能について比較しながらBoltとPUNの重要な相違点を説明します。専用サーバー(PUN)PUNでは接続可能な専用サーバーがあり、このサーバーにはルームが実際に存在しています。ルームを作成したクライアントが最初にルームに参加します。このクライアントはマスタークライアントとして、ルーム内の全員に認識されます。マスタークライアントはホストでも、サーバーでもありません。他の事柄を実行できる特別なクライアントです(擬似オーソリテーティブ)。Boltでは、Boltクライアントの1つがサーバーとして作動する必要があります。専用サーバーまたは実際のホストとしてです。これは少し分かりづらいかもしれませんので、以下で説明します:PUNでは、マスタークライアントが停止すると他のアクター(利用可能な場合)は新たなマスタークライアントとなります。新たなマスタークライアントが設定されるまでクライアントは増加しません。Boltでは、サーバーは「静的」です。ゲームを開始し、サーバーになることを選択した「クライアント」がサーバーとなり、その後もサーバーであり続けます。ホストクライアント(サーバー)が停止しても、他のクライアントはサーバーにはなりません(そして、当然のことながらこれらはすべて切断されます。まとめると、Boltではホストが切断するとゲームが終了します。pingとレイテンシーはホスティングプレイヤーへの接続に依存します。(PUN)PUN(およびその他の多くのUnity対応ネットワーキングソリューション)とBoltのもっとも顕著な違いは、BoltにはRPC(すなわち「リモートプロシージャコール」)の概念がない点です。PUNでは、RPCはすべての(または選択した)クライアントに「このメソッドをすぐに実行してください」と伝えるための方法です。Boltは、同じ機能を実行するのに「イベント」を使用します。柔軟性(PUN)Boltでは、シリアル化コードを書く必要がありません。ゲームステートの表示用に作成したアセットにもとづき、Boltのコンパイラーによってすべて生成されます。これによりコーディングの時間が大幅に短縮され、圧縮などその他の機能も利用できるようになります。これは何がどのようにネットワークに送信されるかについて、完全な管理はおこなえないという点も意味しています。PUNでは独自のシリアル化ルーチンを記述し、何を送受信するかを決定します。してカスタムの予測機能を記述でき、どのクライアントがそれぞれの情報を受信するのかを独自のコードで決定できます。Topビット圧縮(Bolt)とメッセージ効率性(PUN)Boltのコード生成はオブジェクトステートのシリアル化を考慮するため、最新の圧縮を利用できます。これによって複雑なゲームステートをネットワーキングする際のトラフィックを大幅に節減できます。Boltのメッセージは常にホスティングマシンを経由しなければなりません。リレー経由でゲームを実行し、オーソリテーティブなサーバーロジックを使用していない場合も該当します。これによって、Boltにもとづいて開発されたゲームではさらにレイテンシーが追加されます。PUNはこういった影響を受けません。これはデフォルトでPUNのシリアル化コードがクライアントから他のすべてのピアへ、リレー経由でデータを送信するためです(マスタークライアントを経由する必要はありません)。ここでPUNに発生する問題は、ディベロッパーは独自のシリアル化コードを書くため、デフォルトのままでは最新の圧縮を利用できない点です(プログラマーは自身で実装をおこなう必要があります)。(PUN)一般的にチーティングを阻止するにはオーソリテーティブなサーバーコードの記述が必要で、これはどのゲームネットワークディベロッパーも直面する問題です。サーバーの制御はクライアント側からおこなえます。必要に応じてクライアントに返送するデータを修正できます。Boltを使用すれば、クライアント側の予測アーキテクチャ(コマンドおよびレスポンス)とラグ補正されたシューティングの第1レイキャストによって、オーソリテーティブサーバーゲームの実装が飛躍的に単純化します(サーバー時間の近似ヒットボックスバッファにもとづきます)。結果的にディベロッパーは分かりやすいAPIを使用するだけで、業界で長年培われてきたFPSとアクションゲームの実績を自動的に利用することができます。このような完全にオーソリテーティブ(しばしば専用)サーバーを用いる方法で問題になるのがコストです。複雑なシミュレーションに対応するため高いCPU負荷を処理する必要があるサーバーをホスティングすると、ゲームのレンダリングのコストが増大する可能性があります。記述することができます。このプラグインは遮断できるため、他の者に渡される前にブロックまたは修正することが可能です。これは非常に柔軟性の高いAPIで、Photonサーバー自体への実装に必要なロジックは最小限におさえられます。このため、サーバーコストをさらに容易に管理できるようになります。Boltのメッセージパッキングと圧縮の場合、このアプローチは不可能ではありませんが実行は困難です。PUNでは、理論上はサーバープラグインを使用せずマスタークライアントにもとづいて擬似的なオーソリテーティブ機能を実現することが可能です。この場合はマスタークライアント(およびマスタークライアントになる可能性があるものすべて)は各クライアントのステートを完全に正しく維持する必要があります。これは非常に困難です。この問題を解決するためにBoltが用いるものこそが、クライアントステートです。FPSゲームでは、典型的な「プレイヤーステート」には各プレイヤーの位置、速度、カメラピッチなどが含まれます。BoltではこれらのステートはBolt独自のUnityエディター拡張で定義されるため、すべてがユーザーフレンドリーとなります、また処理面では型安全が保たれます。Boltはネットワーク上のステートの同期を実行するため、サーバーは各クライアントの実際のステートを管理し、チーティングを阻止します。