0
571
VistasSocket.io & Redis - Proper architecture for an io game?
I'm using a basic NodeJS scaling w/ Redis architecture, but I'm having trouble configuring this to suit a real-time multiplayer game.
My multiplayer game should have separate lobbies - so when the load balancer places a user in a separate server, there is no way players in the same lobby can communicate, unless I use Redis. The problem is, I can't send every single action back and forth between the servers, as that would overload Redis, as well as ruin the scalability of the server instances, since now I have to store every user in every NodeJS instance (to check for collisions, ect), which defeats the purpose of scaling. Unless I'm doing something wrong?
Basic NodeJS/Redis Architecture (Inefficient for an io game with lobbies?)
I've also added a separate running Manager which configures (creates/removes lobbies) the lobbies, and sends the information to the Worker instances via Redis, so the users so they can view available lobbies
I've thought about having each NodeJS instance to be a separate lobby, but the load balancer doesn't work that way. Also, there is no automatic scaling.
My current architecture, showcasing players (users)
Red is for users
Light Pink is for synchronized users via Redis from the other servers into itself (otherwise, players from other instances would not be visible to one another. Also, wouldn't be able to perform simple updates, such as collision detection)
Each player is in it's own chosen lobby, and is an object which possess X, Y, angle, and several other parameters
Even though users would join Worker 2 or Worker 'n', I still need to relay the user profiles to other workers, otherwise users that are not on the same Worker, they will not be visible to one another. Now in this case, doesn't it completely defeat the purpose of scaling?
Either I'm doing something very wrong, or I'm sure there has to be a solution to this!
EDIT
This is what I have come up with myself so far, albeit not sure if it's plausible
I'm getting virtually no help, some comments would be greatly appreciated
1 Respuestas
Responde la pregunta0
Posting comment as the answer
As per the comment, the game is played among teams and each team has some members but each member in the game must know about other members(not only their team members), given each member has to know about all other members in the game, it's good to go with this design.
Though the segregation should be done at a game level, each game should have its own set of Lobbies and each lobby contains all the players.
We don't have to run workers for each Lobby instead one worker can be used for one game and that'll update all the Lobby data.
Also, Loadbalancer should not be used to distribute players among workers instead a middleware should be used in the application like GamePlayerManager/LobbyPlayerManager to add/remove a player to/from a specific lobby.