Posted at Jun 20/2005 09:19AM:
Ahmet Akyuz are there anybody to help me my project about conways game of life

---

Chapter 6. The Game of Life

So far we have seen programs that are well-behaved: we have stated what they should do, we have written the code and eh presto! the program acts in the way we imagined. Now we are going to look at a program that has a life of its own :). Or at least one that seems to be doing something on its own.

John Conway's Game of Life stirred up a lot of dust when it was first shown to the world: the idea is very simple and we will look at it later, but from that simple idea came incredible mozaiques - so incredible that people talked of "artificial life". Of course it is not alive nor in any real way are the "animals" it produces, but still, well, look for yourself:

[figures of successive generations]

digression For readers who are interested in theoretical stuff, who are curious of the mathematics behind this game: there is a lot of information to be found on the Internet. For instance: Mathworld [link] has quite a few pages devoted to the subject. Look up "life" on that site!

And while we are at it: the Game of Life can serve in a sense as a computer in itself, watch out for the word "Turing". end digression

So what is it all about? As Will Duquette expresses it (he wrote the program we are now discussing):

"Think of a plane divided up into squares like a checker board. Each square can hold a one-celled animal. You start the game by placing cells in squares. Then you watch the cells breed and die through successive generations. The game is to find starting patterns that do interesting things.

Each square on the board has 8 neighbor squares; cells breed and die based on how crowded they are, i.e., the number of neighbors they have. Each new generation is computed as follows:

• For each square, count the number of neighbour cells.
• If the square is empty, and it has exactly 3 neighbour cells, a new cell will be born there.
• If the square has a cell in it, and the cell has less than 2 or more than 3 neighbour cells, the cell will die.
• All of the counting is done first, and then the new cells are added and the dead cell are removed all at once.

Ready for a small example?

[figure: X X X X ^ | ]

The dot that the arrow points to has three neighbours that are "alive" - so it will live into the next step (generation). The one left of that has only one living neighbour and so it will die!

Exercise 6.1

Finish the picture. Do not forget the squares that are now white.

Exercise 6.2

Run the program and try a few figures.

What would be a good way to program this? Well, if we forget about drawing the pictures for the moment, then let us examine what the program does (or should do as far as we understand it):

• It needs to hold the information about which squares have live cells and which have dead cells.
• It needs to know the neighbours of each square.
• When it calculates what the next picture should look like, it must store the complete new picture. (We can not change the squares as we go along, because we would influence the counts of the squares that after this one).
• Only when it is done, the new picture can be drawn.

Now, put the file "life.tcl" in the editor or print it (whichever is more convenient) - we will examine the code together, which is a good exercise in code reading ;).

After a lengthy but clear description we come across the first procedure: the one that sets up the "chessboard". This procedure creates a "canvas" (see the next chapter for an explanation) and it draws the horizontal and vertical lines.

Then, and this is what interests us the most, it creates circles inside each square. It also creates a list of neighbours:

   # Cache the coordinates of each neighbor.
   set boardInfo($i,$j-neighbors) ""
   foreach {iof jof} {-1 -1  -1 0  -1 1  0 -1  0 1  1 -1  1 0  1 1} {
       set r [expr {$i + $iof}]
       set c [expr {$j + $jof}]
       if {$r >= 0 && $c >= 0 && $r < $cells && $c < $cells} {
           lappend boardInfo($i,$j-neighbors) "$r,$c"
       }
   }

You see: here again a mixture of code and data, just like in the NIM game. (Do not worry about the expr command - it is a general command for doing arithmetic. The line

   set r [expr {$i + $iof}]

could also have been written:

   set r [sub $i $iof]

You may have been wondering about the problem of the cells near the boundaries - or may be not. Well, judging from the if-statement, I'd say, they have fewer than eight neighbours in this program!

digression Such problems near boundaries exist in many different forms. Sometimes they are essential to the problem you need to solve, sometimes they are a nuisance. Getting the boundaries wrong (of any type) is a major source of errors. end digression

The next procedure is toggleCell. What is the effect of this procedure? Can you read it from the code alone (remember, the "cell" is a coloured circle). Then, setCell is very similar. Obviously, with these two procedure the cells can be given a different colour.

Okay, clearBoard is very easy to understand: all cells die. Note that the procedure setCell is used, though just using:

    $boardInfo(name) itemconfigure $i,$j -fill white
    set boardInfo($i,$j) $state

would work just as well - but then we get the problem again that all kinds of fragments need to be changed when we decide to use blue and yellow colours for instance. No, keep this sort of code in small and clear procedures, that is best!

Now, the most interesting procedure is generate:

• It runs over all squares
• Meanwhile it counts the live neighbours for each cell:

     foreach neighbor $boardInfo($i,$j-neighbors) {
         incr nCount $boardInfo($neighbor)
     }

You see how cleverly this is done? If the neighbour cell is alive, the boardInfo array holds a 1 for this cell, so nCount is increased by 1. Otherwise, the array holds a 0 and nCount stays the same. There is no need for an if-statement!

When this is done, the array count holds the number of live neighbours for each square on the chessboard. The second part of the procedure then decides if the cells live or die and adjusts the cell via setCell.

For now, we can forget about the rest of the program - this is "merely" for handling the user-interface.

Exercise 6.3

Can you adjust the code so that a cell on the boundary has neighbours on the other side of the board, rather than none? (This way you create a game board without any boundaries!)

Exercise 6.4

There is a procedure missing, placeGlider, can you fill it in - it should do little more than make a few cells alive somewhere. It is entirely up to you.

Exercise 6.5

What do we need to change to make the game board larger, that is more squares?

6.2 Drawing game boards

!!TODO!!

---

Posted at Sep 17/2004 01:15 PM:
kumahahdadfvwefw

---

Posted at Nov 03/2004 04:15 AM:
Have to write this game in asml for project, any chance of suggestions for asml codeing?

Thanks Mark Edmond

e-mail: cs3me@csc.liv.ac.uk

---

Posted at Nov 20/2004 10:47 PM:
HARSH RAVAL tony_london2004@yahoo.com

---

Posted at Jan 27/2005 06:32 PM:
it is very nice!!!! i like it very much