|
A Library Addon For Developing Card Games
New: Ported to Android
Main Features:
- Standard card images (bridge/pocker, French card set, German card set) included
- Simple class design: classes CardGame, Deck, Hand, Card
- Powerful class Hand as a card container with strict distinction between logic and layout
- Rich realistic user configurable hand layouts: in a stack, in a row, in a column, in a fan
- Animation for card layouts and card transfers (moving cards from one hand to another)
- Many useful methods for dealing-out, shuffling, sorting and comparing cards, searching for pairs, trips, quads and sequences with same or mixed suit
- Object-based mouse events triggered when visual part of a card is touched
- User configurable toolbar for text, images, buttons and card stackss
- Simplifies the creation of professional card games like bridge, poker, jass by an order of magnitude, but basic enough to be used in an educational environment
- Smooth integration into the JGameGrid and TcpJLib library to develop Internet based multi-user games
- Integrated into Android JDroidLib library with auto zoom features (automatic adaption of card layouts to different screen resolutions)
Design Principles:
The suits and ranks of the game are fully user configurable by declaring enumerations and passing them to the generics enabled Deck constructor. The deck instance stores a JGameGrid actor (the "seed actor") for each suit and rank enumeration value that is used for displaying a card in a game grid window. But because the card image must be scaled and rotated at runtime, the seed actor is never displayed directly, it only serves as store for the card image (and the card back image, called the card cover).
Suits and ranks are ordered. The priority is specified by the the order of the enumeration values given when the enumerations are defined. The deck class also provides a method dealingOut() that returns a user selectable number of card sets taken from the given suits/ranks, either randomly shuffled or ordered. Cards may also have a card value that is dynamically adaptable.
A card (instance of class Card) belongs to one of the suits and one of the ranks defined when a deck is created. Each card contains a link to its seed actor, but the Card class itself is not derived from the Actor class. To display a card in a game grid window, the seed actor's image is transformed at runtime with the required scale and rotation parameters and the current card actor is created with the transformed image. The card actor is then used as standard JGameGrid actor to show (and eventually move) the card image in the game grid window. When the scale and rotation parameters change, the old card actor is removed from the game grid and a new card actor is created and added to the game grid. It is a good idea to make a difference between a card as instance of the Card class that remains fixed through the lifetime of the card and its visual representation in a game grid window using the card actor that varies depending on the current scaling and rotation (like in the Model View Controller paradigm).
Normally a card is part of a set of cards called a hand and all cards of a hand are shown together when draw() is called. The properties of the visual arrangement is defined using 4 layout classes: StackLayout, RowLayout, ColumnLayout and FanLayout. There are also "handless" cards that are either not yet inserted into a hand or removed from a hand. As stated before, the current card actor associated with the card must be dynamically calculated from its seed actor with the proper scaling and rotation values when the hand is displayed. Thus the card actor is only valid when the card is part of a hand and the hand was displayed. (Alternatively the card's attributeActor() method may be used to define its card actor.)
Hands are very useful card containers, not only for the cards in a player's hand, but also for modeling card piles of any kind laying on the gambling table. Even when a hand contains a maximum of one card, putting a single card into a hand is preferable to an individual card because
moving cards from one hand to another is simple using the hand's transfer() method.
A hand can be empty (and displayed as such without harm). A hand may even serve as card store without being displayed during the whole game. It is not rare to create between 10 to 20 hands in a 4-players game application.
A hand contains a array list of its cards, called the card list. This list determines the order the cards are painted in the game grid window (the "paint order"). Cards painted later are shown on top of other cards. Whenever a hand is drawn, the current card actor of every card is removed from the game grid, recalculated from its seed actor and added back to the game grid. This is a somewhat time-consuming operation and hands should only be redrawn when needed.
The Hand class provides many card list transforming operations, like sorting with several sort types, shuffling, shifting, reversing, etc. When the card list is modified, the change is not visible until the hand is redisplayed by calling draw(). To simplify redrawing, all hand modification methods have a boolean parameter that can be set true to perform redrawing automatically.
A card may be transferred from one hand to another using the transfer() method. The transfer can be animated by a sequence of card positions when the card moves from the source to the target hand. The transfer operation takes information from a TargetArea instance that includes the target location, the card orientation and a slide step (determines the speed). Once the target area parameters are set, all further transfer operations use them until they are redefined.
To give you an idea about the power of JCardGame we show a basic implementation of the classic Mau-Mau game. You will play against three other computer simulated players. The aim is to drop all your cards on the playing pile. Your cards must match either the suit or the rank of the topmost visible card on the playing pile. If you cannot drop a card (or you don't want), you must take one from the talon. (In Switzerland and parts of Austria the game is called "Tschau Sepp".)
Execute the program locally using WebStart.
There are other Mau-Mau versions with slightly more complicated rules. In the next version you have a second chance to drop a card after you took one from the talon.
Execute the program locally using WebStart.
The fun is amplified in the following widely played version, where you may play a Jack regardless of the visible card on the playing pile. Then you announce a "trump" suit that the next player must respect as new suit unless he/she has another Jack to play.
Execute the program locally using WebStart.
Execute the same program with only a few visible player cards (debug version)
|
Download Android app for installation on a smartphone or emulator.
Download sources (MauMau.zip).
Create QR code to download Android app to your smartphone.
Install/Start app on a USB connected smartphone or a running emulator.
(This is a WebStart signed by the University of Berne, Switzerland. It installs some helper files in <userhome>.jdroidtools.If you did not install the Android SDK, you may install a slim version of the Android-Emulator in <userhome>.jdroidemul using this link, To start the emulator, execute ExecEmul.jar found in <userhome>.jdroidemul) |
|
|
|
|
MauMau on a Android Smartphone |
There are still other interesting thrill enhancements possible: You may introduce card pips (card values) like 11 for Ace, 4 for King, 3 for Queen, 2 for Jack and 10 for Ten. When the game is over, the total of pips is evaluated for each player and counted as "negative" points. After a certain number of games (or when a player reaches a certain pips limit), the game ranking is established in reverse order of the points. Using CardGame's pips support, the programming is simple. It's is a bit more complicated to find an optimal strategy for the computer players.
We also implemented MauMau as 4-player online game using the TcpJLib library.
Execute MauMau as online game.
(4 instances in the same game room must be started, all may run on the same or different machines.) |
|