This document is about: PUN 1
SWITCH TO

PUN Classic (v1)、PUN 2、Boltはメンテナンスモードとなっております。Unity2022についてはPUN 2でサポートいたしますが、新機能が追加されることはありません。お客様のPUNプロジェクトおよびBoltプロジェクトが停止することはなく、将来にわたってパフォーマンス性能が落ちることはありません。 今後の新しいプロジェクトについては、Photon FusionまたはQuantumへ切り替えていただくようよろしくお願いいたします。

よくある質問

どのPhoton製品を使用するべきでしょうか?

対象となるゲームやプロジェクトの特性によって異なります。

通常、弊社はFusion または
Quantumの使用を推奨しています。これらは、弊社のもっとも高度なクライアントソリューションです。

概要について、どちらの製品シートにも製品選びのための「Quadrant」が記載されています:

また、Photon CloudとPhoton Serverのどちらを選択すべきかは、こちらを参照ください。

ご不明点はお気軽にお問合せください。

Photon Cloud

Photon Cloudのステータスを確認する方法は?

Photon Cloudのステータスを確認するには、こちらを参照するか、Twitterで@photon_statusをフォローしてください。
最新のステータスについてお知らせします。

デフォルトのPhotonリージョンは?

少なくとも1つのリージョンが利用できる場合、クライアントはPhoton Cloudに接続可能となるべきです。
この点を保証するため、ディベロッパーが明示的に設定しない場合や「ベストリージョン」オプションを選択しない場合には、デフォルト値を設定するか、
またはデフォルト値を使用する必要があります。
デフォルト値はクライアントSDKによって異なります。
ネイティブSDKでは、OpGetRegionsでサーバーによって返されるリージョンリストのインデックス0の値です。
UnityおよびDotNet SDKでは、デフォルトのリージョンは「EU」とする必要があります。

一部のリージョンを無効にすることは可能ですか?

はい。
許可されたリージョンのリストを定義することにより、別の方法で機能します。
詳細は、Dashboardリージョンのフィルタリングを参照してください。

ロードバランシング

Photonのルームでサポートされるプレイヤーの最大数は?

Photonを利用したマルチプレイゲームのほとんどはプレイヤー数が2~16人です。ただし、理論上のルームごとのプレイヤー数/ピアの上限は非常に高く設定されています。
プレイヤー数が32人、または64人で稼働しているPhoton利用ゲームもあり、仮想会議のシナリオでは最大人数が数百人に達する可能性があります。
しかし、1秒あたりの送信メッセージ数(ルームごとのメッセージ数/秒)が多くなりすぎると、クライアントのデータ処理能力によってはパフォーマンスに問題が生じる可能性があります。たとえばターンベースゲームの場合はプレイヤー数が多くなっても全く問題がありませんが、高速アクションゲームでプレイヤー数が32人以上になると、インタレスト管理が必要になるでしょう。
このようにして、すべてのプレイヤーが他の全プレイヤーからのメッセージをもれなく受信できるわけではなくなります。

ルームごとのプレイヤー数は、ゲームルーム内のデータトラフィックを増加させる主な原因です:
このため、弊社はルームごとのメッセージ数/秒を500以下にするよう推奨しています。
Photonはこの上限を強制しませんが、ユーザーの皆様の公正な利用を前提としています。帯域幅使用量を監視することは常に重要である点、また購入プランにもとづき、1CCUあたり3GBのトラフィック範囲内にとどまる点に留意してください。

Photon文字列に上限はありますか?

Photonは文字列を多くの用途で使用します:ルーム名、ロビー名、ユーザーID、ニックネーム、カスタムプロパティキーなどです。

Photonのバイナリプロトコルは、最大32,767文字まで文字列をシリアル化できます。
名前やユーザーIDには36文字で十分でしょう(たとえば、GUIDは36文字です)。
ただし、カスタムプロパティキーの場合には、オーバーヘッドを減らすためにさらに短い文字列を使用しなければなりません。
これは、ロビーに表示されるプロパティの場合に特に重要です。これらのプロパティはルームリストの一部で、ルーム内の数人のクライアントだけでなくロビー内の全員に送信されるためです。

カスタムプロパティ数に上限はありますか?

はい、上限はあります:各ユーザーが設定できるキー値は13,000個までで、ルーム内のキーのサイズは合計で最大500KB未満にする必要があります。
The more Custom Properties are set, the longer the clients take to join a room, as clients receive all of the properties.
カスタムプロパティを多く設定するほど、クライアントがルームに参加するのにかかる時間は長くなります。これは、クライアントはすべてのプロパティを受信するためです。

Photonを使用して、巨大なメッセージを送信できますか?

内容を把握していない限り、Photonを使用して大きなデータ(すなわちファイル)を転送することは推奨しません。
やり取りするデータを最適化してください。やむを得ず非常に大きなメッセージを送信する必要がある場合には、弊社にご連絡ください。

Photon Cloudにはクライアントバッファに対してサーバーサイドの上限があり、5000KBとなっています。
このため状況に応じて、メッセージが以下に該当しないか検討してください:

  • Photon Cloud上のクライアントごとのバッファサイズに対して「大きすぎる」> 500KB。クライアントが短時間でこの上限に達する場合、クライアントはサーバーによって切断されます。
  • 問題を招く可能性のある分割量が発生するため、UDPで送信するには「大きすぎる」>100KB。
  • 複数のUDPパケットに分割して送信する必要があるため、「大きすぎる」 >1.2KB (プロトコルオーバーヘッドを含む)。

定期的かつ頻繁に送信されるメッセージ(1秒間に10回以上)については、1KB以下のサイズを保持するよう推奨します。

メッセージの送信頻度が低い場合(たとえば、マッチの開始時に1回など)には、数KBのサイズでも問題ありません。ただし、10KB以下に保つことを推奨します。

例外的に、20KBや50KBでも問題のない場合があります。
ただし、こうした大きなメッセージは通常、何らかの問題を示しています。修正点がないか確認し、代替策を再検討してください。

どのデータを高信頼、低信頼で送信すべきですか?

まず、信頼性は使用されるプロトコルがUDPの場合のみのオプションである点を認識してください。
TCPには固有の「信頼性」メカニズムがあるため、ここでは説明しません。

高信頼で送信する、とは送信されるものが対象のクライアントに届く点をPhotonが確認する、という意味です。
このため、十分な時間待ってもクライアントが確認応答を得られない場合、クライアントは確認応答を得るまで送信を繰り返すか、再試行回数を超過することになります。
また、高信頼イベントを繰り返すとさらにレイテンシーが発生し、後続のイベントが遅延されます。

信頼性を使用しない例は以下のとおりです:

  • リアルタイムゲームでのプレイヤー位置のアップデート
  • 音声または動画チャット(ストリーミング)

信頼性を使用する例は以下のとおりです:

  • ターンベースゲームでのターンイベント
  • めったに変化しないスコアのアップデート

なぜゲームで多くの切断が発生するのでしょうか?

切断には様々な原因が考えられます。
関連する問題を調査するには、以下のドキュメントページを参照してください:

1つのルームの1秒あたりのメッセージの計算方法は?

Photon Serverは、受信/発信メッセージの合計数を毎秒計上し、ルームの合計数(同じマスターサーバー上のルーム合計数)で割っています。

操作リクエスト、操作レスポンス、イベントはすべてメッセージとみなされます。
Photonの操作はオプションの操作レスポンスを返し、イベントをトリガーしない場合もあれば、トリガーする場合もあります。
キャッシュイベントもメッセージとして計上されます。

ルーム内操作で必要なメッセージ数:

