Output From TK-MineSweeper

How Can We Output Our MineField ?

So, we have our mineField, our mines, our values and status, as well as some sort of interface for the player to select the cells the mineSweeping hero walks upon. All fair and well. However, without some information concerning the state of the game, we haven't an inkling of what is going on. Without detailed interrogation of TKeden through writeln commands, we cannot work out whats going on, and even whether the model is actually behaving in the way we desire.
OK. So it's time we provided some output for the user. What is the best way to output the TK-MineSweeper state at this point in model development, though ?
Again, the answer is - there is no best way. Different people will choose different means with which to output the state of the game. This is one of the things that using TKeden encourages. There is no right or wrong way (or course - there are probably some REALLY wrong ways, but less of that here) of doing it. If the output is correct, then the means is unimportant.
In this demonstration, we will be using the list data type once again to contain different templates representing the mineField itself, as well as labelling templates.

Labelling Template

Whilst we are perfectly free to use writeln abundantly to create some form of output, we have decided to refer to a template here, such that symbols can be changed with only one change in the script. When we refer to templte in this sense, we simply refer to a list (again...), which contains a number of elements which are to be used to create the output display.
At the current point in the development of TK-MineSweeper, it is perhaps premature to consider using the definative notations Scout and/or DoNaLD for representation of our mineField. Although these notations can greatly improve the appearence and usability of the model later on in the development of the TK-MineSweeper mode, at this stage, with such an early model, it would probably be a bad idea.
Hence, for the purposes of model development, we can develop a textual output form. As out mineField is 4 x 4 square at present, it is conceivable that we should want our output to appear in some form such as :

  1  2  3  4
  5  6  7  8
  9  10 11 12
  13 14 15 15
We may wish to label the outer perimeter of the mineField for coherency as follows :
  1  2  3  4
  11  2  3  4
  25  6  7  8
  39  10 11 12
  413 14 15 16
Now, in order to get the appearence of the second example, we require some different elements to be output in the correct places. The building blocks for the outer perimeter of the mineField are : For the purposes of this model, we can split these into two catagories - labels and lines. The following definitions create the lists which can be used to form output :
  labelTemplate is ["1", "2", "3", "4", "\n", " "];
  lines is ["------", ""];
To output an example border, a typical writeln could be :
  writeln(labelTemplate[6], labelTemplate[6], labelTemplate[1], labelTemplate[2],     labelTemplate[3], labelTemplate[4], labelTemplate[5], lines[1], labelTemplate[5],     labelTemplate[1], lines[2], labelTemplate[5], labelTemplate[2], lines[2], labelTemplate[5],     labelTemplate[3], lines[2], labelTemplate[5], labelTemplate[4], lines[2],     labelTemplate[5]);
The above statement should produce the following output on screen :
Now all we need is to output the contents of the minefield within the border we have created in the above statements.

mineField Template

As we begin a game of TK-MineSweeper, we are faced with a 4 x 4 mineField containing X mines, where each cell contains an unknown artefact. We may represent our unknown or 'hidden' cells with (appropriately) a ?.
Taking the approach that has prevailed throughout the creation of the TK-MineSweeper mode, we will again use a list to represent the output contents of the minefield. Again, cell 7 of the mineField corresponds to element 7 of the list, and so on. Hence, we may represent our mineField template as a list of 16 question marks thus :

  mineTemplate is ["?", "?", "?", "?", "?", "?", "?", "?", "?", "?", "?", "?", "?", "?", "?"
    , "?"];
Clearly, when we uncover some cell on the minefield, the ? may become something else, for example, a mine (represented by *), or a value X. Although we are not yet at the stage of development where we can modify the mineTemplte, this list is the list that is modified when cells are uncovered. If a cell, X is uncovered, then conceptually, the corresponding cell element in mineTemplte becomes a different character to represent the fact that the cell is no longer hidden. This will be investigated in the section about interaction with the model later in the demonstration.

Creating An Output String

With the various templates in place, all we have to do is arrange the requisite elements into the correct order, and output those elements as a whole string, which can be output to represent the state of play through a representation of the minefield.
First of all, the string concatenation operator, // should be introduced. This operator allows elements to be concatenated as a single string. Hence : "Indianna"//" "//"Jones" is equivalent to "Indianna Jones".
If we recall the writeln command used above to create the border in which the mineField output will be placed, then we could simply use those elements in that order, with the minefield elements incorporated within to create a coherant whole.
The concatenated string is named outputMF here, and can be defined as :

  outputMF is labelTemplate[5]//labelTemplate[6]//labelTemplate[6]
Phew !
The concatenated string outputMF now represents the entire mineField, including labelled borders.
However, we still have problems. We need to output this game state whenever we make a move which changes an element on the mineField. The next question is . . . how can we make TK-MineSweeper display the current game state whenever we make a change to the board ?

Displaying The MineField When Appropriate

The answer is to use triggered actions. So, what's a triggered action ?
TKeden allows the user to define actions (or functions) which are executed whenever a variable changes. So, say we have a function, Inc, which increments trigger whenever action is modified. We could define Inc thus :

  func Pre : action {
    trigger is trigger+1;
So, if we alter action, then the function Inc is called, and trigger becomed incremented.
The syntax for a triggered action is identical to that for a regular function, except, after the function name, a colon : appears, followed by a list of variables which can trigger that action.
For our purposes, we wish the mineField to be displayed whenever a move is made which causes some change in the state of the playing board. Hence, whenever we affect a change to mineTemplate, the conceptual 'output buffer' of the model, we wish this 'output buffer' to be displayed. We can display the game state simply wy using : writeln(outputMF);. Hence, the triggered action definition could be as follows :
  func dispMF : mineTemplate {
Although we have no internal means with which to modify mineTemplate yet, and hence, no real integration in the model as yet, we may test the output functions by modifying mineTemplate. Each time mineTemplate is modified, we should see the mineField ouput. Try the following (or other) redefinitions to trigger the display routine :
  mineTemplate[7] = "*";

  mineTemplate[11] = " ";
Now the TK-MineSweeper model is starting to come together. We have all the means with which to play a proper game (minus some elements) of mineSweeper, except one crucial element - rules of play. It is this element of the model which allows for a user to actually play mineSweeper, and this element of the model is perhaps the most difficult to design. This is examined further in the next section.

Move to the eighth TK-MineSweeper page...

Updated Wednesday, January 6, 1999