Progress & Digression

The following is an overview of what I have been working on, where I started, where I am and the way I got here.

Note: Below I refer to a card game, which I know as Palace. There are, however, quite a few names for the game. The best link that I've found refers to it as 'Shithead.' Sorry about the profanity, but it is a good description of the game.

My initial goal was to implement Munchkin. This digressed into the near complete implementation of Fluxx. Testing Fluxx lead to the desire for a graphical interface, which in turn lead to work on a card game called Palace. A good way into Palace, I decided that I'd like to look at using Java annotations to add semantic data about undoing in-game actions--a problem that I had in the back of my mind when I was working on the initial Munchkin mock up.

Towards Munchkin, I had made a mock up, which ran through the basic turn / phase structure of the game. It allowed for the use of basic items, one shots and monsters with varying bad stuff. Trading and help were not implemented. There was a concurrent effort to work on some to the more subtle details of the game in a test driven environment. I also made a hybrid design pattern, which I referred to as a Strategy Decorator. This pattern allowed the behavior of a game object to have several chained modifications applied at run-time, but how enforce a particular order of operations for these modifications remains a bit fuzzy.

Given the fuzziness, which was somewhat generalized, I decided that it would be prudent to get some perspective by working on a card game that was a bit more simple than Munchkin. I decided on Fluxx. This went along fairly smoothly and employed some of the tools developed during Munchkin efforts. The turn structure was a list of "rules" that were followed by each player. Testing for the game was about the same as was used in the Munchkin mock up: random act choosing players. I would run the game hundreds or thousands of times in a loop to collect data about the running time and the types of win conditions that ended the various games. A strange glitch came up about once ever four thousand-or-so games, which crashed the program. I didn't figure out how it happened. So I added a text interface, but it was so boring to play that I felt the need to make a graphical interface.

So, I moved on to Palace. Palace, as it stands, is playable and enforces the rules for the game. It is purely graphical and looks fine. The play feels comfortable, but I'm the only person to have tested it. There is no computer player, it's only two player and the hands are open. I left off of Palace while looking into adding a variety of potential features: network play, more players, some animation and / or refactoring the code to adhere more closely to my goals for Munchkin. Palace was put on hold to pursue an idea that I had for recording and undoing method.

I was familiar with Java reflection and knew that you could get a proxy class that passed method calls from a wrapped object to the proxy as method objects. This is provided in the java.reflection library. I had, further, read about the, then new, annotations that got added in Java 1.5, which allowed for supplemental class data to be retained at runtime. It seems that these could easily be used together to add brief semantic tags to indicate the necessary method to call to undo the tagged method. So, I wrote a couple of test programs to try out my ideas. I wrote a tic-tac-toe game, which uses the recorded method calls to implement a simple min-max computer player. I also wrote a sudoku solver, which uses the same methods to follow a nishio solving technique (similar to depth-first search).

The source for the undoable actions and the sample applications can be found here.

Right now, I am finishing up graphical interfaces for the tic-tac-toe and sudoku programs. I wonder whether to digress further--I'd like to see if the undoable commands would hold up in real-time in an Asteroids clone--, or backtrack to Palace, or to wrap-around back to Munchkin.