CO504 (T204) OO/C++ Assignment - A Card Game

Introduction

• Stage 1 - The Requirement
• Questions and Answers for Stage 1
• Teaching Points from Stage 1
• Stage 2 - The Implementation
• Questions and Answers for Stage 2
• Form to Request a Clarification
• An Informal Competition

	    // The Player base class.

    // A Player object is entirely passive. It only acts in response to
    // requests or information received from the manager.

    // newRound is provided for convenience.
    // It is not strictly necessary, as it would be possible
    // to keep track of how many cards had been played in the current
    // round and newGame informs the Player of the number of participants.

    // A Player is asked to play a single card per round. The request is made
    // through a call to either leadRound or playCard. A call to leadRound
    // indicates that this player is the first to play in that round and,
    // therefore, chooses the suit for the round.

class Player{
  public:
    // On construction, a default name is given. Players
    // may choose their own names, however.
    Player(const char *);

    // Be notified of a new game, and how many players in it.
    virtual void newGame(unsigned);

    // Be notified of a new round.
    virtual void newRound(void);

    // Receive a card as part of the deal of this game.
    virtual void receiveCard(const Card *);

    // Be notified of a spare card as part of the deal of this game.
    virtual void notifyOfSpare(const Card *);

	// Play a card in the current round.
    // Play the first card of a round.
    virtual const Card *leadRound(void);
    // Play a card in this round following suit.
    virtual const Card *playCard(Suit);

    // Be notified of a played card in this round.
    virtual void notifyOfPlayedCard(const Card *);

    // Tell anyone who asks what my name is.
    virtual const char *whoAreYou(void) const;
};

Deadlines

Handing in the Assignment

You should hand in to Reception just an ls -l listing of your submission directory as evidence of the submission. You should write clearly on that listing whether your program works or not. By this I mean that

• I will be able to compile it against my test rig as found in /usr/work/t204/Cards on falcon.
• It will play a legal game.

I will only attempt to test run those programs that are claimed to work. Don't hand in any source listings to Reception. Don't include the runnable program in your handin directory.

Cover sheets for the assignment are in the top row of pigeon holes near Computing Reception.

Request for Clarification

A. You come and talk to me about what the best way of proceeding is. It might be useful to have made an attempt at one or more of ex[123] in /usr/work/t204/djb on falcon or to have tried some early exercises from either Perry&Levin or Deitel&Deitel, and to bring those efforts with you.

Q. I have a DOS C++ Compiler and want to work on the C++ Cards assignment over the hols. Do I need anything else other than the files in the Cards directory on falcon?

A. The source should compile without difficulty on a DOS C++ compiler. I have done this with the DJGPP C++ compiler.

Zip files for the DJGPP compiler may be found on falcon in /usr/work/t204/djb/Djgpp or locally via ftp. The full package is at this Simtel mirror.

Q. Would Visual Basic be a good Platform for implementing the design with a "Solitaire" type interface in mind?

A. The Player is not responsible for displaying the current state of the game. The Card class has a virtual print method that provides a way of displaying a card's suit and value. Currently this is implemented as a simple print to a stream argument, but one could envisage that the Card class, or a class derived from it, might choose to display itself in a graphical form, such as you suggest. There should be enough dialogue in the existing `main.cc' to follow what is going on in a game and the contents of the Player should simply be an implementation of the card playing rules. The only output that you might want a player to perform is some form of diagnostics on how each card is chosen. This is not required for the assignment, however.

Having said that, and as a further illustration of the separation of game display from the player implementation; I have created, for my own interest, a class HumanPlayer, derived from Player. This requests a human to select the card to be played in each round, which involves displaying the state of a player's hand as each card is requested. Since the manager knows nothing about the type of player in each `seat', initiating the display must be the responsibility of the HumanPlayer class, but the characteristics of how the display is achieved are still hidden from the implementation of HumanPlayer.

Q. Could you clarify exactly what we are meant to be coding and what each part of the player header file is meant to do. The spec is VERY vague.

A. The purpose of the assignment is to program an implementation of the Player class that is capable of taking a legal part in a game. The interface between the game's manager and each player is defined in terms of the member functions of the player class. The interactions at the start of a new game enable a Player object to know what cards it holds (receiveCard), how many other players there are in the game, and which cards are spare (i.e. held by no-one - notifyOfSpare). In each round, a player is informed of whether it must lead the round (leadRound), whether it must follow a particular suit, and which other cards have been played in the current round. Most interactions take place between players and manager by passing around pointers to Card objects. A Player does not need to know how such an object is implemented but can enquire of it its suit and value.

If you take a look through PlayAGame in main.cc you should be able to see how these interactions take place. For each game a number of Player objects is created to play against one another. In implementing the Player class your sole task is ensure that the implementation plays a legal game, i.e. a Player must not play a card it does not hold, it must follow suit if possible, and so on. Quality of play is not being assessed. This makes the task reasonably straightforward, because the functionality is fully defined and you implement it by defining a function body corresponding to each member function of the class, and adding some protected or private data and/or functions to retain the game state. Indeed, some of the informational functionality can be entirely ignored, with the Player still playing a legal game. You clearly need a means to retain the cards in the Player's hand so that it only plays cards it holds but knowing which cards are spare only matters if you want to play to win. Ensuring that it plays a card of the correct suit is possible because a Card object is able to reveal its suit, and you keep a record of which cards are still in the hand.

