Hi bridge pals.
It has certainly been all Computation Corner and User Guide here lately, and no actual bridge content at all. Of course, I’m not a bridge pundit and will only start playing live games at my local club in two weeks, so I hope you excuse me for my recent focus on the look and functionality of the deal generator.
This is one of those posts that may only interest my future self (this is both my bridge and my bridge generator blog, after all), and other amateur developers who might get a kick out of my stumbling-in-the-dark methods.
In my last User Guide update, I mentioned that one more major reworking of the user interface was coming. That new version is now live online. It is what we in the computer biz call a “breaking change” because, while most of it works the same as before, I removed a feature that, for all I know, was quite popular. It will take me a few weeks to write the user guide for the final version, but I thought I would tell you about the removal of the thing called a “Deal Type Selector” which until very recently was called “Custom Deals”.
Do not despair: the old version of the program is still out there. Go to my main bridge web page to find links to both versions. Also, I didn’t just yank that particular rug from under your feet without providing another way to do something similar and, in my view, a lot better. More on that further on in this post.
Here’s the revised interface:
It is still rather NASA Mission Control-room level jammed with stuff, but I think I brought order to the chaos. And I, for one, like the complexity of Mission Control.
The Random Deal button, Load File button, and the date/time of deal generation are no longer crowded in a sad little ghetto of a box above the Generated Deal panel. The Random Deal button now has a proper home atop that panel. The date/time display always and only relates to when that Generated Deal area was populated with a deal, so it, too, sits proudly up yonder (but not in a sad little box—it is more of a free-range label, outstanding in its fieldset [that’s HTML humor]).
The Load File button moved across town to the side where all the other methods of deal generation (except Random Deal) live. So now it is very (84%?) consistent: most knob-twiddling and button-pushing on the right side, with a clear look at the resulting deal on the left side. Hopefully this will make it easier to keep track of what you are doing with the thing.
Now there’s just one (1), not two (2) Auction fields. I mean, come on, whether it’s for your generated deal or your deal recipe, we can just move our little cursor over to the one, quite sufficient, auction space.
There’s now only one file name field, with the whole gaggle of “Save” buttons under it. The program attaches the correct file extension depending on which Save button you press, by the way—you only have to provide a meaningful file name.
Now for the change that is much more than cosmetic: no more built-in Custom Deals. The original Custom Deals menu was a whopping big radio group with dozens and dozens of options.
Remember that? Ah, good times. I especially like that my HTML skills were such that I provided two “go back” buttons, one at the top and one at the bottom, to deal with the fact that when viewed on a small screen such as a phone or tablet, you could only see part of the page. I’m still not an expert web designer, but holy cow, now I know that that was a symptom of jamming way too much onto a screen.
That was so 2023, wasn’t it?
Yeah, like even up until December of 2023. Yikes! And I thought that was a program with a future!
Ah, but the massive riches it offered—surely that’s a feature worth keeping??
Well, no. The massive billboard of options and the garish colors mask an enormous problem: the logic behind all those deal types. I slowly, painfully implemented every single one of those options in some fairly complex code. Unfortunately, that was so 2021, back when I was in a class using a book written by the teacher. That was a very good, award-winning book, so it was a reasonable starting point for a lad who just wanted a way to generate bridge deals suitable for practice play on BBO.
But as my bridge education continued, and especially as I walked through the Frank Stewart Library at the Birmingham (AL) Duplicate Bridge Club, I awoke to the reality of the multitude of systems and conventions and point range preferences out there. Uh oh. I was going to need a bigger Custom Deals page, and more “go back” buttons if I was going to implement every possible system.
But of course no one could possibly code every possible system. Oh, at first I thought that if I took all my hard-coded logic and figured out how to parameterize it so that I and other people could twiddle knobs and levers to build and save every system in the word, then I would have a great general-purpose generator.
Not a bad idea, and parameter-driven is a good solution for many things. But it only took a year or so of reading and pondering for me to realize that bridge is just too complex and there is too much nuance, too many edge cases, too many exceptions to rules, too many gray areas with no rules, and the biggie: mixing and matching of systems and situational substitution of one for another.
And then consider: I’m just trying to deal cards here.
I’ll have you know that to implement just the many (but simplistic) Custom Deals on that big page, my program had to engage in looking at every hand in a deal, figuring out how the bidding would proceed, and building the deal accordingly. Or, rather, it had to look through mountains of randomly-generated deals, putting each one through as much of a virtual mini-auction as was necessary to predict the opening bid and perhaps one round of bidding. That’s when I really learned how complex bridge is, yo.
I was, in effect, trying to write a super-genius bridge player, while knowing next to nothing about bridge.
Yes, I know that many smart people have written full-featured bridge-playing robots, and there is much ongoing work in that area. But I don’t aspire to be one of those people. I’m starting too late and, besides, again—I’m just dealing cards!
And yet…deals that are conducive to a particular auction and a particular line of play, whether for amusement or instruction, were the reasons I wrote this program. If I just stopped at the point where I had that big but cruddy set of Custom Deals based on a beginning bridge book, I would have something but not, in my view, something good that a serious player or instructor would want to use. If only there was some way I could add the missing bridge smarts, the nuance, the situational awareness, the melding of systems to suit a purpose.
If only I could add the unique knowledge of every single one of my users, and somehow make it run in my program.
If only I could borrow the brains of people like…you.
At that point, which was only a couple of weeks ago, I resolved to remove almost all bridge knowledge from my program, and to instead go all in on dealing the cards. But I would make it possible for a user to encode their bridge knowledge by using my program.
As a result, I tossed the Customized Deal page altogether (and the Deal Type Selector panel into which it had morphed in recent weeks). No more encoding of bridge rules in program logic. Users can encode their own bridge knowledge by constructing deal recipes, testing them as they develop them until the recipes suit their interpretation of whatever rule or scenario they are working on. Then they can save that recipe in a file, hopefully with a meaningful name or in a folder organized on some basis—say, deals for a particular system or for a class lesson. They can feed those deals into a dealing machine, or load them into bridge-playing software, or even include diagrams in written material. And they can share those deals, either in the form of files or web links, so that they and others can pop back into my program.
In short, I’m giving you a toolbox with just the basic tools and telling you: “Go forth and multiply your bridge knowledge with purpose-built deals.”
To help this effort and to soften the blow of losing the Customized Deal panel, I am providing two new things.
The first is already implemented: the Deal Shaper panel you can see on the new version of the program. I decided that while bridge is too big to parameterize, I could give you a starting point for your recipes by letting you configure deals based on shape (balanced, unbalanced, or randomly-assigned), and user-defined (and programmatically-validated, hallelujah!) high-card point ranges.
I sense you thinking, “Hey, shape and point ranges—doesn’t that get into bridge logic?” Well, it might if I went nuts and built in something I called 1NT and made it have a balanced hand and 15-17 points (as I did with the old program).
But I’m not doing that. In fact, I’m not calling any deal anything. I’m making no claim that any deal from my program is suited to any particular purpose because of the aforementioned infinite complexity of the game.
I’m letting you name your recipes, and I’m letting you determine their suitability for your purpose.
Suppose, for instance, that you want a deal with which to study or teach 1NT openers.
You can start out in the Recipe Maker, or you can go to the new Deal Shaper panel and make yourself a Deal Shaper with whatever combination of shape and points you want. Generate a deal from it. Is it suitable as the basis for a recipe for your 1NT instruction deal? No? Hit “Generate” again, and again, and again, until you see one you like. Now bring that deal over into the Recipe Maker. There, you can replace some or all of the cards with placeholders to specify types of card—face card, high card, spot card, any card, no cards, etc.). The rich set of placeholders and the ability to control suit length in the Recipe Maker are, incidentally, what make this program more than just a laborious DIY deal-builder. Heck, BBO has one of those built in.
When building your 1NT-specific deal recipe, if you want to focus on one or two hands in the deal, say North and South, just blank out the other hands and let them get randomly-dealt cards. You might have specified HCP for West and East back in the Deal Shaper, but once you get it into the Recipe Maker you can make any change that suits you.
Once you have a recipe that is reliably generating the kind of deal that suits your needs, save it to a recipe file. Put it somewhere where you can pull it out and use it over and over.
Need a variation on that deal to study or play out a slightly different scenario? Great—you don’t need a hard-coded Custom Deal from me—just bring in that same recipe again and change it to suit your other scenario. Then save that one with a different file name. Now you have two 1NT demonstration deal recipes and you know how they came to be.
By the way—notice that while you can specify dealer and vulnerability for a deal, or have them rotate around the table when you generate multiples deals at once, my program no longer attempts to assign a named type of hand to a “dealer” or “overcaller” or “responder” or “advancer”. I don’t put those words in quotes to deride them or because they don’t exist in the real world or in your mind—but they no longer exist in my card-dealing program. What exists, as you can see in the Shaper and the Recipe Maker and in the Generated Deal display, are North, East, South, and West. You must define things in terms of those seats. It’s up to you to figure out, if it matters, where you want the meaningful cards to land, say if you want a particular seat to open the bidding.
Yes, I kicked the crutch of automatic assignment of the “relevant” customized hand to an opening bidder. Think that was bad of me? Well, consider who was the opening bidder—the guy with the big hand, if that’s what you defined in the old program. It was always—always—the dealer. Now, how realistic is it to generate deals where the program struggles mightily to make the person in the 1st seat always throw down an opening bid? Are there no passes? Are there no 4th seat openers? Not many in that old program. Now you do still define who the dealer is, but with the shaper and recipe maker you also define exactly who gets what in the deal.
So the Deal Shaper is the first thing I have already given you to make up for the loss of Customized Deals.
The other thing I plan to do is to reimplement as many of my old hard-coded Customized Deals as possible using the methods I described above. Since my program can save recipes both as files and as web links, I will construct a web page with an organized set of links to my recipes for those deals.
But my page of my deals will just be a proof-of-concept for this process. Don’t wait for me to hand you saved files and web pages full of links to recipe, even though I will eventually do that.
Start developing your own!
Happy dealing!