Tags: %TAGME{ tpaction="" web="KenyonCpp" tag="" }% view all tags

Lab 7

Due: Nov 3, 11:55pm


  • Turn in the code (a cpp file or ideone.com link), and the run outputs as requested below.
  • Remember to format the code as described and the book and text, and to include comments including complete commetns at the beginning of the program.


Feature %
Program correctness and completeness with respect to defination 70%
Code Format (Indenting, variable names) 10%
Code Comments 10%
Turning in runs of the cases below. 10%


The mathematician John Horton Conway invented the “Game of Life.” Though not a “game” in any traditional sense, it provides interesting behav- ior that is specified with only a few rules. This Project asks you to write a program that allows you to specify an initial configuration. The program follows the rules of LIFE to show the continuing behavior of the configuration. LIFE is an organism that lives in a discrete, two-dimensional world. While this world is actually unlimited, we don’t have that luxury, so we restrict the array to 80 characters wide by 22 character positions high. If you have access to a larger screen, by all means use it. This world is an array with each cell capable of holding one LIFE cell. Generations mark the passing of time. Each generation brings births and deaths to the LIFE community. The births and deaths follow the following set of rules.

  • We define each cell to have eight neighbor cells. The neighbors of a cell are the cells directly above, below, to the right, to the left, diagonally above to the right and left, and diagonally below to the right and left.
  • If an occupied cell has zero or one neighbors, it dies of loneliness. If an occupied cell has more than three neighbors, it dies of overcrowding.
  • If an empty cell has exactly three occupied neighbor cells, there is a birth of a new cell to replace the empty cell.
  • Births and deaths are instantaneous and occur at the changes of generation. A cell dying for whatever reason may help cause birth, but a newborn cell cannot resurrect a cell that is dying, nor will a cell’s death prevent the death of another, say, by reducing the local population.


Some configurations grow from relatively small starting configurations. Others move across the region. It is recommended that for text output you use a rectangular array of char with 80 columns and 22 rows to store the LIFE world’s successive generations. Use an asterisk * to indicate a living cell, and use a blank (or space) to indicate an empty (or dead) cell. If you have a screen with more rows than that, by all means make use of the whole screen.


* * *



then becomes

* * *

again, and so on.

What happens with this?

* *
* *
* *


On startup have the program ask for coordinates of where to put *'s:

Welcom to LIFE.  Enter x and y coordinates where 1<=x<=80 and 1<=y<=22.  Enter x of -1 to end.
Enter coordinate 1: 10 10
coordinate 2: 10 11
coordinate 3: 10 12
coordinate 4: -1

        * * *
Enter to 'Y' continue:Y
Enter to 'Y' continue:Y

        * * *

Enter to 'Y' continue:N!


Look for stable configurations. That is, look for communities that repeat patterns continually. The number of configurations in the repetition is called the period. There are configurations that are fixed, which continue without change. A possible project is to find such configurations.


Define a void function named nextGenWorld that takes the array we call world, a 80-column by 22-row array of char, which contains the initial configuration. The function scans the array and modifies the cells, marking the cells with births and deaths in accord with the rules listed earlier. This involves examining each cell in turn, either killing the cell, letting it live, or, if the cell is empty, deciding whether a cell should be born. nextGenWorld will need to have a local array ( newWorld) of the same type and size, and it will compute the next generation status of each cell from world into newWorld.nextGenWorld will then copy newWorld back into world and return.

So, the life of a cell [x,y] depends on surrounding cells:

[x-1,y-1] [x,y-1] [x+1,y-1]
[x-1,y] [x, y] [x+1 ,y]
[x-1,y+1] [x,y+1] [x+1,y+1]

Given each cell, you will write a to examine the surrounding cells to determine what happens to that cell.

One trick is dealing with the boundary conditions, that is when something is on the edge of the array. A neat trick is to make the array one bigger in every direction, and then use this as boundary space. So if we make world[24][82], the x direction goes from 0 to 81, or 82 cells. Make 0 and 81 always be a space, and never change or print these boundary cells. Then a boundary is really not an exception, it is just considered a dead cell.


  0 ... x-1 x x+1 ... 81
0 space ... space space space ... space
... space ... ... ... ... ... space
y-1 space ... [x-1,y-1] [x,y-1] [x+1,y-1] ... space
y space ... [x-1,y] [x, y] [x+1 ,y] ... space
y+1 space ... [x-1,y+1] [x,y+1] [x+1,y+1] ... space
... space ... ... ... ... ... space
23 space ... space space space ... space

There should also be a function display that accepts the array world and displays the array on the screen. Is should merely display the contents of each row right to left.

Design - the following routines might be useful:

  • int alive(char cell) - return a 1 for life ('*'), and 0 otherwise. Use to check if a cell is alive.
  • char nextGenCell(char world[][82], int x, int y) - return a '*' if the cell at this location should be alive in the next generation. Otherwise return a space.
  • void nextGenWorld(char current[ ][82]) - Given the current world, compute the next generation for the world.
  • You find a LOT of interesting patterns here: conwaylife
  • void copyWorld( char from[ ][82], char to[ ][82]) - Copy world from to world to.
There is a cool online version to play with here

Turn In:

Runs of the following cases. Run until they are either stable, or 10 steps, whichever come first. Turn in the results.

  • boat.png (10,10), (11, 10), (10, 11), (12, 11), (11, 13)
  • glider.png (10,10),(11,10),(12,10),(10,11),(11,12)
  • f.png (10,11),(11,10),(12,10),(11,11),(11,12)
Topic attachments
ISorted ascending Attachment History Action Size Date Who Comment
PNGpng boat.png r1 manage 4.1 K 2015-11-01 - 15:14 JimSkon  
PNGpng f.png r1 manage 4.1 K 2015-11-01 - 15:15 JimSkon  
PNGpng glider.png r1 manage 4.1 K 2015-11-01 - 15:14 JimSkon  
Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2015-11-05 - JimSkon
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback