-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
requirement-decomposition is insufficiently strict when longer-tuples are protected #140
Comments
Interesting. I don't think I would normally consider this is a bug? If the player chooses to break their three-of-a-kind, that's up to them. After all, they're allowed to play the [4, 4] to lead a trick, even if it's probably bad strategy to do so. |
Ah okay - I think I should clarify the problem, I didn't explain it fully. Say person A and B are currently playing in the same trick: The game is currently letting person B play [4, 4, 4, {random}], when in reality person B must play the pair of 10s (to match person A's pairs). Person B technically can play the 4s if they want, but they must play the 10s because they have that pair. (Maybe the game is interpreting the hand [4, 4, 4, X]) as 2 pairs already? [(4, 4), 4, X], and [4, (4, 4), X]?) |
Ah, I see. What's happening here is this: 1/ from the perspective of the game, B doesn't hold two pairs. They hold a pair and a triple. So, a play is illegal if the player's hand can meet requirements that the player's play cannot. However, [4,4,4,10,10] can't meet either the [7,7,8,8] or the [7,7],[8,8] requirements, since [4,4,4] can't be forced to break. So, the requirements that the player is actually being validated against for play-legality is [7,7],[8],[8], which doesn't require a pair for the second half. Fixing this will require some thinking about how whether there should be backtracking in the requirement-decomposition logic -- I haven't put in the time for that, because I don't personally play with the protect-triples setting(s). Reproducing this in a test should be easy though! |
Ah I see - that makes a lot of sense. Thanks for the explanation! |
#205 looks like another case where backtracking might be necessary |
This issue is when 7 people playing with 4 decks of cards. "Longer tuple (triple) is protected from shorter (pair)" setting is on.
When a tractor is getting played ([7, 7, 8, 8]), if the next person to go has a [4, 4, 4] and a [10, 10], he should be forced to play the [10, 10] pair, but the game allows him to just play the [4, 4, 4].
The text was updated successfully, but these errors were encountered: