I don’t have an alternative system to recommend instead of Photon because most services have similar constraints. As discussed in the theory of constraints, measures are taken according to the constraints in each project, and these measures aim to maximize profit. The fundamental problem with most multiplayer services, as we discussed earlier, is the calculation of Load Balance and CCU/Mem. Usage.
Speaking specifically about Photon, they present us with the following main constraints:
A maximum of 16 real-time users can be present in game rooms. There is a lot of ambiguity around this, so I’m including the relevant part from the Photon documentation:
Most Photon multiplayer games have 2-16 players, but the theoretical limit of players/peers per room can be quite high. There are Photon games live with 32 or even 64 players and in virtual conferencing scenarios it can be in the hundreds. However, sending too many messages per second (msg/s per room) can cause performance issues depending on the client’s processing power coping with data. While high player numbers in e.g. turn-based games are totally fine, more than 8 players in a fast-paced action game likely will require you to implement interest management. This way not every player receives every message from all the other players.
The maximum number of requests needed for sending and receiving data per second in a game room should be 500.
The maximum message traffic in a room on Photon is 500KB.
The maximum amount of data that users can send per packet should be kept at or below 1KB.
These are the constraints provided by Photon. You can review the details on this page:
Photon in Our Project
To avoid issues in our multiplayer infrastructure, I will create a hypothetical scenario and discuss it. Concrete examples will help us better understand the above constraints and related problems and assist in finding solutions.
Example Mechanic: A typical runner game. Our users will start running from the starting area, encountering various obstacles along the way. They can overcome these obstacles with the equipment they carry and also have abilities like jumping over them. The first to reach the finish line wins.
In the first step, we need to find the optimal real-time user count for the mechanic mentioned above. The number of users will vary for each mechanic and use case, which is a result of the constraints of these multiplayer services.
If Photon gives us a limit of 500 messages per second:
Let’s symbolize our critical points:
- There are N players in a room.
- A player sends S messages per second (Message sending rate).
- The average message size is X (in bytes).
Based on this, we get the following equation:
💡 500 ≥ S * N * N
For example, if we limit the data transfer rate in our game to 10 times per second per user (S = 10), we find that we can have a maximum of 7 real-time users in our game room.
In an ideal game, the message sending frequency should not be below 10 per second. This technically means that while the game mechanic runs at 60 FPS, the data traffic is limited to 10 FPS, leading to many bugs. So, even under ideal conditions, it’s not possible to have more than 8 users in our game room. (There are optimizations, which I will discuss.)
We organize this message sending rate in Photon through PhotonViews, which automatically send data on the GameObject, whether we call them or not. For example, they handle the basic information like the position and rotation of our characters.
For scenarios like jumping or attacking obstacles, which involve instant changes, we need to use RPCs within PhotonView. And yes, RPCs are also counted within this 500-message limit.
Therefore, if we want to use both the default values of our characters and RPC events in our game, the actual number of users we calculated as 7 earlier would drop to 5 or 6.
Solution 1
Send only the current position, etc., of a player to a designated MasterClient, who then streams it to all other players.
This effectively doubles the round-trip time for each state update on the receiving side of the players. However, it offers good bandwidth for slower-paced games. The formula for this is:
💡 500 = S * (3 * N - 2)
- The
n-1players send their data to the MasterClient. - The MasterClient receives
N-1messages. - The MasterClient sends one message.
- The
N-1players receive this message = 3 * (N - 1) + 1 = (3 * N - 2).
This results in N = 17 users for S = 10.
Here, we’ve achieved optimization by extending the data path but introduced a new problem:
What if the MasterClient drops out, leaves the game, or experiences internet speed issues?
Answer: We would need to use a server-based infrastructure with Photon, where the person designated as the MasterClient becomes our server, and streaming solves the problem.
Of course, this will bring new problems, such as renting a server, ensuring hook connections in games, managing the traffic load on the MasterClient, etc.
Solution 2
In no game (including PUBG, COD, GTA 5) do all users have to be real-time players just because there are 50 users in the game. We could work on producing realistic AI results to reach our target user numbers in our games. This method will be more effective and easier than the other.
If our players want to join the game with a group of 5-10 friends (and I don’t think there’s any harm in limiting it to a maximum of 8), we can structure our game as described at the beginning. However, opening 10-20 player game rooms for every new player and 1-2 players seems harmful in every sense.
For more details:
Photon Load Calculation Example
Reply by Email