The source code of the problem exposition (but not the solutions) is included in the JGameGrid distribution.

Exercise: Developing a Multiplayer Cardgame

Old Maid / Schwarzer Peter / Vieux Garçon

Game History [Ref. Wikipedia]

The game old maid is a Victorian card game for two to eight players probably deriving from an ancient gambling game in which the loser pays for the drinks. It is known in Germany as Schwarzer Peter, in Sweden as Svarte Petter and in Finland as Musta Pekka (all meaning "black Peter") and in France as le pouilleux ("the lousy/louse-ridden one") or vieux garçon ("old boy"). The game spawns an element of bluffing, commonly used in poker

Game Rules [Ref. Wikipedia]

The dealer deals all of the cards to the players. Some players may have more cards than others; this is acceptable. Players look at their cards and discard any pairs they have face up.

Beginning with the dealer, each player takes turns offering his hand face-down to the person on his left. That person selects a card and adds it to his or her hand. This player then sees if the selected card makes a pair with their original cards. If so, the pair is discarded face up as well. The player who just took a card then offers his or her hand to the person to their left and so on. A player is allowed to shuffle his hand before offering it to the player on his left. In some variants, all players discard after the dealer has drawn.

The object of the game is to continue to take cards, discarding pairs, until all players except one have no cards. That one player will be left with the lone unmatchable card; they are "stuck with the old maid (your chosen card)" and lose.

Game Design

The class design we propose is simple and straightforward. Other solutions are welcome. The application class SchwarzPeter asks for important game options (number of players, game room name, player name) and creates an instance of the Player class. We use the embedded server pattern, explained in the TcpJLib Tutorial Lesson 5 (see), where each player tries to start a game server, but only the first server survives. Then the player creates an instance of the class CardTable that handles the visual part of the game. The game server manages the players entering and exiting the game room and receives the turn information from the player that makes the draw. It distributes this information to the other (waiting) players and gives the turn to the next player. The command tags are defined in the interface Command.

Class diagram:

Developing Process (in cycles)

As in almost all software projects, the development of the application is cyclic and more and more features are added in each cycle until the final goal is reached. This kind of work satisfies the students particularly because in every cycle she/he produces a running application that shows the result of the previous work.

Cycle 1: Enter game room, initialize game table, deal-out cards
->to cycle 1

Cycle 2: Register a CardListener to transfer cards, find and transfer pairs
->to cycle 2

Cycle 3: Move partner's cards
->to cycle 3

Cycle 4: Manage player's turn
->to cycle 4

Cycle 5: Remove player who dropped out
->to cycle 5

Cycle 6: Restrict player, announce loser and terminate game
->to cycle 6

Cycle 7 (optional): Add player names, blinking for the current player
->to cycle 7

The result you will obtain: