Saving Messages on Photon

Hi forum,

Im working with PUN for some time now and implemented a lot of funcionality into my game.
Everything works fine so far except the problem with messages per second.

So im working on a FPS-like game reaching 500 msg/s is not hard.
For a worst-case scenario it would be 16 players in a room (10 msg/s per player) which would at least equal
16 * 16 * 10 = 2560 msg/s for position-tracking alone.
Even with a lot of optimization and savings the count would never reach below 500 msg/s.

I read a lot about this problem on the forum but I couldnt really find a lot of information on how to save messages
besides some vague "interest management".

So I came across an idea but im not sure if it works in the context of photon cloud.
So for the example of 16 players: Instead of sending the position from every player to every other player 10 times a second I thought about only sending the data to the master-client, which would collect and merge the data and then send it back to all other clients.
This would only result in (16+16+1+16)*10 = 490 msg/s which would be quite an improvement.
With a bit of optimization it wouldn't be hard to get the count below 400.

Now the questions that bother me are:
Will the Master-Client be able to handle that ammount of data?
Will there be any other complications with this idea?
Also, hast PhotonCloud or PhotonServer any funtionality similar to this; collecting data and sending them mergerd?

Thanks a lot in advance!

Comments

  • 500 msg/s per player is... a lot.

    I just play tested my game, which handles animation, location, very smoothly and i'm only hitting 7msg/s. That includes animations, shooting, etc.

    What I would recommend is: Lower your send rate.
    Use transform lerping. Look at the file (I believe it's called...) LerpCube in the photon examples.

    When you have a lower send rate, but are monitoring the transform information (Rotation, Location) the players will jump location..location.

    With the Lerp Cube, it smoothly goes from OldestReceivedLocationRotation to NewestReceivedLocationRotation

    It's why if you ever play games like COD/BF and you die when on your screen, you're behind a wall or something, but on their screen, you're out in the open.

    Not sure if this is the info you want, but yeah.
  • @Cynikal
    Well I appreciate that you tried to help but it looks like you haven't even read my post.
    Firstly 500 msg/s is PhotonClouds message-cap as you can read here -> https://www.exitgames.com/en/Realtime/Pricing
    It's not my per-player message-count as I wrote:
    For a worst-case scenario it would be 16 players in a room (10 msg/s per player)

    Secondly I explicitly asked questions about my approach in saving messages.

    I am very aware of not only interpolation but also movement-prediction and im able to get to a send-rate of about 5 msg/s.
    But even if you would get it down to 2 msg/s (which is hardly to achieve) you would still get 16*16*2 = 512 msg/s.

    Again:
    Now the questions that bother me are:
    Will the Master-Client be able to handle that ammount of data?
    Will there be any other complications with this idea?
    Also, hast PhotonCloud or PhotonServer any funtionality similar to this; collecting data and sending them mergerd?

    Please read my post again and if you have any idea I will be happily looking forward to an answer.
  • YodelYum: Good questions.

    While the idea is good to send stuff through the Master Client, in practice the results would probably disappoint and have more lag than you'd accept for an FPS. Also, this would be hard to get bug-free as the Master Client could drop out of the game any moment as it's a user client.

    We are thinking about server-side ways to aggregate updates but we don't have a proper concept yet. It would be cool, if the server could track updates and send them together (with the least amount of lag possible).

    At the moment, I would say: Try to get the messages/sec as low as you can per room. The limit for them is not a hard one and Photon won't kick your players for it. If we can implement a server-side aggregation, you can add it when it's ready.

    Also, take a look at this article, which makes "Interest Management" a bit less vague, I hope.
    http://www.m2h.nl/network-traffic-culling
  • Thanks a lot for the information, Tobias.
    Thanks for the link, I will make sure to take a deeper look into Traffic-culling.

    For the server-side aggregation, it's awesome to hear that you are guys are thinking about it.
    It sure would give a huge benefit to the whole PhotonCloud-System.
    Especially since everything is made to "just work".

    Could you possibly provide some more information on when and/or how you handle cases when the msg/s-count is too high?

    Thanks for the informations and the link!
  • When an app is way beyond the message limit, we get in touch with the developer first to evaluate if and how things could be improved. We always try to make things work for everyone. The next steps are very much like I suggested to you now: Try to make the best out of current features, check if we can add useful features to minimize messages and in worst case, we probably accept a higher msg count for the time being.
    Let us know when you reached a plateau with your message optimization. We can then take a look at where you are and what we do next.
    Implementing new features will take a while as some of the team is sick and others are on vacation and Christmas is coming up, too.