Schematization of card games
Status: Planning
Brought to you by:
bago75
Menu
▾
▴
In one of the early threads in this forum Stefano recognised the need to develop a schematization to formalise all card games. Being at the requirements / design stage of such a system I believe that creating an XML schema to represent any card game will be a most effective and important exercise. XML allows high expressibility and is easily editable to reflect changes yet at the same time such a schema will provide us with further insight to develop the actual framework. I believe, as Stefano once suggested, that the final framework will "build up" each card game by reading such a configuration file i.e. the XML schema to create the card game.
I have been brainstorming over the holiday hangovers over such a framework and the following is a VERY raw overview of what I have in mind.
<card_games>
<game>
<name>[game name]</name>
<cards>[card set]</cards> //links to cards document
<layout> //table layout
<grid rows="3" columns="3"/>
<container type="pile|single_card_area|tableau" visibility="0|1">[container name]</container>
</layout>
<player_setup>
<no_of_players>[number of players]</no_of_players>
<partnership>[fixed partnership thoughout game info]<partnership>
<position_info>[information about players positions]</position_info>
<dealer default="[default dealer]" type="rotate|constant"/>
</player_setup>
<play_direction>clockwise|anticlockwise</play_direction>
<hand>
<deal_info>
<direction>clockwise|anticlockwise</direction>
<no_of_cards>0..n</no_of_cards>
</deal_info>
<bid>
[bidding details and rules]
</bid>
<round>
<turn>
<action type="discard" condition="follow suit"/>
<turn>
<win_condition condition="highest trump or card" location="winners pile"/>
</round>
<win_condition>[win conditions for hand]</win_condition>
<hand_score>[score value for hand]</hand_score>
<hand>
<game_score>[game score values]</game_score>
</game>
<card_set>
<name>[card name set]</name>
<card_type>french|italian|spanish|german</card_type>
<suits>
<suit full_name="[suit full name]" shorthand="[shorthand]" rank="[rank value]"/>
e.g. for bridge card set
<suit full_name="clubs" shorthand="C" rank="1"/>
<cards>
<card full_name="[full card name]" pip_value="[pip_value]" shorthand="[shorthand]"/>
e.g. for bridge card set
<card full_name="Ace" shorthand="A" rank="1"/>
</cards>
<wildcards>[wild card (joker) information]</wildcards>
</card_set>
</card_games>
On the whole the schematization outlined above seems good. I would also like to recommend that the game_score section be expanded a bit. For example to include rubber scores and total scores (e.g. you have played 6 games of bridge and team 1 has won 5 of them). In the most general case there should just be a definition of hierarchies of scores with total score at the top and individual games within the games at the bottom of the hierarchy. Possibly even have the hand scores at the bottom of the hierarchy!
I think we should think at the XML schema just after we'll have defined what we need to represent with the XML file.
I think the whole game should be separated in 2 completely detached things: game status composition and game play.
The first one will define how many players are needed, what kind of objects are used (cards, money, tokens, beans :-) ) and specifications for each one. What containers are used by the games (player's hands, tableau, deck) and their visibility.
The second one will define how the Actors (players) can/must work with the game state (object positions, and so on).
A third definition (or an extension of the first one) could define also how to represent the game graphically.
I think we should take in exam this definitions one at a time.
As soon as we'll have defined the first one we'll able to build a generic framework to play games with "player-managed" rules: every player can do everything, as in the real life, we only need to specify the objects in play.
A second step will consist in the creation of a specific actor (the "judge" ) that can check player's actions using a second xml definition (or anything else).
I'm really slow on this planning side, but I've dedicated a lot of time to the process of making a community for java games developer.
I see we are a lot of developers (50 on similar java games, at least 15-20 interested in java card games framework) and I guess that soon we'll be more coordinated!
I'll send an email to everyone wednesday.
At present I am just using XML as a tool to organise my thoughts and as you said it is too early to discuss the actual schema. I agree with you about the 3 subdivisions that you described. I can see the first few tags (<cards>, <layout>, player_setup>) as falling in the first section and the other sections as part of the actual game rules. When you talk about the first section (i.e. with player managed rules) the Apprentice program comes to mind. Apprentice is a tool for playing Magic the gathering and being such a complex game Apprentice allows players to perform all the normal game actions without trying to impose the rules.
What this exercise may help with, could be to identify the different "first principle / basic" actions that are required in the first part of the program, as well as provisions to take into consideration for implementing game rules. Last night I was playing around and I took a small example with Pinocle. Next I intended to try to conceptualise card games involving different mechanics such as scopa, rummy, bridge and canasta. As you can note the structure is yet rather lax and most rule oriented concepts are not yet well defined (e.g. <restriction>, <score> and <game_score>).
<card_games>
<!--Pinochle Rules-->
<game>
<name>Single Deck Partnership Pinochle</name>
<rules_source>Pagat</rules_source>
<cards>pinochle_set</cards>
<layout>
<grid rows="3" col="3"/>
<container type="single_card_area" visibility="1" owner="north" row="1" col="2">north
playarea</container>
<container type="single_card_area" visibility="1" owner="south" row="3" col="2">south play
area</container>
<container type="single_card_area" visibility="1" owner="west" row="2" col="1">west
player</container>
<container type="single_card_area" visibility="1" owner="east" row="2" col="3">east
player</container>
<container type="pile" visibility="0" owner="north" row="1" column="1">north player winning
pile</container>
<container type="pile" visibility="0" owner="east" row="1" column="3">east player winning
pile</container>
<container type="pile" visibility="0" owner="west" row="3" column="1">west player winning
pile</container>
<container type="pile" visibility="0" owner="south" row="3" column="3"> south winning
pile</container>
</layout>
<player_setup>
<no_of_players>4</no_of_players>
<position_info>
<position>north</position>
<position>south</position>
<position>west</position>
<position>east</position>
</position_info>
<partnership>
<partner group="A">north</partner>
<partner group="A">south</partner>
<partner group="B">west</partner>
<partner group="B">east</partner>
</partnership>
<dealer default="random" type="rotate"/>
</player_setup>
<play_direction>clockwise</play_direction>
<meld_information>
<meld name="Class A - Sequence" value="150">
<card shorthand="A" suit="trump"/>
<card shorthand="T" suit="trump"/>
<card shorthand="K" suit="trump"/>
<card shorthand="Q" suit="trump"/>
<card shorthand="J" suit="trump"/>
</meld>
<meld name="Class A - Royal Marriage" value="40">
<card shorthand="K" suit="trump"/>
<card shorthand="Q" suit="trump"/>
</meld>
<meld name="Class A - Common Marriage" value="20">
<!--X in each card means cards must have same suit-->
<card shorthand="K" suit="X"/>
<card shorthand="Q" suit="X"/>
</meld>
<meld name="Class B - Pinochle" value="40">
<card shorthand="Q" suit="S"/>
<card shorthand="J" suit="C"/>
</meld>
<meld name="Class B - Dis" value="10">
<card shorthand="9" suit="trump"/>
</meld>
<meld name="Class C - Four Aces" value="100">
<card shorthand="A" suit="S"/>
<card shorthand="A" suit="C"/>
<card shorthand="A" suit="H"/>
<card shorthand="A" suit="D"/>
</meld>
<meld name="Class C - Four Kings" value="80">
<card shorthand="K" suit="S"/>
<card shorthand="K" suit="C"/>
<card shorthand="K" suit="H"/>
<card shorthand="K" suit="D"/>
</meld>
<meld name="Class C - Four Queens" value="60">
<card shorthand="Q" suit="S"/>
<card shorthand="Q" suit="C"/>
<card shorthand="Q" suit="H"/>
<card shorthand="Q" suit="D"/>
</meld>
<meld name="Class C - Four Jacks" value="40">
<card shorthand="J" suit="S"/>
<card shorthand="J" suit="C"/>
<card shorthand="J" suit="H"/>
<card shorthand="J" suit="D"/>
</meld>
</meld_information>
<hand>
<deal_info>
<direction>clockwise</direction>
<no_of_cards>12</no_of_cards>
</deal_info>
<action type="bid" input="integer" text="number of points to achieve">
<restriction>
<greater_than>250</greater_than>
</restriction>
</action>
<action type="meld"/>
<round>
<turn>
<action type="discard" amount="1" location="tableau">
<restriction>follow suit</restriction>
<restriction>trump if cannot follow</restriction>
<restriction>overtrump if possible</restriction>
</action>
<win_condition condition="highest trump" order_by="rank" location="winners pile"/>
</turn>
</round>
<hand_score>
<score type="card" value="pip value"/>
<score type="trick" value="10" condition="last trick"/>
<score type="meld" value="meld value"/>
</hand_score>
</hand>
<game_score>sum hand score</game_score>
</game>
<!--Pinochle Card Set-->
<card_set>
<name>pinochle_set</name>
<card_type>french</card_type>
<suits>
<suit full_name="spades" shorthand="S"/>
<suit full_name="hearts" shorthand="H"/>
<suit full_name="clubs" shorthand="C"/>
<suit full_name="diamonds" shorthand="D"/>
</suits>
<cards>
<card full_name="Ace" shorthand="A" pip_value="10" rank="1"/>
<card full_name="Ten" shorthand="T" pip_value="10" rank="2"/>
<card full_name="King" shorthand="K" pip_value="10" rank="3"/>
<card full_name="Queen" shorthand="Q" rank="4"/>
<card full_name="Jack" shorthand="J" rank="5"/>
<card full_name="Nine" shorthand="9" rank="6"/>
</cards>
<no_of_decks>2</no_of_decks>
</card_set>
</card_games>
<!-- NOTES:
Currently it is best to take each card game as taking a single number of players so that the layout and futher configuration
can be unambigously defined. For the same game with a different number of players a separate game entry must be entered.
In the future a sort of tree structure could be created in such a way as to derive variants of games from the parent game.
:: sample meld information for a rummy game
:: A section to describe wild card sequences when describing melds should be created to facilitate the description of the
game
<meld_information>
<meld name="4 card sequence">
<card shorthand="A1" suit="X"/>
<card shorthand="A2" suit="X"/>
<card shorthand="A3" suit="X"/>
<card shorthand="A4" suit="X"/>
</meld>
<meld name="3 card run">
<card shorthand="A" suit="X1"/>
<card shorthand="A" suit="X2"/>
<card shorthand="A" suit="X3"/>
</meld>
</meld_information>
END OF NOTES-->
About the Container and Layout definition.
I think we should define the Container sets and their properties in a given tag and the layout in a different tag.
The layout is not an issue for the gameplay and the correct definition of the game rules and mechanics details.
So it would be:
<containers>
<container type="single_card_area" visibility="1" owner="north" name="northplayarea" />
</containers>
<layout type="gridlayout">
<grid rows="3" col="3"/>
<container name="northplayarea" row="1" col="2">north playarea</container>
</layout>
or a similar thing.
Well, just to be sure about. You are mainly talking about trick taking games, do you?
Do you consider only standard decks? Or do you consider the definition of entirely different decks also.
But even a XML classification of all classical trick taking games with classical card decks would be worth the effort IMHO. And this independandly of Ataraxia. It could be a great source for card game research!
When it comes to solitair like games, the layout of cards is of course a substantial part of the game.
We will try to consider every card game with major efforts for turn based games.
Classification and modularisation of non turn based games is really more difficult.
Layout in solitair is not an issua at "rule" side you can play the same solitaire with the same rule and no difference but the layout and the game is the same. I think the layout can be completely separated from the ruling engine. Both the layout and the ruling engine will be built on top of the containers/visibility layer, i think, but they will be separated.
I'll try to create a document from my self-brainstorming-notes from past months about container-visibily layer / layouts / game rule subprojects, but currently I want to define the gameframe-apis before starting with this.
This week I'll post my first purposal draft for the gameframe-apis.
Although the above example was related to a trick-taking game we plan to define and implement any type of card game. Also different decks (e.g. Italian, German) should be supported. One of the main aims is to keep the framework as generic and flexible as possible to be able to specify anything.
I think that a desirable feature of the framework would be to parse the XML specification
and geneate a separate class incorporating the rules of each game - maybe similar to the concept in nebulacards. What do you think about this idea?
At the moment I am trying to figure out the types of constraints required by card games so as to be able to define game rules. For instance most card games require that a player discards card/s from his hand satisfying a particular condition e.g. follow suit or else meld a particular sequence of cards. I will try to incorporate some of my ideas in an XML document example in the near future. Also I am trying to formalise most of the ideas gathered so far from this forum by identifing the various classes in a UML diagram.