This is my version of an old, well known game and a contribution to the CodeProject Mobile Developer competition. This is my second .NET Compact Framework based application (The first was of course a HelloWorld.) and this is also my first CodeProject article.
One thing I always missed on my PocketPC was our old sweet Minesweeper. So I have decided to invest a couple evenings to play with Visual Studio .NET. After one week I had a normal single player version.
The second step was a multiplayer modification of this game (like MinsweeperFlags from MSN Messenger). A hot seat version (both players on the same Pocket PC) was ready very soon, but my goal was a game over a Network or an IrDA. I have written the network layer and ... that's where I am staying now.
Everyone knows simple rules of Minesweeper. My single player mode works the same way.
Because MinesweeperFlags is not so well known as the classical Minesweeper I'd like to say some words about its rules. There are two players Red and Blue one. Game objective is to find and flag mines that are concealed on the board. The first player to flag more than half of the mines wins. Click your left mouse button on a square to see if a mine is there. If a mine is there it will be revealed and your colored flag will be planted on it. You will then get another turn. If the square does not contain a mine, your turn will be over. Each player receives one point for each mine they flagged.
Using the code
In fact the whole Program can be divided into three layers.
The first layers is implemented in the
Field class. It describes location of mines on the field and a current state of each cell. So this class is only design as data storage structure.
The game logic and rules are implemented in
MultiplayerGame classes. These classes are derived from an abstract class
GameBase, which implements common behaviour for both game versions. All these classes implement the
IGame interface. It makes possible to operate with them from GUI without exactly knowing (in most cases) which version is currently running.
I use events to simplify the intaraction between layers. For example
OnCellChanged event will be thrown to notify the presentation layer that content of a specific cell was changed and it must be redrawn.
public class SinglePlayerGame: GameBase
public SinglePlayerGame(byte aWidth, byte aHeight,
byte aBombCount): base(aWidth, aHeight, aBombCount)
public override void ClickCell(byte x, byte y)
if (_field.Bombs[x,y]==Field.ISBOMB) GameOver(Player.None);
if (ClosedCount==_field.BombCount ) GameOver(CurrentPlayer);
public override void SetFlag(byte x, byte y)
if (_field.CellStates[x,y]==CellState.Open) return;
CellState BeforeState = _field.CellStates[x,y];
CellChanged(x,y, BeforeState, _field.CellStates[x,y]);
GamePresentation class is responsible for drawing the game field and the interaction with the main form. The whole user interaction, sound effects and other stuff like that are concentrated in
- There is in fact one more layer (
UdpComm class) to implement network communication. In the current version of this program it will be used only in
frmStartMultiplayer form to detect existence of a network, and to perform a handshake.
Points of Interest
There are some interesting issues I'd like to share with you.
- Application Icon on Pocket PC - When a windows application has only one large icon (32 × 32 pixels) and it must be shown small icon view it will be scaled automatically. To my surprise it was not a case with my Pocket PC 2002, it showed only left top 16 × 16 pixel rectangle. That is why I had to create both 32 × 32 and 16 × 16 icons.
ImageButton - As you probably know there is no
ImageButton in Compact Framework. My initial idea was to present cells as ImageButtons and change image when necessary. I found a Microsoft article How to Create a Microsoft .NET Compact Framework-based Image Button and used their implementation of
ImageButton. To increase the performance by drawing the field I switched to manual drawing using Graphics. This way it works considerably faster.
- Threading in Compact Framework - To simplify the development I wrote and tested almost all modules (except GUI of course) in a Windows application. Then I have transferred this code into Mobile application. In most cases it worked without any changes, but for instance I have discovered that
Thread in Compact Framework has for instance no
IsAlive property and no
Abort method. So when programming Compact Framework always think about it's limitations.
- Moreover there are number of useful things you can find in the source code. For example working with embedded resources or playing a WAV file asynchronously. To my surprise the 2002 emulator plays normal system sounds but not my WAVs. On the other hand 2003 emulator does both.