some Photon Cloud questions

Lizzard4000

hi!

Photon Cloud seems the perfect solution for my needs! but i still have some questions before i will use it.

300 Msg/s per Room, what does that exacly mean?

1.
what i read is that you get the Msg/s with ( (Msg * Playercount) * Playercount-1)?
that means if i want my game to support up to 6 players with 10 updates per second it would be ( (10*6)*5) = 300 Msg/s. So very OK for the Indielimits, is that true?

2.
what does one message include?
i need to send with every message position and rotation. and sometimes stuff like who got shot and more. Is this all included with one message? or will it exceed my 300Msg/s limit?

thank you!

Kaiserludi

1 operationRequest is one message, 1 operationResponse is 1 message and 1 event is also 1 message.
This means, if you send 1 operationRequest, that triggers 1 operationResponse and 2 events, that would be a total of 4 messages.
How many messages are triggered by one operationRequest depends on the kind of operation. On the cloud, which does not support custom operations, opRaiseEvent() is the operation of main interest, as one would normally not join and leave rooms multiple times a second.
Like every operation opRaiseEvent() sends 1 operationRequest and unlike some other operations it does not trigger an operationResponse. On default opRaiseEvent() will trigger 1 event from the server to every other player in the room. This means, that in 1 room with 6 players, when one player raises an event with the default receivers it produces 1 opRequest + 5 events. When every player raises 10 events per second, this sums up to 10msg*6players*(1opReq+5ev)==360Msg/s.
However this formula is only true for the default receivers list of raiseEvent(). For some kind of data it may make more sense to just send it to some players and not to all. For example if the client can locally already know, that the opponents can't see him, then depending on the game logic some data may only be sent to his allies. This way the amount of messages can get a lot lower.

The normal approach would be to send everything, that always needs to be sent together, in one event, but send extra stuff in seperate event.
So you would raise one operation for position and rotation and send this for example ten times per second. You can normally send this stuff unreliable, as if it gets lost the next one position update only 100ms later would already containe more up to date data and makes the old data outdatd, to if one position update gets lost due to bad network conditions it does not make any sense to repeat sending it, as until the client can be pretty sure, that it has not come through to the server, you have already given it the task to raise the next one anyway and until the server can be pretty sure, tha a client has not received it, it has already received the next position data for passing it to that client. Repeating the lost one would mean, that the next one would have to wait, until the lost one has got through, which is normally not what you want. On the other hand shots should be sent reliably, as furhter game depends on the shot info to get through. Therfor you would do a sperate call to raise event, to pass the shoot data with the reliable flag set to true.

At the moment we just log the message-amounts of games and do not enforce the limits, but just keep an eye on the fact, that you should not go beyound them too far with your average room. This means, that some rooms can be above the limits, when other ones are below it. We will have to talk to you, if you are sending tenthousands of messages/second per room, but if you are sending a bit more than 300 currently this woon't have any consequences. However we may enforce these limits in the future, butt most probably not before we offer an option subcribe to higher limits, as we are aware of the fact, that for some types of games 10-20 players per room can be desirable. The current liits are relative low on purpose so tha we can offer lower prices than it woul be possible with higher limits.

Lizzard4000

thank you very much for that detailed answer!!

gameccino

not sure I understand the 500 msg limit.

I see several plans where the CCU grows but the MSG not. in the best case I have 5000 CCU but still 500 MSG/s that if I understand your math is less than a msg per users every 10 seconds.
I plan to do a MMORPG with hundreds of players per room, this looks like an huge limit or Am I wrong?

Kaiserludi

gameccino wrote:

not sure I understand the 500 msg limit.

I see several plans where the CCU grows but the MSG not. in the best case I have 5000 CCU but still 500 MSG/s that if I understand your math is less than a msg per users every 10 seconds.
I plan to do a MMORPG with hundreds of players per room, this looks like an huge limit or Am I wrong?

CCU is overall of players online at the same time for your app: all players in all rooms + players, that are online, but not in any room. The msg limit is per room, so the CCU have nothing to do with this limit, only the players per room are affected by it.
The cloud is currently only targetting room based games like FPS, RTS and so on: gametypes with typically 2-8, maybe 16 players per room.
Real MMOs (usage of the term MMo has been very inflationary in the last years, we are talking about the classical definition here, not just hundreds or thousands of players online, but hundreds or thousands of players all in the same world and all able to interact with each other) need some kind of interest management: no client is able to work itself through the huge amounts of incoming data from thousands of events from other players in the same world, that are not interacting with its palyer in that moment anyway. Photon provides some basic interest mangement with its MMO application, but this application is currently not available and you would probably have customize the serverside logic for an MMO anyway, which also currently isn't possible.
Therefor at the moment for a MMO one should not use Photon Cloud, but run a self hosted Photon Server (depending on the CCU and the hardwarepower cost of your custom serverside logic eventually based on our open source LoadBalancing App on multiple hardware servers, like we do ourselves in the cloud).
Depending on your budget (should be beyond the 5.000CCU mark) asking us via mail for a custom deal, in which we would do the hosting and maybe even parts of the implementation, could also be an option.