Introduction

OK, so who among us hasn't written a card game at least once in our programming careers? However, for most of us, it was written in the days of the command line, and the output looked like this:

Welcome to Blackjack!
You have been dealt the seven of clubs.
You have been dealt the six of hearts.
Hit or Stand (H/S)?

Fortunately, we now have nifty graphical user interfaces and languages such as Java that makes it easy to work with images - such as cards - in programs. Unfortunately, there is a major problem with making this type of assignment: obtaining card images to be used in the program. Scanning cards is a no-no: as the "fine print" provided by The United States Playing Card Company puts it:

COPYRIGHT INFORMATION
BICYCLE®, BEE®, AVIATOR®, HOYLE®, CLUB SPECIAL®, the Rider Back Design, the Diamond
Back Design, the Goddess of Liberty, and other brand names, card back designs and
designs of Aces and Jokers used on this site are registered trademarks of The United
States Playing Card Company in the United States and other countries.

Therefore, in order to assign a graphically-oriented card game, one must have access to a set of cards that are not encumbered by any copyright restrictions.

Our First Resource: The GNU GPL

When I decided to make this assignment a few years ago, a search of the net turned up a web site where a set of card images (a selection of which are shown to the left) were available. These card images were developed for a rather unusual card game written by a person known only as "Oxymoron." All of the card elements are hand designed and antialiased, with all elements symmetrically aligned and centered. Available with the GIF images are Perl and PNM "card element" files - by manipulating these files you can tweak the card images to your liking. Best of all, both the card images and the programs that generate the images were made available by the developer under the GNU General Public Licence! I downloaded a ZIP file containing a copy of the images, and have allowed my students to use them ever since in my introductory Java course (which is offered as a CS2-type course; students come in with two quarters of C++ experience).

Another Problem

Again, let us revisit what we have done in our programming careers - how many among us have written at least two card games? If you said yes, then please answer the following question: how much of your code from your first card game were you able to reuse in your second card game? Many of us would unfortunately have to say, "zero". But what really changed between the two programs? Did the nature of what constitutes a card change? Did the operations that the deck have to perform change? What are the fundamental essences of card games?

Our Second Resource: Object-Oriented Programming and Code Reusability

If we take an object-oriented approach to the problem of writing a card game, the implementation can be greatly simplified through breaking things down into the constituent objects (suit, rank, card, hand, deck) and functionality (deal, shuffle, discard, etc.) Regardless of the game being implemented, the vast majority of the code needs to be written only once. However, there are three major items that that do change from game to game:

1. The evaluation of a hand

2. The composition of a hand (e.g. in blackjack you initially receive two cards whereas in draw poker you receive five)

3. In some cases, which cards are present in the deck

The Assignment

The current version of the assignment broken up into two major parts. The first part consists of a Word document having several sections that leads students systematically through the development process. It first requires all students to develop the Rank, Suit, Card and Deck classes and implement the CardDeckDemo applet that demonstrates that Card objects are successfully being instantiated and can be processed via the Deck. The second section requires all students to develop the Hand superclass and implement both thesubclass DumbGameHandand the DumbGame applet that exercises the methods of the Card and Hand classes. The third section illustrates the benefit of reusable code by having students implement the Beginner's Blackjack applet; this portion of the assignment requires the development of only a new subclass of Hand and a new GUI interface; everything else is based on previously written code, which is rather nifty! The specifications for the Card, Deck, Hand, Rank, and Suit classes are all provided through the use of Javadoc HTML files. Complete source code for the applets is available, as well as stub code for the Card, Deck, Hand, Rank, and Suit classes for you to distribute to your students.

The second part asks students to implement a "legitimate" card game (my definition of legitimate is that the rules of the game can be found in "According to Hoyle" or similar reference) that utilizes a standard deck of playing cards - this includes stripped decks (for Euchre) or multiple decks (for Baccarat).

Resources

• Copies of the assignments in Word and HTML formats.
• Javadocs of the Card, Deck, Hand, Rank, and Suit classes.
• Copies of the card images, available either as a zip or as a tar file.

So What's So Nifty About This?

First there are the obvious factors. It's a game, and games are always fun to implement as the game is a known quantity and, once it's up and running, you can actually do something with the program you just created. It's graphically-oriented, so you can see the cards in your hand, instead of having to read a list of card names. The code is written in Java, so the students in your class can develop the software as an applet, place it on the web, and invite friends and family to surf over and check out their new creation. It uses Swing components, which makes displaying the card images almost trivial - just instantiate a few JLabels and invoke the setIcon() method. The first part of the assignment demonstrates how easy it is to create new programs by reusing old code, which sets the student up for implementing a real card game in the second part of the assignment with most of the work already accomplished. Finally, there are plenty of opportunities for extra credit. However, I believe that there is also something "nifty" from an educational aspect. If I didn't provide the card images, where would they be obtained? It is highly doubtful that a student is artistic enough and has sufficient time to draw a set of cards for use in the program. They could perform a Google search and perhaps find something out on the web; however, the odds are that, if they play by the rules, they'll be empty-handed. Therefore, prior to handing out the assignment and making known to them that you have a set of card images ready for distribution, you sketch out the basics of the program, then innocently ask about how to obtain card images for use with the program. Inevitably, someone will bring up scanning the images off of a set of playing cards or "borrowing" images from other programs (such as Microsoft Solitaire). At this time you can bring up the issue of copyright and licencing, then segue into a discussion about the GNU General Public Licence. In short, this assignment allows you the opportunity to discuss ethical issues regarding the use of software components developed by others.

Contact Information

John K. Estell
Electrical & Computer Engineering and Computer Science Department
Ohio Northern University
Ada, Ohio 45810
j-estell@onu.edu

Last updated 24 February 2004 by John K. Estell