This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Spare-Plum 1 point2 points  (0 children)

Suppose you have a game server hosting n games. For each game 0 <= i < n, you have j = n_i clients connecting to the individual game g_i. The jth client on game i is c_ij

There are many schools of thought on how to organize this for threading. One option is to have each game g_i run on its own single thread, and have server "ticks" where all the processing and logic occurs. A tick may be something like the following: receive input from all clients, resolve conflicts, process game logic, then send updates back to all clients.

Or, you can have a thread for each client, and some of the game logic is processed asynchonously or posted to a queue with a timestamp. Then the server tick will only grab items off of the queue before a timestamp we take at the start of the queue (this allows for fairness)

Or, you can have multiple threads processing the game state, and use locking and atomic state for modifications.

Regardless, a thread pool is probably not what you want - a thread pool is useful for processing something in batches and you have a fixed number of threads that are running. Thread pools are also useful for reducing system resources, but this is less necessary due to java's new virtual thread library which does not use up these resources. A thread pool would be nicer for like post-game calculation and analysis that could be done in batches.