I'm trying to develop my first ever browser-based multiplayer game that utilizes my own websocket server which has no multi-threading capability.

It will be a game where players try to be the fastest in solving as many puzzles as possible in a particular amount of time. Whoever solves a puzzle first wins that round and the next puzzle is served, until time has expired. The player who solved the most puzzles first wins the game.

To keep the CPU-load of the server as low as possible, I'm trying to come up with a strategy that signals clients when time has expired. You see, while games are ongoing I'm simply waiting for input from clients with socket select and a reasonable select timeout. This works nicely to keep the CPU load down. But, as my server has no multi-threading capability, I'm trying to prevent my server from monitoring ongoing games in a busy while loop (continually interrupting socket select), merely to monitor if time has expired.

So, I thought about simply waiting for client input and only then signal the client that time has expired. And if per chance no player is responding anymore (they all disconnected, left game, etc.), I simply mark the game as finished if the game state is requested at some later time.

Do you see any problems with this strategy? And, can you suggest other strategies that I may have overlooked, that don't rely on a busy while loop?

Just after posting the question I realized that I haven't thought things through enough, because I'm faced with the same conundrum of signalling the start of the game as well, of course, which actually is much more time critical. :-(

Actually, after given it a bit more thought still, I think I can signal the start of the game to all clients as soon as the last player has entered the game. So that may not actually be all that problematic after all.

  • 1
    \$\begingroup\$ Why can't the client just count time using its own clock? If you're worried about cheating, just have the server verify the time elapsed since the "round start" message timestamp for that game session when it receives an "I solved the puzzle!" message. \$\endgroup\$
    – DMGregory
    Jun 30, 2022 at 19:49
  • \$\begingroup\$ @DMGregory Yeah, that sounds reasonable. I'm more worried about one client's time expiring too soon than about cheating. I thought seasoned game developers on here might argue that client-side is simply not reliable enough, as some client's time might be less accurate and maybe drift. But I don't know how likely that actually is, if at all, especially if I continuously monitor Javascript UTC date on the client-side. So I guess if I do it like you suggested and read up some more on client/server time synchronization on here as well I might find a workable solution. \$\endgroup\$ Jun 30, 2022 at 20:17
  • 1
    \$\begingroup\$ If your computer clock drifts by a perceptible amount over the duration of a game round, the spring probably needs winding. 😜 \$\endgroup\$
    – DMGregory
    Jun 30, 2022 at 20:29
  • \$\begingroup\$ Yeah, good point! You are right of course; I'm way too concerned about unlikely/insignificant what-ifs. Cheers! \$\endgroup\$ Jun 30, 2022 at 20:31
  • \$\begingroup\$ If you solve your problem, be sure to post your solution as an Answer below. \$\endgroup\$
    – DMGregory
    Jun 30, 2022 at 20:32


You must log in to answer this question.