Once you have added any additional private and protected information to the interface in Player.h and the function bodies in Player.cc you should be able to compile these with the rest of the given code, that provides the infrastructure, and have a working program.

Q. Isn't the comment before receiveCard incorrect?

A. Yes, it has now been corrected in the interface above, and in `Player.h' on falcon. It previously read, `Receive a card as part of the deal of this round,' rather than `game.' The comment before notifyOfSpare has also been amended accordingly. Sorry for any confusion this caused.

Q. So all we hand in is a listing of the directory and a note saying whether or not the program compiles and plays a legal game?

A. Yes.

Q. I probably should know by now how I can compile my C++ program but can you please tell me how I can compile it once I finish programming?

A. You can compile a single .cc file with the command

g++ -c -Wall -O Player.cc

make

Q. Isn't the manager in main.cc unfair in the order it asks players to play cards?

A. Yes. This was an error on my part and I have now changed main.cc to a fairer version. The original version is old_main.cc, should you wish to compare the two. None of this affects the functionality of the Player class, it just makes it a little more consistent with one's understanding of how the game should work.

Stage 1 - The Requirement

Produce a high-level Object-Oriented design for a program to be written in an O-O language to allow the following game of cards to be played amongst 2 or more players.

A game consists of a number of rounds between P players. At the start of each round, every player receives C (= 52/P) cards. The remaining 52%P cards are turned face up so that everyone can see them. A single game consists of C rounds in which each player plays a single card in turn. The player of the first card in the first round of a game is decided randomly. Thereafter, the winner of each round plays the first card of the next round of that game, if there is one. After the first card of a round has been played, the remaining players play one card each in turn. These players must follow the suit of the first player if possible. A round is won by the player who plays the highest card of the lead suit. A game is won by the player or players who have won the most rounds in that game.

Guidance on Design

The following considerations are not part of the assignment, but you might like to bear them in mind when thinking through the design.

• How easy would it be to add the notion of a trump suit to the design?
• Could one or more of the players be a human player or a cooperation between the program and a human advisor?
• Could the manager take part in the game?

You should hand-in an identification of the Classes that are needed, their Responsibilities (public interfaces), and their Collaborators (the other classes with which they interact). You may do this using any existing techniques you might have come across in your background reading - such as Booch diagrams or CRC cards - or your own informal method. Low level implementation detail is not required and you should certainly not submit any C++ for this stage.

Deadlines

Useful URLs

• The Booch Method of Object-Oriented Analysis & Design
• An introduction to object oriented development.

A. Some students feel that if they ask for help on an assignment they will risk losing marks. Others don't like asking questions, in case they look silly. This method addresses both of those concerns. The anonymiser doesn't identify the sender of a question, so I will respond by posting to this page.

Q. How does the first player of the round decide what card they should play? Is it the lowest of any suit?

A. This is up to you. Quality of play is not going to be assessed, only adherance to the rules of the game. I have it in mind to run an informal competition to see whose implementation plays the best against mine, but that is not part of the assessment.

Q. [After the first card has been played] do the other players have to play a card with value as close to but higher if possible, and the same suit? What happens if a player does not have a card of the right suit?

A. Players must follow suit, if they can, but whether higher or lower is a tactical issue that will not be assessed. If they have no card of the same suit, they may play any other card. Which they play is also a tactical issue, and so will not be assessed, but is affected by whether there is a trump suit or not.

Q. How many rounds are in a game?

A. The specification defines this as `A single game consists of C rounds'.

Q. How can there be any remaining cards if the number of cards in a pack i.e. 52, is divided by the number of players. Is this for when the number of players doesn't divide evenly into 52?

A. If there are 4 players (P == 4), then each receives 13 cards (C == 52/4) with none left over. If there are 5 players, then each receives 10, with 2 (52%5) left over.

Q. Would I be correct in assuming that this game is `Trumps' with-out a trump suit (at the moment)?

A. I am not actually sure what this is a version of! I suspect that there are a lot of games with similar rules. It is safest to assume that it is not the same as any game that you already know. In this way you won't be led into making assumptions over issues that have not been properly specified.

Q. Do you use `Round' to refer to both a `Trick' (where every player lays 1 card) and a set of `Tricks' in which all players cards are laid?

I have tried to use `Round' as the equivalent of `Trick' only. `Game' is the equivalent of a complete set of C Tricks.

Q. How do we hand in the work for stage 1?

A. Cover sheets for the assignment to be handed in on 3rd Dec are in the top row of pigeon holes to the left of Reception in Computing. Please note that the deadline is 7pm rather than the usual 8pm.

Q. Are there any no marks at all for putting in any intelligence? Can it effectively just play random cards of the correct suit and still get full marks?

A. That's right. You will not be assessed on the quality of play, just its legality.

Teaching Points from Stage 1

