Player action knowledge
Status: Planning
Brought to you by:
bago75
Menu
▾
▴
What kind of actions a generic player is expected to know?
We can think about these "Movement" actions:
- Play <1/N> Card/s
- Drop <1/N> Card/s (Discharge)
- Draw/Drow <1/N> Card/s
- Pass <1/N> Card/s to a <Given> Player
- Make <1/N> Groups each one with <1/N> Cards from the cards in your hand and Play them grouped:
- this could be differently viewed as a "Play N Cards" and then "manage cards on the tableau"?
If we think that there are game containers that are:
- Deck
- X Player Hands
- X Player Tableau positions
- Graveyard
Then all the "Movement" actions could be expressed as a movement from a container to another container of a set of cards or of a given number of cards.
Set of cards could be "complex" so that groups can exists inside the Set.
A player then can move a "number of cards" (if the container is not faceup) or a "complex set of cards" (if the container is faceup) from a container to another container: CARDS MUST BE ALWAYS SOMEWHERE so "MOVEMENT" is the CORE of card playing (passing, playing, dropping are only aliases for common operations)
There are other Actions that a player is supposed to know how to be performed:
- TurnFinish (some game provide you the ability to do one or more actions or nothing at all... you can TurnFinish when you've finished: we MUST find a better name for this stupid action)
- TrumpChoice, Bidding and similar: these actions could be grouped in a generic "Variable changing" action: a "SetVariable" action that take the variable name as argument could be sufficient.
- Some game, like "Tressette" allow you to "say" keywords during the game... a ChatAction should be used.
- Beccaccino allow you to "chiamarti fuori" / "call you out" (to declare that you think you won the game, you reached the goal)... this is a "special" Action and we should find other action in different games that are not in the StandardActions.
- At the moment it seems that the non standard procedures I've in mind are all called without parameters, e.g: you don't need to specify anything when you "call out", or when you say "striscio", "busso", "volo".... The we could define a standard overloadable procedure that simply allow you to DO something the rules allow you to do (without parameters!): however each Procedure that allow the player to do a specific Action should care to listen for these actions and handle them or they will rejected!
Most of this semplification could only be "valid" for the "cardgame framework protocol specification" and are not suitable for a graphical client that will need to show actions and ask the player to do actions in a more specific way.
We could think, for example at the "Trump choice procedure": this procedure could ask a player to perform a "Trump Choice Action" that in turn is defined as "Variable Set Action [Question: "Choose the trump"] [Variable: HAND.TRUMP]": if the client know the specific "Trump Choice Action" that it will ask the player to do his choice in a good graphical way, otherwise it will handle the "Action Request" in a more generic way: for example by asking in a window "Choose the trump" and waiting for a text input that match a suit name.
There is an action in "Scopa" that is not simply a movement of a card between containers.
Go to http://www.pagat.com/fishing/scopone.html and look at the "The Play" paragraph: the "capture" action is what I'm thinking to.
This action cannot be simplified as a sequence of movements: the first step is that you play a card from your hands to the tableau, and this could be done with the generic movement action, but then, if there are cards in the tableau that could be captured you must capture them and move your card and the captured cards to your "woncards".
The problem is that a played card, once it has been moved to the tableau, has no more "owner" and we don't know who played a card and what is the card played.
We could split the tableau: the real tableau and a particular container that contain the just "played" card:
1) as soon as the player plays /(moves) one card to this container the rules check if there are "capturable" cards in the tableau
2) if there are no capturable cards, rule will move automatically the card to the real tableau, otherwise will ask the player to choose from the tableau the cards he wants to move (from the tableau, to the container where he played the capturing card?)
3) rules will check that all the movements are allowed and then will move the temp-container cards to the woncards of the player.
About the 2nd step: the player "CHOOSE" cards from the tableau because it is a movement where he cannot choose the destination container, so he doesn't move, he only need to choose. (most of the actions will be handled with simple choice and not with the real complete moment action)
To test your structure of movements, I recommend you to look at Durak - see http://www.pagat.com/beating/durak.html - and check whether all the actions of that game can be described using your scheme.
For fishing games, if you want to look at a general case, it would be better to consider Casino or Zwickern rather than Scopa, because in those games you have the extra possibility that cards on the table might be grouped into 'builds' which can only be captured as a whole; you also have the possibility of adding a card to a build, perhaps in more than one way (4 + 4 can be a build of 8 or a double build of 4).
I'm not sure i've understood the durak rules. It seems to me that we can think that the durak tablau is composed by 6 containers where each container is an "ordered" container with 2 positions (attack card, defence cards): the attackers are allowed to put a single card in each of them and the defender is allowed to put a card only if the container already contains an attacking card. The basic actions are always the moves between players hands and a given container (for the defender) and from the hand to anyone empty container for the attacker (the attackers only had to choose the card, not the destination as it doesn't matter).
The second "particular" action used in durak is the cooperative attack: A player can "chat" with other players and can "permit/deny" their join to the attack.
I don't see other "specific" actions that a "player-client" should be able to handle: all the remaining game procedures are procedures fully managed by the server. is this true?
if I understood a build could be a "pile of faced-up card" with an "assigned value" and an "assigned owner".
Ownership could be defined with "build" position: we could think of a generic tableau and a specific tableau for each player (i think this positioning should be done in real game to recognize who own the build, no?). and "value"??? how do players remember build values?? I understand that the cards contained in a given pile doesn't allow you to determine the current value because you don't know what kind of operation has been done on the pile when each card has been added, right? so we must add a "property" to each build that let us remember the current "value". This is similar to the use of jokers in rummy like games (you must choose the card "substituted" by the joker and the choice is "remembered" by the players, without a given "sign") and in Zwicker you also had to choose the value for kings, queens, jacks and aces.
For games already considered we need the ability to assign "values" to a card (or a pile of cards) and the UserInterface will show this value on the card. We also need a way to "dress" a card with another (cloak the card, I don't know which term to use) as for jokers in "scala 40" or similar games. The ability to "flag" a card: "captured" in previous example, "tapped" in magic the gathering.
Can you find other games where players must "memorize" informations that are not just "stored" in card positions or in the score?
The second specific action is the "capturing": you can play a single card and then you can choose one or more group of cards to be captured... let's think how a GUI should let us to do this:
- you play the card in a given specific container
- you choose the value of the card if it is an ace, king, queen, jack
- you can select one or more cards from the tableau until you equal the score of your card (selection could be showed as a yellow border around cards). When you reach the same value of your card it is equal to "choose a group of cards" from the tableau and the server will mark these cards with a "captured flag"
- you can then select more groups of cards and they will be "flagged" as soon as you reach the value of your card
- where you are ready you can "finish" your turn and you win all the "capture flagged" cards.
Is this correct? do you think that this is playable in this way? we can also think so:
- you play the card in a given specific container
- you choose the value of the card if it is an ace, king, queen, jack
- you choose then all of the cards you know you can capture (without grouping them in valid groups) and the server will try to validate you choice creating the groups for you and giving you an error if there is no way to group cards you choose.
Is this better?
I agree with your analysis of Durak. I just wanted you to make sure that your container concept could be applied to a game whose mechanism is fundamentally different from Rummy or Scopa.
In Zwickern, Casino and similar games, in my experience the players just remember the capture value and ownership of each pile, but for thew purpose of a computer implementation it is very desirable to assign value and owner properties to the containers of the piles, so that the legality of moves can be checked. I think there would be no harm in making these visible - in fact it would be an advantage - otherwise it might be unclear to the players why certain moves were illegal.
I prefer your first idea of the process for making a capture in Zwickern - where you select a number of captuarble groups of cards and then confirm the capture when you are ready.
As to memorising information not contained in the position: trivially you must remember whose turn it is to play a card. Also you must remember who was the dealer of the hand, what the final bid was (in a game with bidding), and any additional contracts that may have been undertaken by the same or a different player in addition to the main bid (I am thinking of things like the Pagat Ultimo announcement in Tarock). In some games, such as Skat, you must remember which players originally held certain cards in order to be able to score.