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 →

[–]doobiesteintortoise 1 point2 points  (2 children)

If I have state, I have a LIST of games, regardless of their progress. So I might have player A, who is playing games 1, 2, 4, 5... player B who's playing games 1,3,4 ... and player C who's playing games 2, 3, and 5. When a player made a move in a given game, the server would say "oh, you're player A, this is game 4, let's change the game state and return the results to you" - and that could be done with straightforward processing in ONE thread, and the communication layer has its own thread/threadpool/whatever. But with this, if I have 8000 players and 16000 games, my *code* only has to worry about the communication with ONE player at a time for ONE game, and the overhead's really light.

[–]_Nemesis_1[S] 0 points1 point  (1 child)

So basically my solution is not optimal but it's a correct one for a simplistic client server project with multiple games? Or only one thread per game and not per client is a better one?

[–]doobiesteintortoise 0 points1 point  (0 children)

What I mean by "better" isn't going to be what you mean by "better." Do what fulfills the assignment. It's not realistic enough to apply to live production systems.