Best Of

Hi @PhoenixRise,

Thank you for choosing Photon!

The proper way to enable lobby stats in PUN2 is, as shown in the docs page here:
If you want to do it from code before connecting:

PhotonNetwork.PhotonServerSettings.EnableLobbySatistics = true;

These work when you connect using PhotonNetwork.ConnectUsingSettings(); as that's the only connect method that actually makes use of the ScriptableObject ServerSettings.

If you need to use another connect method, then you should use PhotonNetwork.NetworkingClient.EnableLobbyStatistics = true; before connecting.

I updated our encryption doc and it will be up within the next days here:
https://doc.photonengine.com/en-us/pun/current/reference/encryption

This gets clarified:

In PUN, you can send RPCs and events with encryption on demand. The frequent and regular updates for networked objects, are not encrypted.

To call an RPCs in a secure way, use RpcSecure() on any PhotonView.

PhotonNetwork.RaiseEvent() can be used to send custom events with or without encryption.

In both cases, the server will decrypt the message and re-encrypt it to send it the other players. A Server Plugin could make use of the data, read or change it.

When an operation is sent encrypted, any data you send and all operation paramters are serialized and then encrypted. A lean header per message (length, etc.) remains unencrypted.



Hope that helps.

Hi @sweetmei25,

When you call CreateRoom, the client will send a request to Photon Master Server first.
Photon Master Server will return a response.
If the response is successful, it will contain an address of a Photon Game Server and optionally the name of the room if the client did not specify it.
Then the client will have to disconnect from Photon Master Server and connect to that Photon Game Server.
Then the client will send a request for room creation to Photon Game Server.
If successful, the room is created and the client is joined to that room.

At this point you can't call CreateRoom any more until you leave the room, disconnect from Photon Game Server and go back to Photon Master Server.

Also, Photon rooms are cleaned up by the game server once the room becomes empty and EmptyRoomTTL expires.
You can explicitly clear events cache without waiting for players to leave.

Hi @sweetmei25,

Why do you need an admin panel?

What you are asking for is now how Photon should be used.
Using PUN, clients create rooms.
First, the client tries to find a suitable room to join, if none was found, a new one will be created by the same client.
The client can name the rooms, of course, room names must be uniques, you can't have two rooms with the same name at the same time (for the same virtual application on the same region).
Also, clients can create as many rooms as requested.

If you really have to have an admin panel for whatever reason you will have to use a client to create rooms OR modify the server-side code for the LoadBalancing application and self-host yourself or go for Enterprise Cloud.

In any case, I repeat that what you try to do is not recommended and is not the workflow we encourage with Photon.

Also, for the public cloud, the plan is irrelevant here.
The same features are available for everyone.

Hi @sweetmei25.

Each client connection to the LoadBalancing application (which is what runs on Photon Cloud and also the default application for self-hosted servers) can only be active inside a single room at the same time.

Each PUN instances can only have one connection at once.

You can only run one PUN instance per Unity instance.

So yes, with PUN you would need to run a separate Unity instance for each room that you want to reside in in parallel.

However I don't think that it makes sense to run a Unity instance at all for such an admin panel, as it doesn't really need a game engine.

Hence for this admin panel I would use a Photon Realtime Client that is not integrated into Unity like PUN is, but that can run independently of it (you can still use PUN for the clients of your actual users - PUN uses realtime under the hood and PUN clients and realtime clients can interact with each other and join each others rooms, as long as they use the same appID and appVersion and connect to the same region (you need to take into consideration PUN's specific AppVersion format: {gameVersion}_{PUN_version}. So if you set the gameVersion to "1.0" in PUN and use PUN version "1.80" then the resulting AppVersion is "1.0_1.80".) ).

Just like a PUN instance one instance of the LoadBalancing Client class can only be inside one room at once.

However unlike PUN with a Realtime Client SDK you can just create multiple Client instances in one app, so you don't need your admin panel app to create a new process in the background for each room, but can just create a new instance of the Client class.

Limitations:
- Each such connection counts as a separate CCU, so your admin panel would count as 100 CCU for billing purposes, when it resides in 100 rooms in parallel.
- The architecture of the Photon clients is not designed for this use case and it is not tested by us. Therefor I can't really tell how well this will scale with which client SDK.


Another approach would be to use Photons async featureset. This is intended for use with asynchronous turnbased games like chess, in which not all players of a game need to be online at the same time, but one player can go online, make his turn, go offline again, then come back later to see if his opponents have made their turns. To make this kind of game possible, Photon Realtime supports it that a clients becomes inactive in a room (via opLeaveRoom(willComeBack=true)). This means the client leaves the room, but tells the server to treat it as still there, but as inactive.

Hence on a button click in your admin panel you could create a room and immediately leave it again with the willComeBack flag set to true. This way the room stays alive after the creator has left (as the creator is considered to be still there as an inactive player) and you can go on and create the next room, because you have left the previous one. This way your admin panel only needs one connection and one client instance no matter how many rooms it will open and it will only count as one CCU (however it still counts against the maxPlayers setting of each room, so you need to set the max players of a room to one player more per room than the amount of normal clients that you want to allow in it).
See https://doc.photonengine.com/en-us/realtime/current/tutorials/persistence-guide for more information on async persistent rooms.

Edit:
When thinking about this a little more it becomes apparent to me that you should definitely go with the async approach: this way when your admin panel for some reason crashes or goes offline or experiences a power outage, etc. this won't result in all rooms without normal clients in them to be closed, like it would be the case with "the admin panel always connected with one instance per room" approach.