Topic: bustabit – The original crash game - page 16. (Read 61604 times)

So this is something talks about some shitty talks on chatbox or totally attacking personally? It would really be just unjust or not really that sensible if they do just block you or banned out for that simple reason.

For sure there are other possible violations that you had committed because they cant just make out such decision just because of that.

Have you pm'med him on his forum account?

Daniel can you just unban my account under the name of "Perplex123"?

I said something stupid after losing some bits but I never said I had a problem. Just unban me brooo I just want entertainment


Dont say "No my decision is final" either, you banned me for virtually no reason. I've proven I dont have a problem yet you still dont acknowledge my messages

Yeah, I was more so curious if there were any individual big wins or high multipliers recently. Maybe Daniel can create a new tab titled "Big Wins" or "Highest Last Multipliers" or something along those lines.

Probably what OP is looking for is someone that's winning something in just one game, something like a jackpot some players are just playing a lot of games and causing them to get listed in the leaderboards.

Probably what OP is looking for is someone that's winning something in just one game, something like a jackpot some players are just playing a lot of games and causing them to get listed in the leaderboards.

You can check the leaderboard i suppose, they have a daily, weekly, monthly and all time leaderboard filter.

Any big winners here lately?

As others have already told you in this thread, the best way to get help with your bustabit account or get in touch with me in general is via https://www.bustabit.com/help/contact. As I cannot discuss an account's private information with anyone but its authenticated owner–among other reasons–I do not provide account support in the forums.

As others have already told you in this thread, the best way to get help with your bustabit account or get in touch with me in general is via https://www.bustabit.com/help/contact. As I cannot discuss an account's private information with anyone but its authenticated owner–among other reasons–I do not provide account support in the forums.

Daniel please get back to this message soon, I have an issue regarding Bustabit

Daniel please get back to this message soon, I have an issue regarding Bustabit

Daniel please get back to this message soon, I have an issue regarding Bustabit

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.