Questions, and MORE boring serverside stuffs

Oof, sorry, it’s been a while since I’ve been able to work on this project, and the clock is ticking!

Clues!

Clues can now actually be selected and that will be reflected to the server and all players. You can also see a bit of the buzzer work I started, which is actually much more of a pain than it would seem. Why? Well that’s because we now have to talk about:

SYNCING TIME OVER THE NETWORK

The server running the game has a system time. Your computer, phone, or whatever, also has its own system time which could vary entirely from the server’s. If the server wants to schedule an event (say, when you should be allowed to buzz in), how does it tell the client when that is without an offset?

Using Unix timestamps is common, but without knowing how offset the client is from the server, we don’t actually really know when that timestamp is in reality (since EITHER could be offset from reality, if not both), and we don’t want mismatched times to cause weird problems.

The solution that I went with is that the client will periodically (every 1 second for now) send a “ping” message to the server with its current timestamp. The server will reply with that time as well as it’s own timestamp. Upon receiving that reply, it can then do three things:

1. Calculate the round trip time (i.e., ping!) from the original time we sent and the time it is now.
2. Estimate the server time as we’re processing this by adding the server time + half of the ping
3. Calculate our time offset from the server by subtracting our time from that estimate

I admit that I did NOT figure this out on my own. Google is nice. But this does actually kind of serve as the basis for how things like the Network Time Protocol (NTP) work.

Reminder that all of that is just so we can show when the buzzer is allowed to be pressed accurately.

Spectating

Also, I added a fix so late players aren’t actually awkwardly added in the middle of a game and are instead in a kind of “spectator” state; since they’re still connected, they receive all the game state events and so on. If all actual players leave, the game will reset (which also means I now have a function to reset the state, and for showing alerts!).