Adam's Minesweeper
Goal
In this program I attempted to make use of the state pattern on a larger scale than is ever done in cs15, the point being that the state pattern is a concise way of modelling this program. I made extensive use of commenets both to describe methods and to describe the inner workings of methods. I took snap shots of the code at three points in creating this program (the code for which is available from these links):
Disclaimer
the dates below represent discrete points in time and that they do not imply that I worked on this program for the whole time between time points, that's just when I either started or stopped working (or when I had a rare moment of inspiration)

Starting thoughts

I've been thinking about this program for a while: it's design some implementation details etc.

The Piece class represents the individual squares on the Board class. The Board class keeps track of all the Pieces in a two dimensional array.

I've decided to implement the state patten to change the visual appearance of the individual pieces and their functionality. Each peice will have a reference to a state which controls how it looks and what happens when the Piece is clicked on.

I'm going to start writing the Piece class since all it really has to do is provide an interface for the states to access and modify it.

Now the states need to be made, it appears that there will be six different concrete state classes which represent the six potential states for the Pieces to be in:

some of the functionality of the bombs and normal peices can be factored out so I'll have two more abstract state classes: one for bombs and one for normal peices

Sat Feb 28 16:34:49 EST 1998
Working now, it looks like it will be useful to have a method which allows me to show what a peice is (bomb or number) without having the usual side effects of things like ending the game or such. I think I'll have a the abstract PieceState class have a method "Uncover()" which transitions the current state into the state where the user can tell what the thing looks like.

Sat Feb 28 16:51:20 EST 1998
When the Pieces start off, they are covered. All the States made in the instantiation of the board are Covered and they can't know about the Piece that they belong to until they are assigned to on. Other states are different in that the Piece that they will belong to is known about at instantation so the target Piece can be passed into the constructor

Sat Feb 28 17:10:54 EST 1998
There are a number of constants which will be used thoughout the program. A nice way to make a lot of classes have access to those constants is to define them in an interface which anything that needs them will implement. This is a really sly way of letting lots of things use the same constants

Sat Feb 28 22:22:33 EST 1998
Brown 4 LSU 2 - go Bruno
There are a few states left to do, namely those which have some alternate graphical representation, but that part of the game is relatively trivial now that I have the general framework in place. Before I write those classes, I'm going to add the GameOver() method to the Board class which will let the game end with two possible outcomes which will be indicated by a boolean value. true for a winner false for a loser. This is a rather primative method, but it will work very nicely in this situation. Also, there will need to be a method in the Board class which decrements a counter which indicates how many Number Pieces are left. This is needed becuase the board is the only class that really is in a position to keep track of that.

Sun Mar 1 02:44:05 EST 1998
I've decided to use private helper methods to separate the graphical components of the state which have a grphical component asocciated with them. These methods are private because they need not be called by any other class since they are just helper methods. This delegates some of the work out of the constructor.

Sun Mar 1 03:21:00 EST 1998
All that's left to be done is to create the graphical representations of the various states, which just a matter of playing with GP shapes, and to make a MineSweeper class which will tie the whole program together. I also haven't addressed the flagging of Pieces concepts, but I think I have it figgured out: I'll make a new State which is the flagged state, when it React()s it will return the target Piece to it's original state and when it is Uncover()ed it will return the Piece to its original state and call Uncover() on it again. There will be a check box somewhere that allows the user to either uncover or to flag a Piece depending on the state of the check box. That will all be in a holder pattern which all the states (or most of them) will need to know about, but that shouldn't be too much trouble. I think that I have a few hours left, so I'm going to sleep now.

Sun Mar 1 14:00:15 EST 1998
The program is done in its first incarnation, but now I'm getting a new Runtime errors due mostly to little problems.
My first error is a GP.Exceptions.OutOfBoundsAccess: Attempt to access element 11 in a GP.Collections.Sequence with actual size of 11

clearly not a big issue, I'm just using the Sequence slightly incorrectly, it's a two second fix (off by one error).

Sun Mar 1 14:04:36 EST 1998
things aren't showing up properly because I haven't dealt with colors at all yet, I'll add them now.

Sun Mar 1 14:11:30 EST 1998
The program is still not fully functional, but I'm at the point where I can begin to test it. First I'm going to stick some System.out.println()s around to see if methods are being called. Specifically, I'm putting one in the GameOver method to see if that's doing it's thing.

Sun Mar 1 14:28:47 EST 1998
another off by one error in checking for bombs surrounding the target Piece, I was using a less than instead of a less than or equal to which mean that only these Pieces were looked at:

X X O where T is the target and X means that the Piece
X T O was being looked at. This problem should now be
O O O fixed

Sun Mar 1 15:01:47 EST 1998
There were a couple more off by one errors and a few other minr errors, but for the most part the game seems to be done. The graphics are very minimal right now and you can't flag Pieces, but these two features are just a matter of time: they are not very hard to implements now that the design is well implemented and stable.
I also put in a textual representation of the Board which is printed out when the board is created (it is inverted, but it's good enough for debugging purposes) this is a good idea because it allows the programmer to see what the internal state of the board is and be able to test the game more effectively

Sun Mar 1 16:39:11 EST 1998
I've made the flag toggle button and it seems that the MineSweeper class will make it and then pass it to the Board class which will make the PieceStateFactory with it which will pass it on to all the state's it makes. That seems like the easiest way to let the covered states know about the toggle button.

Sun Mar 1 16:55:06 EST 1998
the graphics are pretty minimal, but I think that this program is done. There are a few more things that could be added to make it even more super-fly but those are just glitz.

Firstly better graphics would be easy to do; they're just a matter of time

A timer could be done easily with a GP.Animator which would update a counter and its graphical representation every second.

Allowing for multiple games to be played without restarting could be done reasonably easilty. Each of the Pieces would need to be able to remove its graphical representation as would all the States, but that's a matter of only a few lines of code. Then the board could move the initialization of the two dimenstional array into a separate method which could be called when a new game is started.

The foundation is all here, extending it is relatively easy with that in place.