calculate Msg/s per room
Options
Hi everyone, my question is does PhotonTransformView and PhotonRigidbodyView messages count when calculating the msg/s per room?
0
Comments
-
> @JohnTube said:
> Hi @SimBaa,
>
> Yes all messages count.
> Check the glossary entry here.
It will not be a decent fps game if I sync the transform and the rigidbody with 16 players in a room with only 500 msg's.
If I want to not cross the 500 I will have to sync only every 2 seconds and that is horribly bad and will cause terrible lag... a fps game is not a fps game wothout atleast 16 players in each room0 -
If you are making shooter game with 16+ players, you should choose another networking solution.
0 -
> @OneManArmy said:
> If you are making shooter game with 16+ players, you should choose another networking solution.
Can you suggest me one?0 -
Photon Bolt is good for FPS.
And FYI: With PUN/Photon Realtime and Network Culling you can reduce msg/room/s. Read more here (old but relevant).0 -
I'm trying to create a proof of concept top down shooter and it seems like PUN may be a lost cause for even 16, let alone 24 players even with influence mapping. If even 8 people are in the same area and another 8 are on another side of the map, that's a minimum of...
- Transform = 8*7*20 = 1,120msgs * 2 = 2240msgs (better than full 16*15*20 = 4,800)
- Shooting states etc.. let's say somehow it only detects changes every 5hz
-- 8*7*5 = 280 * 2 = 560
Unless my math is way off, that's more like 2,750msgs/sec if you just add some fluff for "other stuff" going on in the world. Even a 5v5 MOBA seems barely doable if people aggregate into the same area for a battle?
It's really unfortunate they don't allow us to try to conserve bandwidth.. not sure why "Messages" are the limiter. Seems like it would be easy enough to say.. you're allowed 20kb/s bandwidth etc.0 -
Actually, we do not have a hard msg/s limit. This is in the first place a recommendation, as with more messages clients might easily get overwhelmed - especially mobile clients.
Regarding bandwidth, please be sure to check out the included bandwidth and overage pricing (e.g. https://www.photonengine.com/en-US/PUN/Pricing#plan-20).0 -
dont forget that a fps game cant do network culling to reduce the messages because you will be deleting the snipers of the game, I hope they change that freakin nonsense limit...Majicpanda said:I'm trying to create a proof of concept top down shooter and it seems like PUN may be a lost cause for even 16, let alone 24 players even with influence mapping. If even 8 people are in the same area and another 8 are on another side of the map, that's a minimum of...
- Transform = 8*7*20 = 1,120msgs * 2 = 2240msgs (better than full 16*15*20 = 4,800)
- Shooting states etc.. let's say somehow it only detects changes every 5hz
-- 8*7*5 = 280 * 2 = 560
Unless my math is way off, that's more like 2,750msgs/sec if you just add some fluff for "other stuff" going on in the world. Even a 5v5 MOBA seems barely doable if people aggregate into the same area for a battle?
It's really unfortunate they don't allow us to try to conserve bandwidth.. not sure why "Messages" are the limiter. Seems like it would be easy enough to say.. you're allowed 20kb/s bandwidth etc.0 -
Hi @SimBaam, @Majicpanda .
One of the reasons for having a message limit and not just a bandwidth limit is that the amount of messages that a server needs to handle have a major impact on the CPU usage of that server. More used messages per CCU means less CCU that can be handled on each server, which means that more servers are required for the same amount of users even with the exact same bandwidth usage. The message-limit makes it possible to offer lower prices than would be possible otherwise. Removing it would require us to considerably raise the price for everyone.
As @Markus said, this is not a hard limit.
We won't technically prevent you from sending more than that.
However when you surpass the limit considerably for a longer time and have lots of users, then we may contact you about that to find a solution (potential solutions: you reduce your apps messages per second to be inside the limits or you may prefer to pay more per CCU than the regular price to cover the additional costs of the higher msg/sec or you may want to switch to self-hosted Photon servers, which do not have a msg/second restriction).0 -
I guess the biggest problem I have with the current implementation is (and correct me if I'm wrong) that OnSerializedView(1*hz), PhotonView updating Animator+Transform(1*hz), and every single RPC counts as a separate message.
If your Transform sync needs to be 20hz, OnSerializedView is 10hz, and you send 1 RPC every second let's say just for the heck of it.. and assuming everyone is always moving and OnSerializedView always has something changed, you're sitting at 20+10+1msgs/sec exponentially sent per player to every other player.
I understand the CPU issue, it's unfortunate that everything in one net update cannot be sent in 1 packet and handled on the receiving end resulting in far less messages.
If you use Bolt + Photon Cloud it seems a bit more stable since Bolt packets everything in an update into 1 packet (that it can obviously), resulting in 1 message if you use the cloud. The problem is you then rely on the host/server for RTT instead of the relay.
This may have been a lesson in futility to see how far I could push PUN, but I think I'm still going to have to use Photon Server or Bolt for a fast action game of 10+ players is my conclusion.
In a 5v5 top down shooter, like explained.. if anyone can hit anyone on the map, you can't exactly cull very effectively reuslting in approx 4k messages, blowing away your "soft cap". I'm not sure what happens if my game would constantly send 4k messages/sec. Would I just pay for extra bandwidth or since it uses a lot more CPU, we would have to negotiate some sort of cost that would still result in Photon turning a profit?0 -
Hi @Majicpanda.
I'm not sure what happens if my game would constantly send 4k messages/sec. Would I just pay for extra bandwidth or since it uses a lot more CPU, we would have to negotiate some sort of cost that would still result in Photon turning a profit?
I can't give an answer to this as I am just a client developer and not involved in our pricing calculations.
My recommendation regarding this question is to ask it by email (see https://www.photonengine.com/en/Contact), so that we can assign it as a support ticket to a colleague who can give you a meaningful answer.
it's unfortunate that everything in one net update cannot be sent in 1 packet and handled on the receiving end resulting in far less messages.
That's the price that PUN pays for being rather high-level and simplifying a lot of things for the user - the user unavoidably looses some degree of fine-grain control.
If you want more control about what can be aggregated into one message and what can't, then I would recommend to not use RPCs, but to directly use NetworkingPeer.OpRaiseEvent() instead. That way you have direct control about messages and can easier optimize your amount of messages by aggregating all information into one message that needs to be send to the same client in the same time window.0 -
so if I use bolt or thunder the messages that will be sent to the MasterClient/Listen Server and not the photon cloud server will not be counted right?
@Kaiserludi @OneManArmy @Markus @JohnTube0 -
So far from my last few days of learning, if you use Bolt + Photon Cloud you will only get hit for messages for clients that fail to NAT punch. Someone recently told me that only 5% of connections actually got sent to the relay in the testing, but I cannot confirm and that's a super important piece of information.SimBaa said:so if I use bolt or thunder the messages that will be sent to the MasterClient/Listen Server and not the photon cloud server will not be counted right?
@Kaiserludi @OneManArmy @Markus @JohnTube
One very important thing to note is that Bolt allows compression on integer etc so that you only use the bits for the exact size of the data you need to send. Example, you know you have damage 0-1000, you could compress your Damage variable to 0-1023 so that it only takes 10 bits instead of having to declare a ushort etc and still waste data on the wire.
Major key aspect #2, Bolt sends everything it can in one packet for you, so any Events or sync data is packed into a 1200 byte packet (I believe default size), so this would save drastically on Message count for you.
In Bolt, if data is sent straight to the Host (direct connect successful) I was informed they would not hit the relay, thus not counting as messages.0 -
I completely understand the model and I'm more frustrated that I can't find a solution that marries Bolt + PUN since I don't have the background to implement host migration into Bolt myself.Kaiserludi said:Hi @Majicpanda.
That's the price that PUN pays for being rather high-level and simplifying a lot of things for the user - the user unavoidably looses some degree of fine-grain control.
If you want more control about what can be aggregated into one message and what can't, then I would recommend to not use RPCs, but to directly use NetworkingPeer.OpRaiseEvent() instead. That way you have direct control about messages and can easier optimize your amount of messages by aggregating all information into one message that needs to be send to the same client in the same time window.
Guess people aren't meant to build 16+ player games unless they want to host dedicated servers.0 -
I just tested my game with 4 players today, with PhotonNetwork.sendRate set to 20, so i was expecting something around 4*4*20 = 320 msg/s (or is it 4*3*20 = 240 msg/s? I never know really...)
After the game i went to check the analytics on my photon account, and it tells me: 122 msg/s max, which is far from what i expected... so i'm guessing photon is doing some packing already in the background or something?
anyway... try and check those analytics because maybe your game isn't taking as much as you think it is... ( or am i missing something here? )
have a good day =D0
