Dealer's Choice

[ctm]

Implement Dealer's Choice

Dealers Choice has been played at various ARGEs over the years, and it's also present in WSOP 2023 events #5 and #10. Of the various WSOPS enhancements, this is probably the most likely one for me to implement. It's still lower priority than many other things.

[ctm]

Much of the code for this is already available in my Paradise Road Pick'Em implementation. However, there are enough differences that it may be challenging for me to get this done and tested in time for use on June 3rd. As such, I'm going to take a multi step approach:

• [x] new game is picked every hand by someone
• [x] new game is picked every hand by a rotating new-game-chooser button
• [x] structure can allow new game to persist for an orbit six hands

[ctm]

Thinking about this a little more, I think the thing to do is to make the choice selection be an entire "hand" for Dealer's Choice, unlike Paradise Road Pick'em and Wonky Donkey. IOW, there would be no blinds or antes until the next hand.

So logically, at the beginning of a hand, a predicate is called to determine if it's time to choose a new game. If so, that's done and then the hand is over.

The tricky thing is that the game is also going to determine which of the various values for blinds and/or antes and/or bring-ins and that info is cooked into the mix that GameKeeper knows about.

The simplest way to proceed, I believe would be for the structure to be a 22 game mix, the first being Dealer's Choice, and then the one game for each of the games that can be chosen. Then, we have to have something other than Deal::Choose so the "choice" can be an index into the mix (and so we can have a hacky hardcoded table of choices in web/src/table.rs, like we do for Paradise Pick'em).

The drawback to doing it as described above is that it requires that mix to correspond to the choices provided in web/src/table.rs. That should be OK when there's only one Dealer's Choice configuration (i.e., the one WSOP uses), but will require a refactor when we allow players to create their own mixes and their own dealer's choice selections.

I had forgotten just how gross certain aspects of my Paradise Road Pick'em implementation were.

[ctm]

Dan convinced me to make this lower priority than late registration, so I'm going ahead and slotting Paradise Road Pick'em in, since I don't think I'll be able to get this done and tested in time, since I'll be finishing up late registration first.

[ctm]

Currently, Table has a choice_info field which is an Option<ChoiceInfo>, which is set to None after each choice is made, but we're not yet tracking how many hands or orbits to hold on to the current choice. I think the logical thing to do is to add all the info that is needed to track the number of hands remaining into the ChoiceInfo struct and then only set choice_info to None when an actual game transition switches us off dealer's choice.

I don't actually see a need to support a structure that contains a mix of dealer's choice and one or more other games, nor do I think we need to support the ability to alter the number of hands or orbits via Option, but doing it this way would make it easier to do both of those things later and wouldn't hurt us in any way that I can think of.

Eventually, it probably makes sense to have whatever struct we need to keep track of the number of hands for dealer's choice to be back-patched into GameKeeper so that it can be used to know when to switch between games in mixes. Currently, mixes only switch by number of hands, but it makes sense to have the ability to do it by orbits.

When I get to this point, I'd like to define a trait that has the semantics I want so that I can not worry about the actual representation.

[ctm]

Done, but exceedingly lightly tested. Deployed.