Power Pinochle Forums

My mind has briefly digressed from my primary project of Pinochle Notation while I was combing the Google Groups Pinochle threads (some of which were 15 - 20 years old) for more enthusiasts to recruit as consultants and PP members.

I noticed that many, many threads dealt exclusively with clarifying Pinochle rules.

Let's be honest.
There are lots of variants.
There are lots of rules documents.
These documents are not always great.
Factors in their poor quality include:

• Lack of structure
  
• Lack of accurate terminology
  
• Lack of clear English (grammar, punctuation, spelling)
  
• Lack of simplicity
  
• Lack of completeness
  
• Inclusion of strategies
  
• Inclusion of opinions
  
• Inclusion of glossary of terms
  
• Inclusion of examples
  

In line with Power Pinochle's mission to educate the world about Pinochle, it seems only logical that we bring some sense of order and dignity to Pinochle rules and how they are documented.

I have spend a little under an hour before bedtime smacking together a page that I shall like to build and develop.

Introducing Power Pinochle's "Rules Documentor" -- http://www.powerpinochle.com/forum/rulesdocumentor.php

This, in time, should serve to assist Game Hosts in constructing their own rules document; whether it be for online or offline games.

The left side is the input -- a list of grouped clauses that may possibly exist in any variant.
The right side is the output -- this text can be easily copy/pasted into a PDF, Word Document, or webpage to inform players.

Simply check or uncheck the appropriate boxes and build a professional grade rules document which features only the simplest, clearest, most concise clauses.

Now...
Please don't rate the program on its current status.  The example rule clauses that I have inserted are not of the quality that I aspire to offer.  There are other features to come, including a way to adjust the "plurality" of the certain key words (depending on if there are teams of players or just individual players).

Step one, would be to mine the internet of all existing rules documents.
Step two, would be to examine their terms and clauses and select the best.
Step three, we (PP members) nominate/elect/construct clauses to be offered in the Rules Documentor.

When structure is clean, all possible cases are covered, and clauses are beautifully written, then the program can be considered a success.

If you would like to help with this long term project, simply add to this thread.
All aspects of this project may be debated and discussed; I am only firm in the idea that this project is valuable.

nice start. question. so for example, rather than include every variation of meld the builder could click the meld and after it's pasted in edit the differences in meld?
Or is it a goal that everything in the text came from a selection?

(03-17-2016, 06:09 PM)rdwrites Wrote: [ -> ]nice start. question. so for example, rather than include every variation of meld the builder could click the meld and after it's pasted in edit the differences in meld?
Or is it a goal that everything in the text came from a selection?

Granted, anyone can copy what is produced, paste the text into something else, and then modify it.
However, my goal is to create consistency in terminology and structure, while accommodating all the clauses that different variants may have.

I want to reign it all in and make sure that no one is saying "Melt" when they mean "Meld" and that the consistent term "Run" is used versus "Book", "Straight", "Sequence", etc.
As a by-product, the Glossary page may receive some refinement, which is another bonus.

Developing the Rules Documentor is an opportunity to reveal holes and fringe cases that some hosts don't know about, and offer clear rules for them.

Additionally, I plan to seek and destroy "bad" rules like the use of CHEATING BIDS like "By Me", "One (versus 51)", and "Paaaaaaaass".  I am sure there are other "bad" allowances and loopholes, so healthy/constructive debate will be required on a case by case basis.

Finally, with sufficient development, the Rules Documentor can double as a place to "park" your rules in a single URL.
I could set up certain checkboxes to be checked (on page load) based on values in the URL's querystring (after the question mark in the web address).
... I am still considering all the purposes and features of this project.

Some good thoughts there, mick.

There are also some clauses that disqualify other clauses.  e.g. "Game is played to 350 points." and "Game is played to 500 points."
In these cases, it will better / more intuitive to use radio buttons instead of checkboxes.
My current code is not sophisticated enough to make subgroups of clauses, but this is easily done when I switch from a hard-coded array of clauses to a database table of clauses.

Structure must come first.  I haven't started to scrutinize existing rules documents, but I need to define the primary groups of clauses.
Primary groups should include the Phases (like Auction, Exchange, Meld, Play), but I see the need for non-phase groups (like Getting Started and Terms of Victory).

Would anyone like to nominate some smart names for Primary Groups?

I would like to word the clauses in a way that makes them flexible with regard to number of players / teams involved in the variant.
When the words "player", "players", "team", "teams", "his/her" must be used, I guess I'll create some searchable pseudo-tag like [player/team].
Then I can offer a control button that will replace the [tag] with the desired word.

...nope, radio buttons are no good because once one of them in the group is selected, the group can never be totally deselected.

Instead, I will keep the checkboxes, but offer an inline dropmenu (html <select> tag) that will offer a finite list of valid values. "100 / 250 / 500 / ..." inside the sentence of the clause.

The Meld tables could be built similarly...
A checkbox on the left to indicate whether a Meld Table should be inserted in the table, then a dropmenu of meld table names.  Upon selection of a meld table name, a meld table would appear below (like the Meld Calculator).  Only the meld table that is selected would be applied to the output area.

It's time to start compiling rules documents to review.

Attached is the document used by Sons In Retirement http://sirtwain.org/Pinochle.html

[attachment=39]

John McLeod of https://www.pagat.com/ offers 4 pages dedicated to Pinochle rules and advice:

https://www.pagat.com/marriage/pinmain.html
https://www.pagat.com/marriage/pindd.html
https://www.pagat.com/marriage/pin3.html
https://www.pagat.com/marriage/pin2hand.html

Christopher Chapman offered a rules page that blends rules with advice.
http://web.archive.org/web/2008072608314.../rules.htm


Brad Wilson offered some rules as well, titled Double Deck Killer Pinochle.
http://web.archive.org/web/2001062922493...ochle.html


Someone who goes by the handle "Mouse" invented something called Glup Pinochle.
https://www.pagat.com/invented/glup_pinochle.html

(03-20-2016, 09:01 AM)mickmackusa Wrote: [ -> ]...nope, radio buttons are no good because once one of them in the group is selected, the group can never be totally deselected.

Radio buttons are perfectly good. You just have to include the "None" radio button.