Infinite chess board problem.

Hi,
I'm creating a game, but I don't find any solution for this problem without using HTTP requests or writing my own multiplayer engine...
To put it simply (the game is very different and more complex), it is a game similar to chess where the player manipulates a king and can only see the 9 adjacent squares (top, bottom, top-right, ...) . He can move to one of these squares (because he is the king), when he moves, he then sees the 9 new adjacent squares. He also sees when another player moves.

I'm trying to implement this with Photon (PUN) and rooms. Suppose the game contains 10,000 players. This implies that if there are many rooms (one room for a number of squares), for certain movements, it will be necessary to move from one room to another. The player will therefore not be able to see the players in the squares of the room he left unless we can send messages from one room to another or from a lobby to a room. Another solution would be to group all the players in one room, but like I said the game is more complex, movements are not the only messages to send.

Thank you for reading and for suggesting me a solution (even if it is not necessary PUN-related).

 

So first, I'd question your assumption that a single "game" would have 10,000 players. Even the most optimized MMOs can barely handle 1000+ players in a single area of interest (google Eve Online and time dilation, or look at Albion Online and Das Tal for how indie studios deal with the MMO challenge). So unless someone on the forum knows some examples that I do not, I can't imagine a server architecture that can handle that many players passing any kind of messages back and forth for one "game" with room splitting or not.

Also, if you are really looking for that scale of players -- you are talking at least $2,000 in photon ccu + whatever your bandwidth cost is. It might be a better investment to hire an engineer to architect your own custom solution that you will host on your own hardware instead of running that in Photon.

Now, following up on that -- I don't think your split of "some blocks per room" utilizes the photon network stack the way that Exit Games intended. If you were going with pieces can jump from board A to board B model, then rooms might make sense, but even then, I've always thought of rooms as instances of a running game match. So in your typical first time online game loop:

* Player opens game first time and creates an account.
* Player then logs in with their new account
* Player now joins a lobby, shares meta data and chats with other players to identify which "match" he wants to join
* player joins match and plays until someone wins

In that example above, there are two rooms -- the lobby for people to chat about matches (and to exchange other match making data for skill ranked matches) and then the second room is the match that the player joins and plays until someone wins. Photon limits that to 16 players by default, per room, though you can ask them to lift that limit a bit -- but I imagine they will try and push you over to Photon Quantum (which is an alternative architecture instead of PUN2) for the scale you are talking about.

Now, going back to your "9 adjacent squares" question, I think what you are asking for is what Photon used to call Interest Management (or area of interest management) -- but from my reading tonight, it looks like their mmo demo is no longer supported with PUN server V5. I don't know if they deprecated anything in the SDK that blocks your ability to follow their examples, but it is not a good sign if they stopped shipping a demo showing how to do this with PUN2, so maybe it would be best to look at other solutions if that is the true scale you are looking to achieve with your game.

 

Thank you for your detailed reply.

The term "Interest Management" is exactly what I was looking for, I think it is still possible to do this with Photon by using interest groups. I was aware of groups but figured if I used them it would mean that I would make a single room for the game that had all the players in it. This would be problematic in the sense that some decisions are only made by the masterclient, if he has connection issues the game will be glitchy or even broken despite automatic switching, it is too much dependence on one person.

The 10,000 players won't actually be in just one area of interest. The player only needs to see the movements of adjacent players, so only 9 players in an area if possible. There may be 10,000 players who can play the game at the same time (like among us with a peak of 3.8 million CCUs).

The complexity of the game is not in the multiplayer architecture, so with the storage cost, the database, hiring an engineer is likely to be more expensive in the short term. The only difficulty is what this topic is about, how to group together a large number of players so that each one can send messages to a part of them, that part changing over time. If I have 10,000 players at the same time, I'll probably be able to afford the $2,000, so unless photon can't handle that number of players without worrying about architecture, that won't be a problem.

I agree with you. However, the game has not several matches, just one for all players. The typical first time loop is :
* Player opens game first time and creates an account.
* Player then logs in with their new account
* Player join the match and play until he loses (like agar.io but the map is not limited)

If there are no matches, he creates the match. I can use Photon with one room, from what I understand from the documentation, there is no limit of players in a single room. The default is 16, but I can lift it when creating the room. But if there are too many players in this room, maybe I am wrong but there might be negatives consequences. Quantum is for fast paced multiplayer, the game I'm trying to make is more like turn-based with a time limit for each turn, I don't think I'll need Quantum for that. Lag, sync and send rate are not a worry.


In sum, I will go with creating one room, and use interest groups, but if anyone has another solution thank you for letting me know.