Deal Generator User Guide
Deal Recipe Maker
Experienced users might use this guide mainly as a refresher on the card specification codes used in the Deal Recipe Maker, so I provide those right up front. New or questioning users can of course read the whole guide.
Deal Recipe Maker Card Specification Codes
VOID - key this in a suit, with nothing else, to ensure it gets no cards.
2 through 9, or T, J, Q, K, A - specific cards.
G - A, K, or Q.
F - face cards (excludes Ten, which is faceless, but just so you know).
H - honors (includes Ten).
S - spot cards (excludes Ten). Ten is spotty to some, but for that we have “Z”.
Z - spot cards, including Ten. Z for zero HCP. Get it?
X - any card.
(n-n)x - randomizer. “(n-n)” means 2 integers enclosed in parentheses and separated by a dash. When you use this construct, replace the “x” following the parentheses with any of placeholders G, F, H, S, Z, or X. This construct lets you specify a random number of whichever placeholder immediately follows the digits in parentheses, with the random number confined to the range specified by the two integers. This lets you build single recipes that can get variable results, supporting phrases such as “6+ spades in North” with (6-13)X in North’s spades, or “responder has more than 4 spades and no more than 4 hearts” with (5-13)X in responder’s spades and (0-4)X in their hearts. Ignore it until you discover the need for it and then—rejoice.
[x][z] - suit or. Expression selector. If you include one or more expressions inside square brackets in a single suit, the generator will randomly select one of the enclosed expressions and will discard the others. This “or” operates only within a single suit at a time, so you could have square-bracketed expressions in every suit, and the generator will randomly choose one to keep for each suit with such expressions.
{x}{z} - hand or. Expression selector. If you include one or more expressions inside curly braces in a hand, the generator will randomly select the enclosed expression(s) in one suit and will discard the enclosed expressions from other suits. This “or” operates only within a single hand, but it works across all suits in that hand. The generator will randomly choose to keep the curly-braced expression for only one suit in each hand.
B - key this anywhere in a suit, but preferably at the end, to indicate you only want cards specified by other placeholders in this suit. Use this to ensure you get the exact lengths of suits you want in a recipe that does not specify the locations of all 52 cards.
blank (nothing) - if the content or length of a suit is not limited by “VOID” or “B” then any blank space in the suit can receive a random card in a recipe that does not specify the locations of all 52 cards.
The Deal Recipe Maker of the Bridge, Out Ahead bridge deal generator lets you specify which cards, or which types of cards, you want in each hand. You can specify anywhere from none of the cards to every single one, depending on your needs. You specify cards using the codes shown at the top of this guide. Rather than rehash those codes exhaustively, I will point out things that might not be obvious about this panel.
Generate Deal button: when you press this button, it does not alter your recipe in any way. Instead, it uses your recipe (but not the shaper!) to cook up a deal which it then shows over in the Generated Deal panel. If the deal suits your needs, you’re done. If not, press the button again or else change your recipe until you get what you are looking for.
Red Button: this button generates a deal that conforms to your recipe and to the point ranges and hand shapes in the shaper panel. Use often, but use carefully.
The Handviewer button on this panel is only useful if you have keyed in only specific cards. The Handviewer, courtesy of BridgeBase, only displays actual cards and will choke on our other placeholder codes. This is still useful, because unlike my Generated Deal panel, Handviewer will display partial deals and partial hands, say if you want to see a nice display of just one or two hands in a deal for some kind of analysis where you don’t want to see every card in the deck.
The Report button opens up a dialog box with the recipe in printable form—basically like the Generated Deal form. In addition to printing recipes, you can use the recipe Report function to selectively print hands in a deal. This is very useful for making instructional deals where you might want to show only North and South, or if you were making handouts for four students and you want each to see only their own hand. Assuming the deal you want to configure in some way is in the Generated Deal panel, copy it to the Recipe panel by clicking the “To Recipe” button of the Generated Deal panel. The deal will be copied to the Recipe panel. Each suit in the recipe (except for VOID suits) will end with “B” because that is how a suit of an exact length is marked. Now click the Spade image for each hand that you want to exclude from the printed deal; this will clear out that entire hand. For the remaining hands, click the Club image to remove the “B” placeholders/length limiters for that hand. Note that both of these methods are just for convenience; you could always manually blank out anything you don’t want to appear in the printed version. If the word “VOID” is in any of your remaining hands, just blank it out. Double-clicking the entry field for any suit will blank out just that suit in that hand. Now when you click “Report,” your printout will show only what you left in the recipe panel. If you need to show it several different ways, just click “To Recipe” to restore the whole recipe and chop it down for your next printout.
Copy Link button: when you press this button, a link to the deal generator webpage is generated, and it includes whatever card codes are in the Recipe Maker. That link is saved in your clipboard, so if you intend to do anything with it you need to do it before you cut or copy anything else into the clipboard. One thing you might do with such a link is include it in an email or document so you can click it later to get back to whatever recipe you were working on.
Save Recipe button (not on the recipe panel—look to the file save area at the lower left of the web page): saves the current recipe into a file with a .bcoarecipe extension. The program does not prefill the file name, so you have to key one in. You can put your saved recipe files somewhere for future reuse. You can load .bcoarecipe files back into the bridge deal generator using the “Browse…” button and file selector near the top right side of the web page.
When you access the bridge deal generator using the saved recipe link, or when you reload it from the .bcoarecipe file, the page will reload the recipe into the Recipe Maker.
Loading a LIN or PBN file into the program will also populate not just the Generated Deal panel, but it will also load it into the Recipe Maker as a very exact recipe, with every card specified and with “B” at the end of each suit to restrict its length.
Auction input area (not on the recipe panel, but described here because if you view a recipe in the Handviewer, it will also show your auction if you entered one): this input area is not edited, so you can key anything in it. It is intended to let you include a nicely-formatted auction if you view your recipe (with actual cards only) in the Handviewer. It’s free-form, but Handviewer has certain expectations, so do this if you want an auction: key a series of bids or calls, separated by commas. The first bid or call is assumed to be by the dealer, then LHO, then partner, and so on. Don’t skip any seats, even when passing. Calls are P, X, or XX. Bids are a digit followed by a suit, or by N or NT. It is good form to end any auction with “P,P,P”.
Swap and Rotate buttons: Here we use some hieroglyphics in lieu of words.
These buttons provide our most-requested feature, by which I mean I was studying deals with friends yesterday and I realized that I didn’t have a quick way to swap hands around in a deal. Yes, we can rotate dealer and vulnerability quite easily when generating multiple deals, and that is a very effective way of letting you study a fixed deal or a related set of deals with all dealer/vulnerability combinations. But what if you have a deal that’s just perfect for some purpose, but you want to keep dealer/vulnerability as it is but swap the cards around?
In my case, I had a set of instructional deals for 2-level weak opening bids. North was the dealer, and the hand with the 6-card suit and low HCP, in every single deal. I thought we were just going to study the things on paper, but someone said, “I wish we could play these. Can we deal them out with cards?” I said, “Hell, no!!!” Not really, but I thought it, because I find the process of manually dealing out specific hands very tedious and error-prone. Also, we only had three people. You can play with cards that way, but it is not ideal. I said “no” to dealing out cards, but “yes” to playing the deals on BBO. We all had computers or tablets, so why not?
I used the deal links embedded in my worksheets to regenerate the deals on my website, save them off to a LIN file, and load them into BBO. I then set up a teaching table with my uploaded deals as the deal source. This took all of 2-3 minutes, which included a coffee run to the kitchen.
That was great, but only North was able to practice the 2-level weak opening bid. Sure, I could have rearranged the seat assignments in BBO from one deal to another to put different players in North, but let me tell you something: these were elderly people who already have a tough time if their seat in BBO doesn’t match their physical location at my dining/card table. It’s bad enough if the person sitting in the southerly seat is assigned North, but they adapt after a few minutes of bewilderment and mild protest. But no way am I going to reassign seats midstream; that would cause a riot.
Much of my generator program development has been driven by overcoming obstacles and pain points in the generation of deals. I thought I had solved all potential issues weeks ago, but that was before I started using my own program to make instructional materials for friends who are absolute beginners who are learning at ages 78 and 85. I never imagined that physical vs virtual seat location would ever be an issue. I get it, though: for folks not born and raised with computers, the mind does not instantly adapt and map to whatever view of the world the computer is showing you.
But even wtihout that problem, the usefulness of being able to move hands around in a deal is fairly obvious.
The N-S button swaps North and South.
The W-E button swaps West and East.
The swurvy-curvy arrow button moves each hand one seat clockwise—North to East, East to South, South to West, and West to North.
The Spade-Heart button swaps spades and hearts within each hand.
The Diamond-Club button swaps diamonds and clubs within each hand.
Swapping or rotating hands or suits in a recipe only changes the recipe panel; if you want a deal with that new configuration, you need to press the Generate Deal button of the recipe panel.
The rest of this guide is about how cards are dealt based on the recipe. If you are getting good results you may not care how cards are allocated, but if your recipes are going wrong, read this and ponder whether you might have conflicts built into your recipes.
Just one example: Suppose you have keyed “F” for face card four times in one or several spade suits. Fine. Now you think it would be nice to have two honors for that same suit in a hand that has no “F” codes. Well, sorry, but “F” codes are fulfilled first before considering any other code. In our deal, the only thing left for an “H” code in that suit would be the Ten, which lands in the suit on one of your “H” codes. But there’s no face card or honor left for your second “H”. I did that very thing and you can play with it here. Generate from that recipe over and over, and watch South get the Ten of spades and no other spade honor every time since they were allocated elsewhere.
When trying to build recipes based on suit quality, management of honors is an issue—one you can navigate successfully if you just pay attention to how many of each code you have used.
There can be similar interactions involving all the codes. Like a good cook, you must pay attention to the ingredients in your deal recipe. When I’m building a recipe, I generate often to see how it’s working as I go along. No need to wait for nasty surprises at the end.
Recipes are not edited for correctness or reasonableness. You can key in utter garbage, give everybody impossible numbers of honors, etc. The program will calmly deal only cards that it has in the deck—it will not conjure extra honors out of nowhere if you happen to specify too many.
The program will try to deal every card to somebody, eventually.
When you key in or load up a recipe and press Generate Deal, the program takes a well-shuffled deck and then commences going around the horn starting with West, fulfilling your card specifications one type at a time. This is quite different from dealing cards to each seat round-robin starting with the dealer, for the program will pass through the deck several times.
On the first pass, it goes through and notes every suit for which “VOID” is specified, and marks them in its little notebook. They shall have no cards at all, if possible.
Then it goes through and deals cards into placeholders in the order shown at the top of this post. Notice that those codes are in order from most specific and restrictive to least specific. So first it honors all requests for specific cards. Then it starts over with whatever is left in the deck and honors “F” codes, dealing out face cards. Then it starts over and fulfills “H” codes. And so on through “X” for any card.
After fulfilling those codes, it takes another tour of the recipe and notes any hands with a “B” code indicating that they only want cards that fulfill a placeholder code. The program marks those hands in its little notebook; unlike the VOID suits they may have received some cards in earlier rounds, but now they, too, shall receive no more. We hope.
Now for the grand finale: we have honored all placeholder codes, and we know who doesn’t want any more (or any in the first place) cards. But we may have some left in the deck! What to do?
In the final go-round, the program deals any leftover cards into hands that have fewer than 13 cards, honoring VOID and B codes from its little notebook so as not to rudely slap unwanted cards into a hand.
All done, right? Well, no: if the recipe was too specific and especially too restrictive, there could still be undealt cards. The program now disregards the VOID and B codes and deals the remaining cards into any available slot. There can be invalid recipes, but in practice this program should not produce invalid deals.
Happy dealing!