Characteristics Of Play Area Cells


Looking More Closely At MineSweeper

Now that we have a conceptualmineField on which to base our model, it is time to start observing the mineSweeper game as we already know it (from memory, or from looking at other implementations of the game), in order to introduce further additions to the model of the game
 
Whilst we are simply observing a game, and capturing characteristics of that game in a model in TKeden, it is notable that this sort of technique is one of great use in creating models for a number of diciplines. Whilst we are using an existing game as our referent for this model, in the creation of a model of say, a railway junction, we use the real life artifact as our source of observables, and use our model to experiment upon in order to gather more knowledge about the operation of the system.
 
It is notable from the description of the MineSweeper game given in the introduction that we do not know the contents of any 'cell' of the mineField until it is uncovered, or it's contents can be derived from surrounding cell values or guessed through luck. Hence, it is clear that the cells need to be of two states - covered or un-covered.
 
In this attempt at a model for TK-MineSweeper, we are using another list to represent whether or not a particular square on the mineField has been uncovered.
 
Recall from the previous page that we defined the minefield as a list, minefield containing 16 elements, each represetning a cell in the 4 x 4 mineField. We can simply create another list, where each element of the list corresponds with a square on the minefield, which contains some value which says whether that particular cell is covered or un-covered. Hence, square 12 corresponds with element 12 in the new list, square 3 with element 3, and so on.
 
We can represent a square being hidden with a value 1, and an uncovered square can be represented by a 0. If we call our list representing the status of the cells status, then typing or copy & pasting the following into the TKeden Input Window and Accepting will provide the relevant information for later additions to the model.

  status is [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1];
Whilst we have the required definition of the status of each cell in the minefield (in terms of un-covered .vs. covered), it may be useful to include a dynamic count of the number of elements covered as the game progresses. Using an is assignment as follows, we may keep up to date on the number of cells uncovered :
  nCovered is status[1] + status[2] + status[3] + status[4] + status[5] + status[6] 
      + status[7] + status[8] + status[9] + status[10] + status[11] + status[12] + status[13]
      + status[14] + status[15] + status[16];
So, in order to find out how many of our minefield cells are currently hidden, we simply total the status values of each element. As TKeden dynamically updates variables defined with the is operator, we always have an accurate count of the number of hidden elements.
 
It is possible to interrogate TKeden at any point with either ? or writeln. Checking nCovered at this point with the following statement should yield the result 16, since 16 cells are hidden :
  writeln(nCovered);
Whilst we now have a board, and the cells have the characteristic that they are hidden or un-covered, we are missing a vital element that nay game of MineSweeper is pretty boring without.
 
What could be missing ?
 
THE MINES !!!
 
The next section of this demonstration adds further complexity to the model by introducing the notion of mines. Clearly, at this early stage, we have no user interface. The user can only look at the current model through interrogation via ? and writeln, and direct references to all variables. Hence, it is time to start also considering some sort of player interface.

 
 
Move to the fourth TK-MineSweeper page...
 
 
 

Updated Wednesday, January 6, 1999