Thursday, May 29, 2014

Java Card Game Engine at a Glance

Not long ago, I decided to write a quick card game in Java. I wanted to write War because about a year prior, I had helped a friend of mine start learning Python for the first time and we wrote a War game together. Then recently, I started helping him again as he began to take on Java for a new job he scored. The incentive was here once again to write War, and would make for a great example of some basic Java usage/syntax. 

My project can be found on GitHub and is free to use: https://github.com/thedouglenz/JavaCardGameSystem/

I wanted to utilize as many object oriented programming tactics as I could, so I started designing and writing my models. The objects I wanted to capture and use from real-world card games were, of course, the idea of a card, a deck, a hand, a player, etc. I even ventured to create a class for a table, which encapsulated among other things, the number of sides of the game table for a given game. I added functionality to the deck such as dealHand and shuffleDeck. I gave every Player a Hand. Every Player the ability to play a card or a collection of cards on the table, the deck the ability to track and report its size, ...

In fact, it continued like that until I was realizing that by this time I was creating more than just the card game War. I had the whole domain model built for potentially lots and lots of card games. I could already sense the basic functionality was present for Crazy Eights, Rummy, Hearts, etc.

The aspiring user would simply have to take my layer of models and write most any game he or she desires by simply building an interface that controls game logic and some kind of GUI. Consequently, I wanted to try this for myself, which brought me back to War. I simply built a WarGUI class that utilized Java's Swing libraries to make the most basic GUI known to man, built a class, WarController, to control the game logic and a class, WarGame, that initialized everything the way I needed it. War obviously has a pretty standard and logically easy game loop. Nonetheless, the models served the purpose very well. 

Then my aforementioned friend asked if my system could be used to make poker. While I was tempted to say that it could, I knew that poker was a little bit different than the others. And a non-expert user would still have a lot of work to do if they wanted to use my system to invent a poker game. So I took to writing PokerHandEvaluator5Card. This is one of those classes justified by the general responsibility assignment software pattern (GRASP) known as "pure fabrication". Clearly, in real life there is no such thing as a "poker hand evaluator". Human beings are bright enough to do that work within minutes (or seconds) and dismiss it as trivial that they were able to do it. However, for the purposes of programming a dumb computer, a thing like evaluating a poker hand is a chore. Thusly, my implementation creates a new instance of my evaluator for each hand that needs it and exists thereafter only to report what poker hands are in it.

As you browse through my code and decide if and how you want to use it for your Java card game, feel free to make any additions/modifications. The state of the project at the time of this writing is "in progress" (in quotes because while I say its in progress, I haven't actually touched it in a while as I'm busy with other endeavors now, namely an Android application). Enjoy!

No comments:

Post a Comment