I love Minesweeper. There are many versions out there, but the one I've spent the most time playing comes installed on Windows 7 Home Premium. Despite it's glaring design flaw (puzzle games should never require guessing), I keep coming back. It's the only game I have installed on my phone. Bored one summer, I decided to build the game for myself and my love for it grew even stronger.
Look closely at my images and video of the game. You'll notice some visual similarites to one of my other projects, Connect 4. That's because I used the same graphics library. Here's what I had to say about it on that page.
Connect4.java relies on JEventQueue.java and JBox.java. Both are libraries created by Mads Rosendahl, a professor at Roskilde University. I've never met him, but my professer at BU gave those two files to students so we could make our GUIs.
An important thing I learned from my prior experience with Rosendahl's tools was that they're excellent for creating grid-based GUIs. Both Connect 4 and Minesweeper contain large two dimensional arrays of buttons. 64 (8 rows x 8 columns) were needed for Connect 4. Minesweeper needed 3 different arrays (one for each difficulty setting), with the smallest containing 81 and the largest containing 480. If I were to hand code even 64 buttons I would have almost certainly made errors (assuming I don't die of boredom first). In both Connect4.java and BetterMinesweeper.java, there is a method called "printBody". It doesn't get called when either game is running, but it was very helpful during development because it generated most of the code needed for the buttons. Unlike Connect 4, Minesweeper's GUI is written in the same file that houses the game's logic because there was no AI component to complicate the way the graphics appear.
In addition to the light code generation, Minesweeper gave me the pleasure of writing two mutually recursive methods. Mutual recursion is one of those techniques I read about in computer science texts, but never had a real problem to apply it to. I was really excited when I got the opportunity to do so with the game's "revealOne" and "revealNear" methods. What exactly do those methods do? Let me give you some context first.
Even at the highest difficulty, most tiles do not have a mine hidden underneath them. Requiring players to left-click every one of those tiles would needlessly lengthen each game. This would especially annoy players who like to race against the ticking timer at the bottom of the window. The game automatically reveals the contents of a tile in two instances. The first is when the player left-clicks to reveal the contents of a tile that is not adjacent to any mines. In this case there is no point in printing a number on the tile because it would have been zero. The game does the player a service by automatically revealing all of the adjacent tiles to save time. The other instance in which this takes place needs to be triggered by the player. The requirements are little more complicated. The tile needs to: (a) already have been revealed, (b) have a number of adjacent tiles that is greater than the number written on the tile, and (c) the number of adjacent tiles marked red (meaning the player believes these tiles have mines under them) needs to be equal to the number written on the tile. If all three requirements are met and the player double-clicks the already revealed tile, then the game automatically reveals all of the adjacent, unrevealed, unmarked tiles. Doing so can backfire and result in a loss if the marked tiles (part c) turn out to be incorrect.
Regardless of how the recursion gets started, a trace of the Java stack would show revealOne at the beginning which invokes revealNear just once (zero times in the non recursive base case, of course). Then revealNear makes eight calls to revealOne. Visually, the player witnesses a cascading effect of tiles revealing themselves until the base case is reached. I'm sure there's an iterative solution, but after spending hours trying and failing to divine one, I decided to start thinking recursively. The final code is fairly clean, if you'll allow me to assess my own work. It was years after completing development until I learned this kind of algorithm is called flood fill.
Watch the game in action at the YouTube link below. Play it for yourself by downloading this zip file. When you unzip (I recommend using 7-zip), please keep the structure of the folders the same. The minesweeper folder should contain a subfolder called "src" and BetterMinesweeper.jar. Open the jar file to play. The src folder contains the game's image files. Tampering with that might remove the images from the game. It'll still be playable, but it won't look the way I intended it to. Here's a handy guide.
