This topic is a continuation of the previous one. Let’s continue by considering that we are running our game with 7 users at 10 FPS.
If we receive data traffic at 10 FPS, we will frequently experience lag in the game. You might have encountered this in many games, where a network player’s movements are often jerky, jumping in milliseconds as you approach them.
To solve this problem, we can use the interpolation methods that are built into Rigidbody by default. However, if we overdo it with physics calculations, we risk compromising device optimization.
Therefore, I believe it is beneficial to use mathematical lerp methods in situations where physics calculations are not crucial, and I have used similar infrastructures in my own projects.
Earlier, we discussed 3 of Photon’s 4 fundamental constraints, but we haven’t talked about the 4th one: the size of our message data. For example, when we want to send transform information in a single message, we get data sizes like this:
- position:
Vector3⇒ 16 bytes - rotation:
Quaternion⇒ 20 bytes
If we use the entire 500 message limit and, for now, only send and receive position and rotation information:
💡 500 * (16 + 20) = 17.57 KB
We can assume that we have 17.57 KB of data traffic per second. Let’s remember that the maximum traffic in our room should be 500 KB per second, and the message size should be a maximum of 1KB (currently, only 36 bytes).
A New Problem
Even though all these values meet our constraints on the Photon side, they introduce a new problem on the device side. As we send and receive messages, we will have Garbage Allocations equivalent to the traffic size, which will continue to allocate and collect garbage continuously every second, as discussed in the section on GC generation with strings.
There is no way to prevent the GC generated by this data traffic—specifically in Photon. This situation will occur under all conditions. However, we can optimize these values.
There are many serialization and optimization frameworks, such as message packing, protocol buffers, etc. Similar assets also exist specifically for Photon.
What we are essentially doing here is, instead of sending and receiving data as individual parameters, we can serialize the data set before sending it and transfer it in binary format. After deserializing the received bundled data (with very small error rates leading to possible data loss), we can use it in our game.
You can check out these links:
Reply by Email