操作 成功:ベストケース 成功:平均的なケース 成功:ワーストケース
Create 2
(SuppressRoomEvents=true)
3
+ Join event (SuppressRoomEvents=false, default)
4
+ ErroInfo event (HasErrorInfo=true)
Join 2 + k
(SuppressRoomEvents=true)
+ k * cached custom event
2 + n + k
+ n * Join event (SuppressRoomEvents=false, default)
2 + 2 * n + k
+ n * ErroInfo event (HasErrorInfo=true)
Leave 2
(SuppressRoomEvents=true)
1 + n
+ (n - 1) * Leave event (SuppressRoomEvents=false, default)
2 + (n - 1) * 2
+ (n - 1) * ErroInfo event (HasErrorInfo=true)
RaiseEvent 1
(no operation response)
(target: interest group with no subscribers)
1 + n
+ n * custom event
(target: all/broadcast)
2 + 2 * n
+ n * ErroInfo event (HasErrorInfo=true)
+ Auth event (token refresh)
SetProperties 2
Broadcast=false
2 + n
+ n * PropertiesChanged event (Broadcast=true, default)
2 + 2 * n
+ n * ErrorInfo event (HasErrorInfo=true)

ユーザーが使用するトラフィックを計算する方法は?

これは難しいトピックです。
まず、いかなる計算も理論上の見積もりであり、現実を反映していない可能性がある点を把握する必要があります。
概念実証をおこなって、実際のデータを収集することをお勧めします。

それとは別に、ここではルーム内の単独ユーザーによって生じるトラフィックを見積もります:

以下を想定してみましょう:

  • ルーム内のプレイヤー数はNです。
  • 1人のプレイヤーが1秒あたりに送信するメッセージ数はFです(メッセージ送信率の単位はHz)。
  • 平均メッセージサイズはX(単位はバイト、ペイロード (P) + プロトコルオーバーヘッド (O))です。
  • 平均的なプレイヤーは、そのゲームに1か月あたりH時間を費やします。

ACKを考慮しない場合、接続処理(確立や保持など)が命令や再送信をおこないます。
すると、このゲームでは以下のとおり平均的に1CCUあたりC(単位 バイト/月)を使用します。

C = X * F * N * H * 60 (分/時間) * 60 (秒/分)

切断後すぐにルームに再び参加する方法は?

ルームへの参加中に発生した予期しない切断から回復するために、クライアントはルームへの再接続と再参加を試みることができます。
これを「クイック再入室」と呼びます。
クイック再入室は、次の場合にのみ成功します:

  • ルームは同じサーバー上にまだ存在するか、読み込めます:
    プレイヤーが退室しても、他のプレイヤーがまだ参加している場合、後者はPhotonサーバー上で生き続けることができます。
    プレイヤーが最後に退出し、ルームが空になった場合、EmptyRoomTTLは、プレイヤーが参加または再参加するのを待機している時間です。
    EmptyRoomTTLの後、ルームがまだ空で、誰も参加していない場合、Photonサーバーから削除されます。
    永続化条件が満たされ、Webhookがセットアップされている場合、ルームの状態を構成済みのWebサービスに保存して、後で読み込むことができます。
  • アクターは内部でインアクティブとしてマークされます。同じUserIdを持つアクターがアクターのリスト内に存在しますが、現在ルームに参加していません。
    これには、PlayerTTLが0と異なる必要があります。
  • インアクティブなアクターのPlayerTTLが期限切れになりませんでした。アクターが戻ってくるオプションを選択してルームを出ると、インアクティブ化タイムスタンプを保存します。
    ルームが稼働している限り、インアクティブ化時間からPlayerTTLミリ秒が経過すると、それぞれのアクターがアクターのリストから削除されます。
    それ以外の場合、アクターが再入室を試みるときに、再入室の試行時間とインアクティブ化時間のミリ秒単位の差がPlayerTTLを超えると、アクターはアクターのリストから削除され、再入室は失敗します。
    そのため、インアクティブなアクターは、インアクティブ化時間の後、PlayerTTLミリ秒だけルームに再入室できます。

PUNではPhotonNetwork.ReconnectAndRejoin()を呼び出すことができます。

PUN

PUN PlusとPUN Freeの違いは?

パッケージの内容に変わりはありませんが、PUN Plusをご購入いただくと、適用から12ヶ月間有効なPhoton Cloudサブスクリプション100CCU分のクーポンを取得できます。

2,000DAUや40,000MAU(これらの数値はEGのCloudを使用しているゲーム全体の平均)のゲームの場合には平均100CCUで十分なので、かなりお得です。

購入日の12か月以内にダッシュボードでコードの適用 をおこなう必要があるので、ご注意ください。

PUN Plusクーポンの適用方法

  1. Photonダッシュボードを開きます。
  2. -/+ CCUをクリックして、クーポンを適用したいAppIDを選択します。
  3. 100CCUタブを選択します。
  4. 「クーポンがありますか?クーポンコードを使用して、プランを追加してください」をクリックし、請求IDを入力してください(注文番号ではありません)。
  5. "クーポンコードまたはUnity請求ID"欄に、Unity請求IDを登録してください。
    Unity請求IDは、UnityアセットストアでPUN Plusを購入すると付与されます。注文番号を使用しないでください。
  6. アプリケーションIDを再確認し、"適用する"をクリックします。

なぜ、ゲームで多くのラグが発生するのでしょうか?

ping(RTT)で問題が発生し、その頻度が高くない場合にその理由を特定するのは困難です。
ゲームやPUN自体とは別に、ネットワークの問題が関連している点も考えられます。
インフラは、多くの場合において非常に複雑で制御が難しいものです。
PUN内の一部のメッセージは高信頼で(たとえばRPC)、これらのメッセージが欠落した場合には再送信する必要があります。
この現象が1回以上起こる場合にはpingが急速に上がり、アップデートがないためにゲーム内のロジックが停滞します。

PUNには再送信によるラグに対処する機能がありますが、この機能でも完全に回避することはできません。
最新バージョンにアップデートするよう、常に留意してください。

ラグは切断につながる可能性があります。
切断の一般的な解決策については、こちらを参照してください。
弊社のサポートが必要な場合、弊社は再現方法、発生頻度、発生時刻、および問題の継続時間を把握する必要があります。
また、可能であれば1つ以上の接続、接続タイプ、およびデバイス上で、同様の問題が発生するか試してください。そして、どの接続、接続タイプ、デバイスで試したのかを
弊社にご連絡ください。

詳細な情報を、こちらに記載された宛先までご連絡ください。

再現できた場合に、弊社は問題の解決策を調査します。

使用中のPUNのバージョンを確認するには?

PUNのバージョンは、以下の3つの方法で確認できます:

  • Unityエディター内のPhotonServerSettingsインスペクターの最上部に表示されています。
  • PhotonNetwork.PunVersion文字列フィールドに表示されています。
  • "Assets\Photon\PhotonUnityNetworking\changelog.txt"で、最上部の最初のエントリーを参照してください。

請求

学生、趣味でおこなっているディベロッパー、インディー向けの割引はありますか?

弊社の製品にはすべて、無料プランとワンショットのプランがあります。
また弊社は通常、Unityアセットストアのセールに参加し、また当選者にはクーポンを提供しています。

1つのPhotonアプリケーションに、複数の100CCUプランを組み合わせることはできますか?

いいえ。
100CCUプランは1つのAppIDにつき1回のみ適用でき、複数の100CCUプランを使用することはできません。
複数のPUN+アセットシートを購入している場合には、各AppIDに対して個別の無料100CCUを適用する必要があります。
1つのアプリに対してさらに多くのCCUが必要な場合、次の上位プランは500CCUです。
月額または年額プランをご利用の場合には、その月額/年額プランのCCUに加えて、12ヶ月間有効の100CCUを使用できます。

Back to top