Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

Card engine in Java

How to create reusable classes for card games

By Kent Sandvik, JavaWorld.com, 08/10/96

  • Print
  • Feedback
.
This all started when we noticed that there were very few card game applications or applets written in Java. First we thought about writing a couple of games, and started by figuring out the core code and classes needed for creating card games. The process continues, but now there is a fairly stable framework to use for creating various card game solutions. Here we describe how this framework was designed, how it operates, and the tools and tricks that were used to make it useful and stable.

Design phase

With object-oriented design, it is extremely important to know the problem inside and out. Otherwise, it's possible to spend a lot of time designing classes and solutions that aren't needed or will not work according to specific needs. In the case of card games, one approach is to visualize what is going on when one, two, or more persons play cards.

A card deck usually contains 52 cards in four different suits (diamonds, hearts, clubs, spades), with values ranging from deuce to the king, plus the ace. Immediately a problem arises: depending on the rules of the game, the aces can be either the lowest card value, the highest, or both.

Furthermore, there are players who take cards from the deck into a hand and manage the hand based on rules. You can either show the cards to everyone by placing them on the table or look at them privately. Depending on the particular stage of the game, you might have N number of cards in your hand.

Analyzing the stages this way reveals various patterns. We now use a case-driven approach, as described above, that is documented in Ivar Jacobson's Object Oriented Software Engineering. In this book, one of the basic ideas is to model classes based on real-life situations. That makes it much easier to understand how relations operate, what depends on what, and how the abstractions operate.

We have classes such as CardDeck, Hand, Card, and RuleSet. A CardDeck will contain 52 Card objects at the start, and CardDeck will have fewer Card objects as these are drawn into a Hand object. Hand objects talk with a RuleSet object that has all the rules concerning the game. Think of a RuleSet as the game handbook.

Vector classes

In this case, we needed a flexible data structure that handles dynamic entry changes, which eliminated the Array data structure. We also wanted an easy way to add an insert element and avoid a lot of coding if possible. There are different solutions available, such as various forms of binary trees. However, the java.util package has a Vector class that implements an array of objects that grows and shrinks in size as necessary, which was exactly what we needed. (The Vector member functions are not fully explained in the current documentation; this article will further explain how the Vector class can be used for similar dynamic object list instances.) The drawback with Vector classes is additional memory use, due to a lot of memory copying done behind the scenes. (For this reason, Arrays are always better; they are static in size, so the compiler could figure out ways to optimize the code). Also, with larger sets of objects, we might have penalties concerning lookup times, but the biggest Vector we could think of was 52 entries. That's still reasonable for this case, and long lookup times were not a concern.

  • Print
  • Feedback

Resources