Hi,

Hmm.. I am currently going through different designs of game server back-ends and it gets me wonder: how would you scale single-threaded server?

What comes to my mind atm. is that if the server is made using back-end like node.js would it be possible to start e.g. 4 node.js processes which all are executing the same game server program? (to benefit from amount of cores available).

I noticed that this is called "clustering" in node.js or something.

Nevertheless, the problem which troubles me is the fact that I think (?) I cannot control which of these processes are getting the requests and I would like all of the players from 4 different processes to be able to interact in a same virtual world through websockets. That leads to a question that has anyone done anything similar?

Hence, I had also an idea of using redis as an intermediate to store the game state, so all processes can read/write to it:

redis

process 1 -- | -- process 2

process 3 -- | -- process 4

But that would still mean that each of these processes has their own game loop and it confuses me concerning the interactions? when player i and j stands next to each other they could come from process 1 and 2... can they even collide like that? :wacko: any ideas? thus, couldn't find any material of using multiple server-side game loops like this.

how would you scale single-threaded server?

Thanks for the replies, they gave me some ideas to try out. For now I will try to go with an approach that they are only one game loop -process per computer, and features which can be run independently will be run at different processes.

I also looked into making processes to listen on different ports, and I have a feeling that it is possible (even though all the examples shows how to listen same ports).

After these changes, I think I have something like the following:

One server has:

- Game process (basically, the game loop stuff - fast actions - movement/attacking/NPCs etc.)

- Chat process (doesn't need to be that fast, but needs mostly likely AOI to filter sent messages)

- Template process (responsible of returning e.g. data for the dialogs and alike.. when you open a shop?).

- Anything else?

Hmm.. the point with this approach is the fact that single-threaded server doesn't like sending of big responses like templates.. but also that I can use separate websocket connection from client to game and chat process. (chat connection can be then closed by the user if wanted etc.)

And yes, I guess I still need a one server which knows all the game servers in the system so that player can be connected them appropriately.

Do the shop templates have to be big? Server can send a message that contains SHOW_SHOP_INVENTORY followed by a number of how much items, and followed by N pairs of quantity and item-ID. Everything else (the names, the dialog, etc) is invariant stuff, can be stores on the client.

Yea, I think you have a point there. Then I could add just more logic to the client-side that it is able to place that information into these dialogs which are generated with js or picked directly from the DOM. That being said, I would probably still make the separate template server because if I build it using react or something I would minimize the risk of doing javascript memore leaks which may occur with these kind of SPAs.. so there are some trade offs which needs to be taken into consideration.

Take a look at how irc networks work.

It's worth looking into how others solved problems, even outside of the games industry

It's worth looking into how others solved problems, even outside of the games industry :)

Trust me when I say that I have, I have been googling all over the place and tried to fit my web development knowledge to game development as much as I can :rolleyes:.. there are just infinite amount of things to learn when it comes to making mogs - maybe that is the reason why it is so interesting. :cool: