Hi to all,
This question is more conceptual as compared to technical. It does not relate to server-client relationships in relation to real-time gaming, whereby the server handles all the game logic and the client simply acts as a renderer. I know that that would essentially involve:
- A “decent” server tick-rate.
- Lag compensation.
- Entity interpolation.
- Input prediction.
Among other things that can be done to optimize an online game. I also know that it involves using UDP over TCP if the game needs to be fast (loss of data during transmission can be compensated for via entity interpolation and so on).
My question revolves around the concept of how many world objects the client can actively support without being laggy. I know that that doesn’t really have an answer and generally depends on the power of the computer that hosts the client.
As an example, consider a server that can support say 800 players or so. Not all those players are going to be view-able, and player number 0 doesn’t need to know about players 1-799 even though they are on the same server [this example assumes that all 800 players are logged in at the same time and are in the same area of the game-world]; player 0 would need to know about say, players 1 through 9 or players 1 through 19 . So I take it that there’s usually a limit as to how many players player 0 would need to know about. Maybe just 10, or 20 at most.
With this in mind, all 800 players would need to be placed into groups of 80, if the maximum amount of visible players is set to 10, or 40, if the maximum amount of visible players is set to 20 per client. These groups would be “rooms”, “group-instances” and so on, running on the same server, each dealing with their own relevant sets of data. The server would then have 10 or 40 world-simulations to perform periodically based on it’s tick-rate, I take it that these simulations would have to be done in threads so that all the data-sets are processed simultaneously. As each group would be it’s own instance, there would be no such thing as “resource-racing” between the threads, since they would not be interconnected and would each be handling their own data-sets.
Well, that’s pretty much it…in games that support that many players, would that be a viable approach? If not that one, then does anyone have a different way of handling this issue? Remember that the question is about instancing within one server, not running the game in multiple servers; of course there would be multiple servers, but they too would be faced with the same task of dividing the players who are logged in into groups.
If some part of the question isn’t clear, please point it out and I’ll try and clarify it.
Thanks in advance.