Any big winners here lately?
You can check the leaderboard i suppose, they have a daily, weekly, monthly and all time leaderboard filter.
Topic: bustabit – The original crash game - page 16. (Read 61368 times)
You can check the leaderboard i suppose, they have a daily, weekly, monthly and all time leaderboard filter.
Any big winners here lately?
Daniel please get back to this message soon, I have an issue regarding Bustabit
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.
Devans please don't make your decision final. It's clear that you're doing it because you assume I have a problem but I have only been playing with disposable money that I've had to my expense for years.
Just please unban me
Daniel please get back to this message soon, I have an issue regarding Bustabit
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 I cannot use your sites intergrated support feature. I have attempted to send emails on a few occasions which had no response so i decided to try this website, the next best thing. Is there any way I can open a private direct message with you here or anywhere else?
If the request must be through the websites support system then you will have to check why the emails of account "[email protected]" are not getting through
Daniel please get back to this message soon, I have an issue regarding Bustabit
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
So you really need to create a main thread first before posting here?https://bitcointalksearch.org/topic/m.57820129
and why not explain what is the main idea why you wanted to directly ask Daniel when there are a proper forum to ask your problem?
Daniel please get back to this message soon, I have an issue regarding Bustabit
contact their support(it is also the best way to get in contact with the owner) . is the issue regarding bustabit so bad that you won't contact their support and should only be heard by the owner? if not. it's better to elaborate the issue here.
Daniel please get back to this message soon, I have an issue regarding Bustabit
Why is it necessary to correct the start time on each heartbeat? How does the start time change?
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.
Quote
"So the client basically has two options..." Could you perhaps elaborate more on this? I don't really understand what you ment.
What part of my explanation didn't you get?
In case the client does not receive a game tick it can show a 'reconnecting' animation or something similair. I completely understand that and it makes much sense to me. However why is the including elapsed time necessary in this event?
Earlier you said this is used for correcting the start time, why not just send a unix timestamp when game emits the start event? This way desync can never happen since the client has the start time of the game and does not calculate this time itself. If the game start event is emitted 5 second later, the client will still receive the correct unix timestamp when the game started since this does not change in the backend.
So instead of sending: game_tick: 1041, why not send game_tick: true (assuming this is only used as a heartbeat you explained earlier).
I don't see the need of the elapsed time here.
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!
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!
Hey Ryan, thanks a lot for your answer!
"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 "
Why is it necessary to correct the start time on each heartbeat? How does the start time change? Lets say the client somehow decided the start time to be 5000 but the server actually started at 5001 it will correct this start time on the very first tick it receives, where can it go wrong from there? Why would the client suddenly change the start time?
"So the client basically has two options..." Could you perhaps elaborate more on this? I don't really understand what you ment.
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.
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.
Thanks for your answer!
How can the client and server get out of sync though? They only need two variables, the start time of the game and the current time. Both of these can not change since its a simply subtraction.
Even if one of the two variables is subject to change (I dont know how) then I don't see how the game tick of 150ms which gives back the elapsed time can help in correcting this.
I understand emitting back the elapsed time can be used to check if the elapsed time on the client is the same, but as far as I know start time and current time are always the same regardless of where it is called from so there shouldn't be a difference.
About your second point, why is exactly broadcasting cash out events individually not fast enough? If you broadcast them only on ticks wouldn't that result in a delay (not a delay for actually cashing out but a slight delay in updating the bets for other users)? if I cash out at timestamp 3000 and the next tick is at 3150 it will show my cashout of timestamp 3000 'happening' at 3150 for other users.
Lastly the third point you gave, this is the only reason why I could see the purpose of emitting the backend ticks to the client. But lets say a game lasts 3000ms, a user laggs for around 8000ms, when the user resumes it will for instance receive game tick 4000, what useful information can it get from this? I understand it can ensure that the game is alive but it can't conclude from that '4000' that its still the current game or the next one. In my eyes emitting the game id would just be enough if its purpose is only for sending heartbeats.
Perhaps I'm missing something here, which I probably am I guess haha. Just correct me if I'm wrong
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.
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.
Hey everyone,
I have some questions about crash games in general and I think this topic is the right place to ask.
Lately I've been wondering about a few things:
Most crash games send game ticks (every 150ms or so) to the client. I'm having a hard time understanding why they do this. Bustabit (and also the old v1 src) does this as well. I know the backend has to loop/tick every 150ms to do cashouts and such, but why would you emit that back to the client. If the client just keeps track of the start time of the current game and updates the counter according to the same formula the backend does then it is always in sync with the backend whatsoever since both sides do a simple subtraction (current time - start time) and pass this onto a function which gives you back the multiplier/point it should be at.
So what is exactly the purpose of the backend emitting the current tick/elapsed time to the client? If the client receives the crash event then it knows the game crashed and can show the crash animation or something similair. I've been looking around in the chrome devtools network tab (filter on WebSockets) and almost every crash gambling site seems to send ticks back to the client, except for one site (https://www.csgoroll.com/) which just sends the start and crash event and nothing else which seems to work fine.
Initially I sent the above (a little adjusted) to Ryan but he forwarded me to this topic so others can also benefit from potential answers
If someone can enlighten me on this specific question I would greatly appreciate it!
- sharpness
I have some questions about crash games in general and I think this topic is the right place to ask.
Lately I've been wondering about a few things:
Most crash games send game ticks (every 150ms or so) to the client. I'm having a hard time understanding why they do this. Bustabit (and also the old v1 src) does this as well. I know the backend has to loop/tick every 150ms to do cashouts and such, but why would you emit that back to the client. If the client just keeps track of the start time of the current game and updates the counter according to the same formula the backend does then it is always in sync with the backend whatsoever since both sides do a simple subtraction (current time - start time) and pass this onto a function which gives you back the multiplier/point it should be at.
So what is exactly the purpose of the backend emitting the current tick/elapsed time to the client? If the client receives the crash event then it knows the game crashed and can show the crash animation or something similair. I've been looking around in the chrome devtools network tab (filter on WebSockets) and almost every crash gambling site seems to send ticks back to the client, except for one site (https://www.csgoroll.com/) which just sends the start and crash event and nothing else which seems to work fine.
Initially I sent the above (a little adjusted) to Ryan but he forwarded me to this topic so others can also benefit from potential answers
If someone can enlighten me on this specific question I would greatly appreciate it!
- sharpness
Generally speaking, the support requests I could delegate to someone else don't require much time to resolve, and those that do take time to respond to can't be delegated because they require database access to resolve. As a result hiring dedicated customer service representatives hasn't been worth it so far. Besides, I think it's valuable to players that they can immediately and directly get in touch with someone who can help them when they need to
Given the number of users there could be enough tickets to be an annoyance but finding the right people for customer support in the cryptocurrency space is definitely a problem. The kind of people that will do the job well and can also be trusted will get bored quickly and start looking for other opportunities.
This is a general issue in software support. It is very difficult to find good people, but the ones you do find are completely underchallenged after six months at the latest and quit again or want more demanding jobs. However, you will never be able to give a support employee access to funds (FIAT, Bitcoin, ...), the potential that something happens here and you are cheated as an operator is very high. We have now solved this in our company via bots. These can handle about 60% of the requests ("please reset my password", "i don't know how to deposit", ...). About 30% are then handled by level 2 support staff and the rest comes to the owners themselves, especially when it comes to special withdrawal requests or legal threats.
It's probably a trust issue and a lack of need. It's definitely hard to find good support people that are knowledgeable about the space (and I'm assuming he doesn't want someone to just read off of a script), and even harder to trust them. If you give too much access, they could theoretically steal lots of money. If you give too little access, you'd end up doing a lot of the work yourself anyway. My guess is that bustabit/bustadice don't end up getting too many support tickets in the first place so it's not a big deal for him to personally handle all of them.
Given the number of users there could be enough tickets to be an annoyance but finding the right people for customer support in the cryptocurrency space is definitely a problem. The kind of people that will do the job well and can also be trusted will get bored quickly and start looking for other opportunities.
What has the amount of profit he might or might not be making got to do with him hiring or not hiring people to help him out?
DarkStar_ has mentioned reasons why Bustabit and other websites might not need or want to have staff handling customer emails, it seems certainly plausible. Even some huge corporations employing hundreds of people inform customers to wait 24/48/72 hours for a reply, some even cite a week. If devans is replying sooner including to someone who has opened multiple tickets in 7 hours then that statistically is excellent and he deserves credit which is why your post baffled me.
After reading your post I thought it was worth a look in to your recent posting history therefore I posted about you for not being the original owner. If I have written anything wrong please free to post in that thread to contest it or correct me but allow devans to keep this thread about Bustabit: https://bitcointalksearch.org/topic/m.57530459
Why do you end up doing all of that all by yourself without getting any help, is it more about trying to protect the website from someone to come in and change something and ruin it? Or maybe some support staff acting unprofessionally and destroy your reputation? If that is the case we all know you already, I doubt we would put it on you when they do a mistake.
DarkStar_ has mentioned reasons why Bustabit and other websites might not need or want to have staff handling customer emails, it seems certainly plausible. Even some huge corporations employing hundreds of people inform customers to wait 24/48/72 hours for a reply, some even cite a week. If devans is replying sooner including to someone who has opened multiple tickets in 7 hours then that statistically is excellent and he deserves credit which is why your post baffled me.
After reading your post I thought it was worth a look in to your recent posting history therefore I posted about you for not being the original owner. If I have written anything wrong please free to post in that thread to contest it or correct me but allow devans to keep this thread about Bustabit: https://bitcointalksearch.org/topic/m.57530459
Yeah, I answer all support requests myself. Generally I respond to all messages within 24 hours. In this case the longest response time to their multiple tickets was 7 hours and 2 minutes, which I think is reasonable.
Lol, why though? I mean you must be making good enough profit to hire someone else for helping you out right? I have zero clue how much you make, it is probably easy to calculate based on what people made and lost since the start of the year on the investment page and then calculate your cut on that. However even without doing that, I assumed that you were making good enough profit to hire some people, not even just one person but more like multiple people to help you out, could be about coding, design, support staff and many things like that. Why do you end up doing all of that all by yourself without getting any help, is it more about trying to protect the website from someone to come in and change something and ruin it? Or maybe some support staff acting unprofessionally and destroy your reputation? If that is the case we all know you already, I doubt we would put it on you when they do a mistake.
Yeah, I answer all support requests myself. Generally I respond to all messages within 24 hours. In this case the longest response time to their multiple tickets was 7 hours and 2 minutes, which I think is reasonable.
Lol, why though? I mean you must be making good enough profit to hire someone else for helping you out right? I have zero clue how much you make, it is probably easy to calculate based on what people made and lost since the start of the year on the investment page and then calculate your cut on that. However even without doing that, I assumed that you were making good enough profit to hire some people, not even just one person but more like multiple people to help you out, could be about coding, design, support staff and many things like that. Why do you end up doing all of that all by yourself without getting any help, is it more about trying to protect the website from someone to come in and change something and ruin it? Or maybe some support staff acting unprofessionally and destroy your reputation? If that is the case we all know you already, I doubt we would put it on you when they do a mistake.
It's probably a trust issue and a lack of need. It's definitely hard to find good support people that are knowledgeable about the space (and I'm assuming he doesn't want someone to just read off of a script), and even harder to trust them. If you give too much access, they could theoretically steal lots of money. If you give too little access, you'd end up doing a lot of the work yourself anyway. My guess is that bustabit/bustadice don't end up getting too many support tickets in the first place so it's not a big deal for him to personally handle all of them.
Yeah, I answer all support requests myself. Generally I respond to all messages within 24 hours. In this case the longest response time to their multiple tickets was 7 hours and 2 minutes, which I think is reasonable.
Lol, why though? I mean you must be making good enough profit to hire someone else for helping you out right? I have zero clue how much you make, it is probably easy to calculate based on what people made and lost since the start of the year on the investment page and then calculate your cut on that. However even without doing that, I assumed that you were making good enough profit to hire some people, not even just one person but more like multiple people to help you out, could be about coding, design, support staff and many things like that. Why do you end up doing all of that all by yourself without getting any help, is it more about trying to protect the website from someone to come in and change something and ruin it? Or maybe some support staff acting unprofessionally and destroy your reputation? If that is the case we all know you already, I doubt we would put it on you when they do a mistake.
Yeah, I answer all support requests myself. Generally I respond to all messages within 24 hours. In this case the longest response time to their multiple tickets was 7 hours and 2 minutes, which I think is reasonable.
Jump to: