As a personal project, I'm setting up a MMO, and writing the server in C#/.NET Core.

As of now my architecture is as follows: The world exists of different areas ( you can go from area to area trough portals ). An area is called a 'room' on my server. Each room has it's own list of clients ( players, each with their TCP stream ).

Now I was wondering if it was ok that I run each room on it's own thread. Each room will manage it's own update cycle ( game loop / room ), as it's independant of other rooms.

My worry is that as the game grows, I will get lots of areas and that a thread per area isn't that great of an idea.

So my question is: Am I doing something wrong or non-benificial in the future ? Am I better off having 1 thread for the game logic for all the rooms ? Or is it ok to have a thread per room ?

• I'm voting to close this question because it is a cross-post from Software Engineering. Cross posting is not allowed on stack exchange sites. Please choose the site you think will give you the best answer for your situation and post only there. – Vaillancourt Oct 1 '18 at 14:11

By the way, you might want to organize your code around the ThreadPool class and pass Tasks to it where each task consists of performing a single update-tick for a single room. The ThreadPool can be configured to use a specific number of threads. You shouldn't set it higher than the number of (virtual) CPU cores. When you give it more tasks than it has threads, those tasks will be enqueued and processed as soon as a thread is finished. That means you can leave your update scheduling to the framework.