FAQ

目次

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

対象となるゲームやプロジェクトの特性によって異なるため、これはむずかしい質問です。 ただし、弊社は以下のように推奨しています:

ご不明点な点がある場合、お問い合わせください。

Photon RealtimeとPUNのちがいは何ですか?

Photon RealtimeとPUNはともに、同一のAPIにもとづいています:LoadBalancing APIです。

これらの製品は同じバックエンド、サーバーアプリケーション、低いレベルの要素を共有しており、中核となるコンセプトも同一です。 当初、PUNはより優れたUNet(旧式のUnity Networking)と位置づけられていました:同様のAPIを保持し、さらに強固なバックエンドと豊富な機能を提供していました。

そして、その後PUNは次第に分化して、Unity上でのマルチプレイヤー向けNo1ソリューションとなりました。

Photon Realtime Unity SDKと比較して、PUNは以下のようなさらに高度なレベルの機能を提供し、またこれらの機能は購入後にすぐに使用できます:

  • Magic Unity コールバック
  • ネットワークオブジェクトをシリアル化および同期する外部Unityコンポーネント:もっとも重要なものにPhotonViewがあります
  • PunRPC
  • オフラインモード
  • ...

詳細はこちらを参照してください。

ただし、PUNはWebhookルームステートの保持をサポートしますが、 保存されたゲームの画面を読み込む際に、シーン内のネットワークオブジェクトのステートを完全に復旧することはできません。

詳細は、こちらを参照してください。

LoadBalancing APIとPhoton Realtimeのちがいは何ですか?

LoadBalancing APIとPhoton Realtimeは、名称は異なりますがおなじものを指しています。 LoadBalancing APIまたはLoadBalancing Client APIは、Photon Realtime製品向けに弊社が提供している、クライアントSDK内で利用できるプログラミングインターフェースです。

Photon Cloud

Is Photon Cloud down?

You can check Photon Cloud status here or follow @exitgames on twitter to get notified about status updates.

What is the default Photon region?

Clients should be able to connect to Photon Cloud as long as at least one region is available. So to guarantee this, a default value is configured or is used when the developer does not explicitly set one or choose "Best Region" option. The default value could vary by client SDK. In native SDKs, it is the value at index 0 of the region list returned by server in OpGetRegions. On Unity and DotNet SDKs, the default region should be "EU".

一部のリージョンを非有効化することはできますか?

はい。 これは、許可されるリージョンのリストを定義するのとは逆の方法で設定できます。 詳細については、"ダッシュボードリージョンのフィルタリング"を参照してください。

Load Balancing

What is the maximum number of players supported by Photon rooms?

The number of players is the main factor for increasing traffic inside the room. The more players there are the more messages are exchanged.

The short answer is:

4 is good, 8 is doable. Above 8 is tricky and requires some netcode magic.

The long answer is:

In theory, there is no limit. For more than 8 players you will need interest management. For massive amounts of players you would split them - your world - across multiple rooms.

Is there a limit for Photon strings?

Photon uses strings for lots of purposes: room name, lobby name, UserID, Nickname, custom property key, etc.

Photon binary protocol can serialize strings up to 32767 characters. For names and UserIDs 32 characters should be enough (e.g. a GUID is 32 characters). However, for custom properties keys, you should use shorter strings to minimize their overhead. This is especially important for properties that are visible in the lobby, as those are part of the room lists and get sent to everyone in the lobby, not just the couple of clients in a room.

Is there a limit for the number of custom properties?

No. However, note that the more Custom Properties are set, the longer the clients load time will be because when joining the room, the clients also receive all of the properties. If you have too many of them and clients' load time exceed a certain amount of time, this might result in a disconnect for them.

Can I send a huge message using Photon?

We do not recommend transferring large data (i.e. files) using Photon unless you know what you are doing. We advise you to optimize the data you exchange and get in touch with us if you really have to send a very big message.

Photon Cloud has a server side limit for client buffers which is 500KB. So depending on the context a message could be considered:

  • "too big" for our per client buffer size on Photon Cloud > 500KB. If a client hits this limit in a short period of time, it will be disconnected by the server.
  • "too big" to be sent with UDP without resulting in an amount of fragments that might cause problems > 100KB.
  • "too big" to be sent without splitting it up into multiple UDP packets > 1.2KB (including protocols overhead).

For messages that get sent very regularly (10 times a second or even more often) we would recommend to keep their size below 1KB.

If a message only get sent rarely (for example once at the start of a match), then a size of multiple KB is still fine, but we still would recommend to keep it below 10KB.

In exceptional cases something like 20KB or even 50KB might make sense. But usually messages that big indicate that there is something wrong and you should review what you are doing and reconsider your options.

Which data should be sent reliably and which should be sent unreliably?

First of all, you should know reliability is an option only when the protocol used is UDP. TCP has its own "reliability" mechanism(s) which are not covered here.

Sending something reliable means that we should make sure it arrives to target(s). So in case we do not receive an acknowledgment after waiting enough time, we repeat sending until we receive the acknowledgment or we exceed the number of retrials. Also, repeating reliable events may cause extra latency and make subsequent events delayed.

Examples for not using reliability:

  • player position updates in realtime games
  • voice or video chat

Example for using reliability:

  • turn events in turn-based games

Why do I have so many disconnects in my game?

The disconnects could be due to various reasons. We already have two documentation pages that can help you investigate the related issues:

How messages per second per room are calculated?

Photon server counts total inbound and outbound messages every second and divide it by the total number of rooms (on the same Master Server).

Any operation request or operation response or event is considered a message. Photon operations return an optional operation response and trigger zero or more events. Cached events are also counted as messages.

Messages cost per in-room operation:

Operation Success: Best Case Success: Average Case Success: Worst Case
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)

How do I calculate traffic consumed by a user?

This is a complex topic. First you need to know that any calculation done is just a theoretical estimation and may not reflect reality. We recommend building a Proof-of-Concept and use it to gather real data.

That being said here is how to estimate traffic generated by a single user inside a room:

Let's assume the following:

  • a room has N players.
  • a player sends F messages per second (message send rate in Hz)
  • average message size is X (in bytes, payload (P) + protocol overhead (O))
  • an average player spends H hours per month on your game

If we do not consider ACKs, connection handling (establishment, keep alive, etc.) commands and resends. Then we say that on average, a CCU consumes C (in bytes/month) in your game as follows:

C = X * F * N * H * 60 (minutes per hour) * 60 (seconds per minute)

切断後に、ルームにすばやく再参加する方法は?

ルームへの参加中に予期せず切断した場合、クライアントはルームへの再接続と再参加を試行できます。 これを「クイック・リジョイン」と呼びます。クイック・リジョインは、以下の条件を満たした場合にのみ成功します: - ルームが同じサーバー上にまだ存在しているか、または読み込み可能な場合:

プレイヤーがルームを退出すると、ルームは他のプレイヤーがまだ参加している場合にPhoton Server上に存続しつづけることが可能です。 もし最後のプレイヤーが退出してルームが空になる場合には、プレイヤーが参加または再参加するまで、ルームをどのくらいの時間存続させるのかをEmptyRoomTTLで指定します。 EmptyRoomTTL後もまだルームが空で、どのプレイヤーも参加しない場合、そのルームはPhoton Serverから削除されます。 持続の条件を満たし、またWebhookが設定されているならば、ルームステートは設定されたWebサービス上に保存され、後で読み込めます。 - アクターは内部的には非アクティブにマークされます: 同じUserIdを持つアクターがアクターのリストに存在しますが、現在はルームには参加していません。この場合、PlayerTTLを0以外の値にする必要があります。 - 非アクティブなアクターへのPlayerTTLが失効しなかった場合:アクターが再び戻ってくるオプションとともにルームを退出する場合、このユーザーのDeactivationタイムスタンプが保存されます。ルームが存続している限り、Deactivation時刻からPlayerTTLミリ秒経過すると、各アクターはアクターのリストから削除されます。 もしくは、アクターが再参加を試みた場合に、再参加を試みた時刻とDeactivation時刻の差異(ミリ秒)がPlayerTTLを超過している場合には、そのアクターはアクターのリストから削除され、再参加は失敗します。 So an inactive actor can rejoin a room only for PlayerTTL milliseconds after Deactivation time. 結果的に、非アクティブアクターは、Deactivation時刻からPlayerTTLミリ秒経過した時点でのみルームに再参加できます。

「クイック・リジョイン」は、2つのステップからなります:

  • 再接続: 一旦切断されると、単純に適切な接続方法を呼びます。

  • 再参加: loadBalancingClient.OpRejoin(roomName)を呼びます。

Billing

Do you have special offers for students, hobbyists or indies?

All our products have a free tier and a one-off entry-plan. We also usually take part in Unity's asset store sales and occasionally give vouchers to lucky ones.

Can I combine more than one 100 CCU plan for a single Photon application?

No. The 100 CCU plans are not stackable and can be applied only once per AppId. If you purchase multiple PUN+ asset seats then you must redeem each 100 free CCU for a separate AppId. If you need more CCU for a single app, the next higher plan is the 500 CCU one. If you subscribe to a monthly or yearly plan, then you will still keep the 100 CCUs for 60 months on top of / in addition to the CCU from your monthly/yearly plan.

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