Recommended Posts

13 hours ago, MeOne said:

our team is full of congenial friendly players, but when we want to invite new players, one of them must go.
This is very disappointing. Could you increase the team-size, please?

It was raised 3 times... by 5 slots each time. So it went from 20 up to 35.

Maybe create twin team to yours?

Edited by Beridok
Link to post
Share on other sites
  • 2 weeks later...

If you increase the team size, the challenges would become easier than the developers meant them to be -- so they'd increase the thresholds.

It would also increase the ability of the top players to band into fewer teams, for a better chance at trophies and faster challenge completion.

I don't think anyone wants that, especially not smaller teams.

Link to post
Share on other sites

But what is the benefit of faster challenge completion? No one wins more then the other. Only to wear the newest hat earlier? Or to win the 2x 700k before the others?

To be fair the thresholds could depend of the amount of members:

50000/35
57000/40
85000/60

 

Link to post
Share on other sites

But what is the benefit of faster challenge completion? No one wins more then the other. Only to wear the newest hat earlier? Or to win the 2x 700k before the others?

My team, at least would reather finish quickly, They modify thair play to get more team points (and a sure payoff) so they can return to playing with theirpreferred style.

We do this, even though we have always finished the highest chest. I assume other teams that finish the challenge do the same. No one dislikes quick money.

To be fair the thresholds could depend of the amount of members:

That's an interesting idea. It also requires additional coding that I would MUCH rathersee devoted to the "Wait for BB" option.

It's be easier for the devs to simply increase the thresholds across the board. That's what the challenge has always been: "can you reach the fixed threshold?"

Though programming hasn't ben my MAIN job for 35+ years (I later went  to med school to become a physician, and am now retired),  I've run websites for organizations, and programmed in settings from embedded systems to research applications to phone apps. I'm more an enthusiast than an expert, but every programmer knows this: each new bit of code is a headache and a potential disaster. Testing/QC is never a sure thing, and we HATE deploying unforeseen bugs. Nonprogrammers don't appreciate tha there are ALWAYS bugs

Link to post
Share on other sites
10 hours ago, elon said:

No one dislikes quick money.

The most players i know, have lost more money, than they get back from the chests.
First they played heads up, they got more gold from the chests, as they needed and all was OK.
Then the costs were doubled and now the most lose their money on a blackjack table with 500k stakes.

10 hours ago, elon said:

"Wait for BB"

I think the whole table-hopping problem, could be solved easier, when they would implement a brake of 2 or 5 minutes, before you can join a new table in the same casino. Most players who changes often and quick, wants to get a lucky streak at a table. I tested this more than 10 times with royal poker, at the 5th or 6th table i got pocket pair aces or kings, gone all in and won. And the BB doesn't me care.

And - i am a software developer. I know about the problems.

 

Link to post
Share on other sites

A delay before sitting at a new table is a good idea, from a player perspective.

I'm not sure how it would fit into the code. As a developer, you know that while anything can be programmed in, some solutions slide into the existing program flow elegantly while others generate spaghetti. From the behavior of the "Switch Table/Leave table" option, I'm guessing that there's a good place in the code to insert a delay easily. In the exisiting code, if you leave a table, then sit again within a short time (~15 secs), then try to switchtables, you only get the option to leave, not switch. If you wait, say, 30 seconds or more before re-sitting, you get both options -- so the game already has code to account for time away befoe re-sitting.

A re-sit delay might also reduce play volume marginally, which the developers may not want (from Steam statistics I've seen, play volume is down from 6 and 12 months ago), but in defense of the idea, the reduction wouldn't affect most players much, and even table-jumpers wouldn't be affected much, because they'd learn that jumping tables was no longer a beneficialstrategy -- which is the desired result.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.