Relationships Between Cells & Mines

Definitions Of Cell Values

Our current model consists of a minefield.
Each cell in the mineField has some status - 1 if that cell is hidden, and 0 if that cell is visible.
Each cell in the mineField also has some status in terms of mines, containing 1 if that respective cell contains a mine, and 0 for cells that do not contain mines.
Recall from the introduction that we defined the game such that an uncovered cell may contain a) a mine, or b) a value, or c) a blank.

We need to be able to work out which cells have values, and which have blanks, and what those values are.
Taking what now seems a good approach to this solution, we can define a list, which corresponds to the board list, mineField, which contains the values of the squares on the board. We can represent a blank as a 0 in this list, and any other values as the value in the list
The only problem is - how to define each of those values.
We know that we define the value of a square as the number of mines surrounding that cell in an 8-connected area. Hence, we can simply count the mines in the 8-connected area of the chosen cell, and print the resultant figure inside the cell to represent it's value. If that value is 0, then the cell is a blank.
This is quite a complex definition, as each element in the list, representative of each cell in the mineField, needs to total up it's 8-connected elements. The following statement, which can be copy & pasted, is used to create such a relationship :
  values is [(mines[2]+mines[5]+mines[6])
    , (mines[1]+mines[3]+mines[5]+mines[6]+mines[7])
    , (mines[2]+mines[4]+mines[6]+mines[7]+mines[8])
    , (mines[3]+mines[7]+mines[8])
    , (mines[1]+mines[2]+mines[6]+mines[9]+mines[10])
    , (mines[1]+mines[2]+mines[3]+mines[5]+mines[7]+mines[9]+mines[10]+mines[11])
    , (mines[2]+mines[3]+mines[4]+mines[6]+mines[8]+mines[10]+mines[11]+mines[12])
    , (mines[3]+mines[4]+mines[7]+mines[11]+mines[12])
    , (mines[5]+mines[6]+mines[10]+mines[13]+mines[14])
    , (mines[5]+mines[6]+mines[7]+mines[9]+mines[11]+mines[13]+mines[14]+mines[15])
    , (mines[6]+mines[7]+mines[8]+mines[10]+mines[12]+mines[14]+mines[15]+mines[16])
    , (mines[7]+mines[8]+mines[11]+mines[15]+mines[16])
    , (mines[9]+mines[10]+mines[14])
    , (mines[9]+mines[10]+mines[11]+mines[13]+mines[15])
    , (mines[10]+mines[11]+mines[12]+mines[14]+mines[16])
    , (mines[11]+mines[12]+mines[15])];
This definition can be tested for correctness. Try the writeln command following to display the conceptual minefield :
  writeln(values[1], values[2], values[3], values[4], "\n", values[5], values[6], values[7],     values[8], "\n", values[9], values[10], values[11], values[12], "\n", values[13], values[14],     values[15], values[16]);
If the code is correct, then, referring back to the definition of the location of the mines, the output should resemble the following :
Of course, this basic output does not consider the graphical appearence of the mines as of yet, and so the mines do not appear in the output.
So, we have the basic essential elements for the TK-MineSweeper game. Now, it is high time some coherant player interface be introduced such that a user may interact with the model as it currently stands. The beginnings of this appear in the next section.

Move to the sixth TK-MineSweeper page...

Updated Wednesday, January 6, 1999