CS31 Lab 5: Game of Life

Due before 11:59pm, Friday Nov. 9

This lab should be done with your lab partner.

Lab 5 Goals:

Lab 5 Introduction

First, both you and your partner should run update31 to grab some starting point code.

  $ update31
  $ cd cs31/labs/05
  $ pwd
  /home/your_user_name/cs31/labs/05
  $ ls
  Makefile  gol.c  oscillator.txt
The starting point code includes: an empty Makefile that you need to implement; gol.c into which you should implement your solution; and osicllator.txt, a sample input file to your program. You should create other input files to test your solution.

Project Details and Requirements

Game of Life

For this lab, you will implement a program that plays Conway's Game of Life. Conway's Game of Life is an example of discrete event simulation, where a world of entities live, die, or are born based based on their surrounding neighbors. Each time step simulates another round of living or dying.

Your world is represented by a 2-D array of values (0 or 1). If a grid cell's value is 1, it represents a live object, if it is 0 a dead object. At each discrete time step, every cell in the 2-D grid gets a new value based on the current value of its eight neighbors:

  1. A live cell with zero or one live neighbors dies from loneliness.
  2. A live cell with four or more live neighbors dies due to overpopulation.
  3. A dead cell with exactly three live neighbors becomes alive.

Your 2-D world should be a TORUS; every cell in the grid has exactly eight neighbors. In the torus world, cells on the edge of the grid have neighbors that wrap around to the opposite edge. For example, the grid locations marked with an 'x' are the eight neighbors of the grid cell whose value is shown as 1.

x  1  x  0  0  0  0
x  x  x  0  0  0  0
0  0  0  0  0  0  0
0  0  0  0  0  0  0
0  0  0  0  0  0  0
0  0  0  0  0  0  0
x  x  x  0  0  0  0
Conway's Game of Life description from Wikipedia, shows some example patterns you can use to test the correctness of your solution (like Blinker, Toad or Beacon).


Implementation Details

Your program will take two command line arguments. The first is a the name of a configuration file that will specify how to initialize the game playing variables (dimensions of the grid, number of iterations, how to initialize the grid cells). The second will indicate whether or not the game of life board should be printed out after every iteration or not.

Here are some example command lines:

# run with config values read from file1.txt and do not print the board:
./gol file1.txt  0       
# run with config file file2.txt and print the board after each step:
./gol file2.txt  1   
Your program should handle badly formed command lines (e.g. print out an error message and exit).

File Format

The input file format consists of several lines of an ascii file. The first three lines give the dimensions and number of iterations, the fourth line lists the number of coordinate pairs followed by the lines with i j (row index, column index) coordinate values specifying grid cells that should be initialized to 1 (all others should be 0):
num rows
num cols
num iterations
num of following coordinate pairs (set each (i, j) value to 1
i j
i j 
...
You can create your own input files in vim (or emacs) by following the file input format.

For example, a file with the following contents generates an interesting pattern that starts in the lower left and walk up to upper right of grid:

30
30
100
5
29 1
28 2
27 0
27 1
27 2

In addition, you will add timing code to your program to time just the GOL computation (the timing should not including the board initialization phase of your code).

Computing Values at Each time step

One problem you will need to solve is how to update each grid cell value at each time step. Because each grid cell's value is based on its neighbor's current value, you cannot update each cell's new value in place (otherwise its neighbors will read the new value and not the current value in computing their new value).

Requirements


Useful C functions and Hints

Example Output
Here is an example of what you might see from different runs. I'm printing '@' for 1's and '-' for 0's because it is easier to see than '0' and '1' characters. You do not need to use the same characters as me. The first shows just the start and end board configuration from a run that is initialized to a very simple oscillator pattern, and the second is the same configuration, but run with 0 as the second parameter (notice the time difference between the two):
# a run with output:
$ ./gol oscillator.txt 1 

start board:

- - - - - - - - - - - 
- - - - - - - - - - - 
- - - - - - - - - - - 
- - - - - - - - - - - 
- - - - - - - - - - - 
- - - - @ @ @ - - - - 
- - - - - - - - - - - 
- - - - - - - - - - - 
- - - - - - - - - - - 
- - - - - - - - - - - 
- - - - - - - - - - - 

end board:

- - - - - - - - - - - 
- - - - - - - - - - - 
- - - - - - - - - - - 
- - - - - - - - - - - 
- - - - - @ - - - - - 
- - - - - @ - - - - - 
- - - - - @ - - - - - 
- - - - - - - - - - - 
- - - - - - - - - - - 
- - - - - - - - - - - 
- - - - - - - - - - - 

total time for 21 iterations of 11x11 is 5.493663 secs

# a run with 0 as the second parameter should print no ouput
# the total time then measures just the gol computation part because
# the printfs and usleeps should not be executed when passed 0
$ ./gol oscillator.txt 0 
total time for 21 iterations of 11x11 is 1.001186 secs

Extra Challenge
After completing a well-designed, well-commented, correct solution to the required parts of this assignment, as an extra challenge you can see how your program compares to mine speed-wise, and see if you can tune your program to beat mine: Speed Challenge.

Even if you do not do the extra challange, you may want to read it over to learn a bit more about running timed experiments, and about gcc compiler optimization flags.

Submit

Once you are satisfied with your solution, hand it in by typing handin31 at the unix prompt.

Only one of you or your partner should run handin31 to submit your joint solutions If you accidentally both run it, send me email right away letting me know which of the two solutions I should keep and which I should discard (you don't want the grader to just guess which joint solution to grade).

You may run handin31 as many times as you like, and only the most recent submission will be recorded. This is useful if you realize, after handing in some programs, that you'd like to make a few more changes to them.