What kind of "concept" are to be defined?
Status: Planning
Brought to you by:
bago75
Menu
▾
▴
card games are built around some basic concept that change from game to game but are almost present in all the card games.
Actors: Players
the only actors in a game are the players:
a) this should be true... no?
Objects: Deck of Cards
Most games use a specific Deck of Cards:
a) are there games that need more "objects" in order to be played?
- e.g: dices??
GameResult:
At the end of each Game a GameResult exists:
a) is it true?
- i think so...
b) what kind of results exists?
- a player or more that one are the winners
- other games could provide only "loosers" and not winners: again, there could be more that one.
- other game could provide a classific
c) points?
- not all the games are based on "points" and probably points are not always an integer number: can we get sample games?
Goals/End of game
games ends when a goal has been reached:
a) is this always true?
- are there games where the "time" determine the end of game?
- if this is true we could separate the concepts of "goal" and "end of game" because in such a game the goal would be to do points, but the end of game is not reached at a particular score, but after a specific time.
b) what kind of goals exists?
- maximize points
- finish the cards
Yes, this definitely should be divided in 2 subjects: goals and end of game. I'll try to refactor this.
Card containers
a) does all the games have the "Player hand" concept?
- is the hand allways "private"? (only visible to the owner)
b) some game has a common "table/tableau" where cards are not "owned" by the player who played them, but only by the table itself
- for example "scopa", "scala 40"
- "scala 40" and i think rummy games needs the ability to define and identify "group of cards" on the table.
c) most trick based games have different type of "tableau": every player has his own "piece" of table where he put cards he want to play; until the end of the trick the cards are still considered owned by the player and we must be aware of who played each card in game.
- the number of cards contained in each "private" piece of table is defined by the game itself.
d) most games provide the availability of the "undealt cards deck" that is on somewhere on the table
- is always face-down and a single deck?
e) some game needs "won cards" containers for each player or for each partnership.
- is allways true that won cards are only "numerable" and not viewable?
f) other games provides a "graveyard" (a place where discharged cards are sent)
- sometimes this is a facedown pile of cards (example?)
- sometime this is a faceup pile of cards (so that last card can be seen) (example?)
- graveyard could be done so that all cards are faceup and visible: i'm thinking about mah-jong (that I consider a card game played with particular cards): this could be thought as a "faceup, last accessible (one can take the last played card/tile) all visible cards"
g) some game need that a specific card is put face-up on the table (usually under the deck) to indicate the "trump".
h) mah-jong has a particular container that is specific to each player and contains flowers, tris, straight and so on: it is different from "scala 40" because tris and other "played groups" are still owned by the player who played them and they are also used to determine the score of each player. Should we consider this "container" as a particular part of the player hand that has been published to players? I don't think so... it would be better to define a new container for each player: we could also think at it as the tableau of trick taking games: the only difference is that cards are grouped and that is not emptied at each "round".
Game variables
many games are based on "variables":
a) trump: some game need a trump and this is a variable as it is needed in order to "know" the status of the game
b) trick leader
- this only exists in trick based games.
- are there games where you need to know the current role of the player? I referer to attacker/defender games... probably it could be "generalized" with the definition "leader"?
c) dealer: who dealt the cards?
- this could not be present in all the games, but probably in many.
d) players current score: most games needs that player points are recorded for following hands or anything else.
e) hand leader: this only exists in hands based games.
f) in some game the "time" could be an important variable: can we find a card game that do use of "time"?
g) turn of whom?: who is the player that should play now? this does not mean that he is the only one that can play in his turn: this is only the way to know the current "position" of the game.
- can we find a game where "turn" is not defined?
what other variables could exists? I think that specific procedures could need specific variables: we probably will have to define the "variable definition mechanism" and a standard set of variables but we should provide methods to add customised variables.
Ok, i stop here with the game informations. The only thing (net most difficult one, probably) not in this overview should be in the "Game Procedures".
>Card containers
>a) does all the games have the "Player hand" concept?
>- is the hand allways "private"? (only visible to the owner)
Please take into consideration games such as Indian Poker. In that game one card is placed on player's forehead (ie. all the other players see it, but the player himself doesn't).
In a more general level it could be said that there is a visibility consept: each card or card container is visible to 0..n players.
Making it too general will be a disadvantage too.
Cards are a "physical" thing and we know that visibility is done in a way that "physic" agree on.
Visibility could be handled as:
- every player
- only owner
- everyone but owner
- your partnership (games where there are cards viewable from you and your partner)
otherwise a specific visibility object will be created...
Card containers
Some things that are related to card containers
- ordered or unordered container (ie. does the order matter within the container). If it is ordered, the cards can be accessed by their "position" in the container
- visibility: when a card is moved to the container, does it become visible or unvisible. Putting a card into the container can also change the visibility of other cards.
- the name of the container (can vary between games - and is localizable)
Examples:
A hand
---------
- A hand is a container owned by the player and visible to the player
- It is unordered, it does not matter in which order the cards are in the hand
Discard pile in Gin Rummy
------------------------------------
- it is ordered
- only the topmost card is visible
At the higher level of abstraction, the knowledge of each player should be limited to this kind of objects:
- GameAction / GameMove / Nofifications
- a basic set of gamemoves that could be handled with specific actions defined as genericactions with defined parameters, so that the "DiscardACardAction" will be described also as "MoveCardAction(FromContainer,ToContainer) => MoveCardAction(YOURHAND,GRAVEYARD)". In this way a generic interface could be developed fastly and specific interfaces could be developed to resemble a given game more closely
- game will Notify players about what's happening: notification of player Moves , of Container changes, Variable changes: a movement of a card from one container to another should be handled with 1 "MoveCardActionNotify" or with 2 "ContainerChangeNotify" (one with the remove and one with the add)?... the first I think.
- Player
- Names
- Dipositions
- Partnership
- Game
- Turn concept
- set of allowed Actions
- Equipment:
- Cards and SetOfCards and Decks: a client could know of specific decks, a dummy one could only know the concept of Card and communicate with card suits/rank or card brief names (Ah, 3c): look at Anaxor mailing list archives about comparable tokens.
- Chips / Money: at a first stage we could handle chips with variables.
- Containers: chips containers, cards container
Equipments should be visible on the player screen: the dummy client could handle a list of container/variables without layout, a more advanced could define layouts with an XML file or given language. There could be LayoutObjects that know how to arrange containers on the screen.
It seems to me that this is a good point... we should agree on this or change it if needed and then start studying architecture / interfaces.
Is this the complete "basic knowledge" needed to play cards?
How about bidding in games such as Bridge? How should it be handled? It is kind of conversation between the players and it will effect the later parts of the game. Typically no cards are actually played during bidding (there are some games, however, where players make a bid by showing a card from their hand)
Bidding goes under "set of allowed Actions" does not it? There are typically strict rules on what is allowed during the bidding.
Should the game be divided into "stages" such as
- dealing and other procedures before the actual game
- possible bidding stage
- playing the cards
- scoring and other procedures after the game?
Stages depend heavily on the game played. The bidding stage can be simple or quite complicated.
Procedures like bidding, trumping (choice of the trump), auctions (some game need auctions to be done: in the first stage of "3 in 1" the dealer can do an auction to "sell" the "spare hand" (during the dealing the dealer distribute cards between players and one more hand is the "spare hand", as if it were a player).
The simplest client doesn't know about this kind of actions and should handle them with "generic variable management actions" (you ask to set the "Bid" variable, the "Trump" variable, and the server receive the string and can accept/reject it). Little enhanced clients will better interact with this kind of procedures giving you options about the answers.
sorry for the incomprehensible message... here in italy the wine of the new year is ready :-)))))) and I like wine! ;-) ... so.... you know what I mean...
We could think of a specific action called "BridgeBiddingAction" that is defined as a variable management action that let the player to set the "bid" variable ("SetVariableAction" with the constraint of the variable name that is "bid" and the question "Do you bid:")
The basic client doens't know of the "BridgeBiddingAction" and will handle the simplified action asking to "Do your bid:" to the player and the player can write whatever he wants in the text area. The rules will check the reply and will choose either to accept the action or not. If the value "setted" with the action is not valid rules will send an error to the player and will ask to repeat the action ultil a good reply is given.
The advanced client coded for a better bridge support will handle the "BridgeBiddingAction" directly and probably will return errors to the player without talking to the server/rules. It will allow choice of the "Bid" in a graphical way, with predefined values, and so on.
I really don't know at the moment the best way to code this... but I think this would be the best way to manage the game.
Objects:
The chips used for betting in games such as Poker or Mus might also be objects. You might choose to treat these as scores, or you might say that the scoring apparatus - whatever kind is used - is an object. Note that games in which there are a number of pools to be played for can have fairly complex states of the score - example http://www.pagat.com/lhombre/tresillo.html
Results and Goals:
I don't remember exactly what we defined as a game, but there are many card games that have no definite end. During the session, some money is transferred between the players at the end of each hand (sometimes even during the play). When the players agree to finish, the result is simply that some of them have won some money (more or less), some have lost, and some might be exactly even. There may not be a concept of an overall winner - if you win some money you are happy, even if some other player has won more money than you have.
How to manage games with the "undefined ends" ?
How is this done in real life? the first player that want to end the game the game ends?? this could be not the best for player that are loosing...
We could think that every game could be ended in a given moment: in hands/trick based games at the end of every hand the score is updated and players could agree on ending the game at a given score (different from the default).
So every rulesystem (game) should define "moments" where the game can "safely finish" (I think that every game will be "freezable" at any time, but finish a game in the middle of a trick make no sense).
Players should agree on the "duration of the game" or on the "score" to be reached to end the game, or number of tricks , number of hands ...
Eventually, this could be improved later because I think that this doesn't "change" the real gameplay: a game rule must declare "moments" when the game can be interrupted "safely": we then can improve the checks done in this moments later.
Some games have a defined ending procedure. For example, in Hunagrian Tarokk, any player may at any time announce "The Skiz deals and does not deal". You then note which player holds the Skiz in the next hand, continue until it is that player's turn to deal, and then play one more hand dealt by each player, stopping immediately before the Skiz's second turn to deal. Other games end by informal agreement - for example the players might agree to end after three more hands - or one might end at a time agreed before the start of the game. Also, an anding time agreed in advance might be changed if all the players agree.
In an on-line game you also have to cope with the possibility, fortunately rare in real life, that one of the players just goes away, without any agreement, for example because of a lost networ connection.
I do think we should aim to allow a bid to be selected from a defined list of possibilities. At least the player would need some way of knowing what methods of expressing the bid the server would be likely to accept. There are many games (such as Pinochle) in which the bids are simply numbers.
I recommend that you look at Hungarian Tarokk if you would like an example of a game in which the 'bidding stage' is relatively complex. Note that there are actually several stages:
a) Bidding - the possible bids are 'three', 'two', 'one', 'solo' and there are two special calls: 'hold' and 'pass'. Some bids are only legal when ceratin cards are held.
b) Talon exchange: players draw some cards from the talon and discard some. Players are informaed if any trumps have been discarded.
c) Call, declarations, announcements, kontras. The bidder calls a card whose holder will be his partner. Also, all players (in turn) can announce bonuses, declare combinations of cards that they hold, and kontra bids and announcements by players they know to be their opponents. It is possible to take several actions in one turn.
Only after all this does the play begin.