• Class names should be singular or collective nouns. It was quite common for `Cards' and `Players' to be used as class names. A class represents a description of a typical object that belongs to that class. If a plural name is used then it can introduce a confusing mixture of singular and plural facets into the description. For instance, classes named Cards often included attributes for suit and value, but also behaviour usually associated with a pack of cards. It is much better to describe the class Card and, if a group of cards has distinctive attributes and behaviour, use a collective noun, such as Hand or Deck, for another class. In this way it is clear that the description of `Deck' does not need to go down to the level of an individual card, because that is covered elsewhere.

• Each responsibility should have its own list of collaborators. A typical description of a Manager class listed just about every other class as a collaborator in a single block. Unless these are noted against individual responsibilities, it is difficult to check for completeness of the design. When a collaborator is listed it often gives you useful information about what to describe for that collaborating class. For instance, a Manager class might have a method called, `Deal a card.' Possible collaborators are Deck and Player. This suggests that Deck should have a responsibility that allows a card to be dealt from it, and Player should have one that allows it to receive a card.

• Attributes of a class should be private. A common error was to simply describe a Card as having a suit and a value. If we adopt the principle that attributes (fields, data) are private then it is necessary to provide responsibilities that give access to these. Where the data should be read-only (as in the case of a Card) these are called `accessors.' Where the data should be writeable these are called `mutators.'

• Some designs created a Winner class. I am not convinced that this was necessary. Many missed that more than one player may win a game, in the event of a tie. Where Winner was defined, it was not clear whether there should be distinct classes for the winners of the rounds and the winners of the game? Since each Player in a game is a potential winner, the distinction between a Winner and a Player is not clear to me. However, I did not impose a penalty for including such a class. It is often the case that you define spurious classes and only discover later that you can get rid of them, as the design is refined.

• Class descriptions often failed to take the identification of `facts' about classes far enough. Facts should be separated into attributes, behaviours, and responsibilities. A few examples,
  • `Every player receives C cards.' This fact can be broken down into an attribute - the player must have somewhere to hold the cards - and a responsibility - the player must be able to receive cards (possibly singly or as a group).
  • `Players must follow the suit of the first player if possible.' There is an implicit responsibility to be able to play a card, but there is also an explicit behaviour that is part of the governing rules of the game. This is a behaviour of the Player, and it may also be a responsibility of some other class to check its compliance.
  • `A round is won by the player who plays the highest card of the lead suit.' This is a fact about rounds rather than players, of course. If there is a Round class then its responsibility is to determine the winner of the round. However, you could view it as a behaviour for a particular implementation of Player that tries to win the game.

• I quite liked the alternative approach to undealt and played cards that was adopted in some designs. Instead of explicitly informing players of these cards they were simply made available to any player that wished to know about them. This reduces the basic Player class to a few basic responsibilities and leaves the other functionality to derived classes that wish to know about the other cards.

• Both Deck (Pack) and Hand classes were quite common. In addition, some designs included something like a Trick class, to represent the cards played within a single round. These are all used to hold collections of cards. There would seem to be a good case for a CardCollection base class, therefore, from which all of these could be derived. CardCollection would be able to hold an unsorted set of an arbitrary number of cards, and cards could be added, removed and inspected. A Hand class might consist of 4 suit-related CardCollections. A Deck class could add a shuffle method. A Trick class might be able to report the winning card, for instance.

On the whole, the problem seemed to lend itself quite well to a variety of solutions and most designs managed to produce a basic set of classes comprising Card, Player, Manager and Game. One of the weakest areas was showing how these classes interacted and those designs would probably have benefitted from `acting-out' a game in order to see how the master-slave relationships would work in practice.

An Informal Competition

My intention is to award a small prize of a book token to the best implementation of a Player, or class derived from Player. I propose the following form of the competition, but this is open to discussion and variation between me and those who intend to enter.

• You may enter up to a maximum of five different implementations.
• There will be an initial qualification stage in which your implementation must win or tie at least 40 2-player games out of 100 against my implementation.
• Those that pass the qualification stage will be randomly drawn in pairs to compete in 100 3-player games, where the third player is my implementation. These 100 games will be two sets of 50 games, in order to allow for the two possible `seat' arrangements (X-Y-Z and X-Z-Y). Victory will go to the one of the pair scoring the most wins. In the event of a tie, 100 4-player games will be played (without change of ordering) with two of my implementation taking the other two seats. In the event of a tie again, this pattern will repeated with 100 5-player games, and so on, until a winner emerges.
• In subsequent knockout rounds, I am not sure whether it would be better to have straight 2-player games (in which my implementation drops out) or to follow a similar pattern of 3-player games.

In order to make this work, it will be necessary to make some changes to your source code to prevent name clashes. I will give details of this nearer the time.

Deadline for registering your entry into the competition is 14th February 1997.

Q. How about a couple of bottles of wine for first prize instead of a poxy book token :-)

A. I wouldn't want to give the (entirely false) impression that students are more interested in drinking than studying, now, would I?!

I have made an executable of my version available for you to compare with your own. This is called `cards' in /usr/work/t204/djb/Cards on falcon. I have updated the `README' file with details.