Well, it's not necessary. But it's better to do, and it's easy. So why not?

Basically it handles this situation:
Client receives a "game started" event. Client records the time it got the game started.  5ms later, the server says "the game has been running for 150ms".

With this information, the client can know that the "game started" event was lagged out (e.g. network problems). It can safely update the "game started" time to be 145ms earlier than it previously had it.



What part of my explanation didn't you get?

Hey, good question!

So starting from first principles, the server needs to let the client know these events:

a) The game starting
b) When cash outs happen
c) When the game ends


And let's remember, there is a certain amount of time it takes for the server to communicate with the client (latency).


So the most naive solution is simply to broadcast all the events in real time. That will work fine, but the first issue you'll run into is when there's a network connection the client won't (immediately) realize and it'll look like the multiplier is going super high. When the network connection issues resolve, the user will be disappointed to learn that it didn't really go that high.

So we're going to need to broadcast a "heartbeat" (or game tick). Ideally multiple times per second, so if the client doesn't get the heart-beat it knows immediately something is up.

That's going to work fine now, and we're in business. But each message we send/process incurs overhead, and with a lot of events it's going to cause issues on both the server and client. Bustabit v1 was notorious for this. So there's a whole slew of optimizations we can make.

So let's go through a few that bustabit v2 employs:

A) Sends the client the (auto) cashout of the other players. That way the client can "predict" other players cashing out, and there's no need for the server to say the player cashed out at that point. This way the server only tells clients when a player manually cashed out.

B) Batch cash out events. If people cash out at the same time (or close to it), just send it in a big message.

c) Combine heart-beats with cashout events. If the server sends a cashout event, obviously the network connection is fine. No need for a heartbeat in that time.


---

And your question regarding synchronization is a little tricky. So two things to remember: there is always latency between the server and client. It's not possible for the server to tell the client the exact time the game will crash (until it actually crashes) or people would hack the client to easily cheat.

So the client basically has two options. One is to try show the multiplier that is CURRENTLY on the server. The other is to show the multiplier that the player would get if they hit the cashout button. The first solution is better for when you lose (it shows a lot smoother). The second solution is better for when you win (players are a lot less affected by latency. But the multiplier will overshoot the actual crash, i.e. the player will see 1.92x and then see "busted at 1.90x").

So bustabit tries to go more with the first approach. And each heartbeat it tells the client how much time has elapsed, which the client can use to correct its idea of when the game started (i.e. latency is not necessarily constant. It might get better and worse ). You can see how bustabit v1 did this:

https://github.com/kungfuant/webserver/blob/master/client_new/scripts/game-logic/GameEngineStore.js#L192-L195

--

Hope that makes sense!

One reason is indeed ensuring that clients stay in sync. While most devices' clocks don't have much drift, we can't expect every device to be accurate, so it's safer to not entirely rely on the client like that.

But I suppose the bigger reason is simplicity and efficiency. Oftentimes there are lots of cash-outs happening simultaneously and broadcasting each of these events individually isn't fast enough, so bustabit broadcasts cash-out events in batches on every tick instead. We could skip the broadcast if there weren't any cash-outs since the last tick, but it's simpler to just broadcast every tick, regardless of whether it contains cash-outs or not.

Finally, the broadcast tick also serves as a kind of heartbeat, allowing the client to assume that the connection has been lost if they haven't received any events from the server in n seconds.