dec says: I saw the posting. I take it the game was over . I am assuming Rob won that game and his opponent is questioning what they could have done . I went with the luck factor a dozen keep. dec

JQT says: Tim Schempp did a marvelous job on Royal Cribbage 3.1 (a.k.a. Cribbage King), but an even older program is "Crib '97" by Craig Hessel, and it requires a Windows XP or prior Op Sys to run these. Hessel's program is one that I would really recommend to beginners or intermediate players, because it SAVES GAMES (even if you quit mid-game, it can recover!), and you can see an easy-to-decipher running tally of your statistics, and all of your games are saved and presented in a very logical manner that is as close to a Portable Game Notation as anything that exists today. Hal was coming very close with his Base64 format, and as far as readability, I still like Hal's translated (xlate) from his Halsware (proprietary fonts) to Courier, which resulted in a pseudo-ASCII format (it still required visual columns to line up to parse correctly, and it used various font colors to help readability). True PGN would be human-readable and scripting-tool-independent, and not depend on color, columnar layout, etc.). I've spent two decades trying to come up with a PGN format for Cribbage Game Files that could also be used for Game Entry (thus, some semblance of sequential order must be imposed and maintained) and that would support a machine-readable format from raw ASCII. Hal's Base64 would have done EVERYTHING except be usable for game entry. My analogy for this game entry process is like that of a Bowling Score, or a Golf Scorecard, or a Baseball Game Box Score, something you can fill out sequentially in real time as the game proceeds, and that captures every score, card, and play. For example, if you want to capture a particular deal, you first denote the score as (53-54*) for example, and now you need 13 variables to denote the card ranks, and 4 variables to append the suits, since 6 cards for each player, and 1 card for the cut. However, if we want to "capture" these during a game, we need to enter them sequentially when we see them (pegging), so Pone might have (3c 3h 5c 5s 6d Tc) as in today's puzzle, but since Pone would only "see" Dealer's cards during the pegging, we need to "fill these in" as they are played during the pegging, and either a third party human, or a program, or either player in the game needs to be able to do this with a LITTLE INTERRUPTION and time delay as possible. Then, each card gets logged during the "play" (pegging) and this can even become a "checksum" to double check the earlier hand entry (everything gets entered twice, so an accidental omission won't cause loss of game). Also, if both players are logging a game, the two scoresheets become an additional checksum to help capture the game (if 3h gets logged as 3d by mistake, it will show up wrong in one place, but correct in three places, so any entered errors can usually thus be self-corrected by human or machine). Same thing with scores, which get logged before and after the deal, giving some quasi-cyclic-redundancy to the process. Sorry about the length and technical jargon, but I hope this offers a glimpse into what maybe could one day become a Cribbage Game Machine and Human Readable File Entry Protocol. 🧁 ☕ 🍉