Is there a hard limit on how many players can join the same match?
Let me give some context.
I’m planning to build a game with a global, persistent game state. All players connected to the server would load the same game state and get events from that state.
I have pondered this and come up with a couple of possible ways to achieve this:
A huge match. If there is no limit to how many clients can join one single match, this might work. The match itself could control and limit the amounts of messages sent to avoid overloading the clients (and itself).
Many matches using a storage object. Each match would save new data to be added as a temporary storage object and an admin match would consolidate them. Each match would then poll the global storage object state at regular intervals.
Which one of these approaches makes most sense? Are there alternative ways to achieve a globally shared state?
Update: I’m going to try to use one match and hope that there is no player limit.
Matches don’t have any hard player limit, it all comes down to the tick rate, bandwitdh and server resources. You may add players without restriction, but in practice you may start to see degradation of the match ability to keep the tick rate stable depending on how much work it has to do (and how much you can optimize).
If there’s some way of logically splitting the state between matches (in-game zones, or “servers”, etc) then you may be able to spread the load more evenly without requiring too many changes to your logic other than having the client joining the right matches dynamically - this really depends on the type of game you’re building.
Propagating state changes across all matches may become tricky via the Lua/JS runtimes - we provide a shared server cache but it doesn’t come without tradeoffs and can easily become a point of contention. If you’re writing your code in Go, then you could use something like channels to propagate state changes between them.
Thanks, that’s really helpful. My use case is an open world, where “all” players contribute to a common goal that’s visible to all players.
In a scenario where thousands of players are connected simultaneously, there has to be logic to limit the amount of data sent to clients. Knowing that there is no hard limit, the trick then becomes setting the tick rate as low as possible, and optimizing who to send what to in a logical way, and minimize actual work done by the server, as you suggested.
Then I guess the plan is to beef the server up according to user numbers!
I appreciate this is a rather odd use case, and maybe using go instead of Lua is a better approach.
