Introducing The Mines


The Mines Themselves

We have a board. We have hidden and visible stated squares. However, we have nothing to go inside those squares. Whilst the cells in a 'complete' mineSweeper contain various values, it is intuitative to include the most simple part first. Hence, we are going to add the notion of mines to our model.
 
There are many different way of incorporating the idea of mines into the model, and the dynamic experimental nature of TKeden accomodates the facilitation of numerous mine implementations. However, here, we are looking at a similar way of defining a cell containing a mine as that of defining whether a cell is hidden or un-covered.
 
Recall from the presious page, that each element of the list status defines whether or not it's respective cell is a) hidden, or b) un-coveed. So, the list status defines the states of the squares respective to their visability to the user. In a similar way, we could define a list mines, in which each respective element defines the state of a cell where the two possible states are a) the cell contains a mine, or b) the cell DOES NOT contain a mine.
 
So, we could say that a value or 1 at a particular position X in the list represents that cell X on the minefield does contain a mine, whilst a 0 represents that X has NO mine.
 
Taking a similar stand as in the definition of the status list, we have the situation where cell 9 is represented by element 9 in the list, mines, and cell 13 is represented by element 13 in the mines list.
 
Hence, we can define our list, mines as follows :

  mines is [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0];
However, the above list reprsents a mineField where there exists no mines. In order to determine that there is a mine a a particular location, we place a 1 in the mines list.
 
Say we want 5 mines, positioned as follows : Our definition of mines should read as follows :
  mines is [0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1];
We now have a mineField which is more dangerous than it was 5 minutes previously.

Keeping Track Of Numbers

Now that we have the mines list, it is useful to know how many mines we have. Whilst we may use a 'cop-out', and simply say 5, it is better to have a dynamic count of the number of mines, since later implementations may produce random minefields with different numbers of mines.
 
We may introduce a dynamically updatable variable, nMines, using the is operator as follows :

  nMines is mines[1] + mines[2] + mines[3] + mines[4] + mines[5] + mines[6] + mines[7]
    + mines[8] + mines[9] + mines[10] + mines[11] + mines[12] + mines[13] + mines[14] + mines[15]
    + mines[16];
This 'dynamically updated' count is comparable with the similar definition used in status earlier in the demonstration. We simply obtain a number telling us how many mines there are. TKeden dynamically retains the value of this variable such that, when it changes, we always know the accurate value of the number of mines in the mineField.
 
With the mines in place, we have a mineField that seems to be taking good shape. However, we need to introduce some quite complex definitions into the model to determine the values in the remaining cells in the mineField. This will be tackled in the next section of the demonstration.

 
 
Move to the fifth TK-MineSweeper page...
 
 
 

Updated Wednesday, January 6, 1999