Turn-Based game with groups, cache, and a centre control master client across multiple rooms

Options
JoH
JoH
edited October 2015 in Native
Hi

We have a card game now running in turn-based cloud and it's perfect fitting our need. We have a master client in a room.
In the near future, we have to build a scenario "multiple room(group) game", and players may need to change rooms (groups) automatically during playing. So we have to have a "super" master client and to manage the whole things across all rooms(groups). (Of course there is still one master client in each group)

We are considering how to send messages to manage things globally.

1. According to some researches in this forum, messages cannot be sent between rooms. So we cannot place different groups of players in different rooms.

2. I was thinking about "groups" feature in one room ,placing all players in one room and assigning different groups to players. But according to http://forum.photonengine.com/discussion/6497/receivergroup-all-doesnt-seem-to-work-for-raiseevent#latest the cache function would be disabled which is not acceptable to our game.

3. like2. , but sending all messages to all players, and then filtering messages by client itself. However it's quite waste because we may have total 100+ players in the same room.

Is there any suggestions to achieve this scenario?

Thanks a lot!
Jo

Comments

  • Kaiserludi
    Kaiserludi admin
    edited October 2015
    Options
    Hi Jo.

    1. Yes, that is correct - messages can't be exchanged between players that reside in different rooms.

    2. Yes, I fear that is correct. Events that are coming from the cache are currently always sent to everyone who has not received them yet.

    3. Just sending everything to everyone and filtering on the receiving side is not a good idea for such high amounts of players inside the same room, as the amount of messages would increase squared to the size of players: if 10 players send 1 to each other player once a second, that would be a room total of (1 outgoing + 9 incoming) x 10 players == 100 messages per second per room. For 100 players it would already be (1+99) x 100 == 10,000 messages per second per room. As you see, you definitely need to have some kind of interest management with such high amounts of players to avoid the amount of messages from increasing squared to the number of players per room, as the amount of messages per second is the main cost driver and we therefor need to limit it to a sane level (100msg/s per room for turnbased, 100 for chat and 500 for realtime).

    Please be also aware that one Client- or Peer-instance can only be inside of one room at the same time, so to have one Client reside in several rooms at once, it would need to create multiple Client instances (one per room) and connect all of them. However each connected instance counts as one CCU, so every Client that resides in such a group room additionally to a normal room would count as two instead of 1 CCU, so if every Client does this, that would result in twice the CCU and therefor twice the financial cost for you.

    4.Therefor the approach that makes the most sense may be a fourth option:
    Additionally to the Photon TurnBased also use Photon Chat. All Clients would then join their normal room in Photon TurnBased, but all Clients that are part of a multiple room game join the same Channel in Photon Chat. They could then just send messages to players from different rooms through the Chat service (Photon Chat is not limited to text messages, you can send any data type there that you could send with any other Photon product).
    I don't know if this is feasible for your as as Photon Chat does not support event caching or room properties.

    5. You could of course just host you own Photon server and modify and enhance it to better fit this multi-room games scenario. Setting up and hosting a Photon server is rather simple, but pay attention to traffic costs, which are astronomical on the usual cloud-hosters. Bare-metal server usually make a lot more economical sense for the main userload. Also, modifying and enhancing the Photon server source code to support your needs can easily be quite a bit of work when everything needs to scale well.

    6. Like 5, but we host and maintain an enterprise cloud for you. However this is pricing-wise only making sense, if you expect to have thousands of CCU.

    7. Theoretically we could also implement a feature request from you like making event caching compatible with receiver groups, interest groups and /or target players, but you would most likely have to pay the developer hours on a consultancy base.

    Maybe it helps if you explain a bit more in detail how we should imagine such a multi-room-game.