There is only one part to this project, due 11pm November 17. You should review the project soon. However, we'll be discussing it in lecture Nov 13, so you may want to wait until after that lecture to begin working on it seriously. The project actually only involves writing around 30 lines of code, but you need to understand an existing larger program. (We're giving you a starting version that you can modify.) There is also an extra credit option, in response to some requests for this.
Turn in the entire program using turnin as usual (including all the code, both the part that you use without modification and the part that you modify).
The Game of Life is a simple example of simulation using cellular automata. The mathematician John Conway proposed it in 1970, and it has attracted interest ever since. It's not a game in the sense of two players competing, but more in the sense of a simple set of rules that can give rise to complex behavior. The game is played on a 2 dimensional array of cells. Each cell is either alive or dead. We are given some starting configuration of live and dead cells. Then, at each step (in other words, at each tick of the simulation clock), we compute the next state of the array. This is done as follows. For each cell, calculate how many live neighbors it has. Each cell has 8 neighbors: up, down, left, right, upper-left, upper-right, lower-left, and lower-right. If the cell is dead and if it has 3 live neighbors, it comes alive. If the cell is alive and has 2 or 3 live neighbors, it stays alive. Otherwise it dies (or stays dead), either of loneliness or overcrowding. Important: the next states for all the cells are computed using the current states of all the cells -- you'll get wrong results if you update a cell and then use the updated state of that cell when computing the state of its neighbors.
The game continues indefinitely, although obviously you'll want to stop it at some point. Also, conceptually the 2-dimensional array of cells is infinite in all directions. In practice, of course, we have to make it finite; in the starting code it is 30 by 30 cells.
Here is an executable file that shows what the solution should look like:
To begin, download the following code as a starting point. To download the code, click on each link and save the file under the suggested name. The version above uses a simplified update rule that makes the cells just move 1 to the right each step. To do the assignment, you have to replace the simplifed update rule with the correct one. The procedure that you need to modify is called "oneStep". There are other procedures that draw the image, respond to commands, and so forth -- these are all OK as they are, and you don't need to change them. So concentrate on the "oneStep" procedure!The code uses a global variable "cells", a 2-dimensional array, that holds the current state of each cell. There is a second array "newCells" that we use to hold the next states of all the cells. After computing all these new states, we copy "newCells" into "cells". (Remember that the next states for all the cells are computed using the current states of all the cells.) Use these variables in your final version as well.
What about cells at the edge of the grid? Do we need to write special cases to avoid looking at neighbors that are off the grid? No -- here we use a standard trick. We make the array cells 1 bigger in each direction than it needs to be, so that it goes from 0 to nRows+1 and from 0 to nCols+1. However, we only update the cells from 1 to nRows and from 1 to nCols. The cells just outside this region always stay dead. We can check their state when doing updates, however; thus avoiding a lot of special cases. The simplified update rule uses this trick already, so you can look at the sample code for more details.
You only need to turn in the final working program. However, we suggest that you do a few simpler experiments to get started.