CPE 101:
Fundamentals of Computer Science 1

The game of "life" was invented by the mathematician John Conway in 1970. It consists of a grid of cells which are either alive or dead and a set of rules for determining which cells will be alive or dead in the next generation. It is an example of what computer scientists refer to as Cellular Automata, that is, systems of cells in a grid where rules are applied that govern the activities of cells and their neighbors.

For a very nice treatment of the game complete with examples, see the web page at:

For this assignment, you will take the ScoreBoard classes distributed Lab 9 and create a Java applet which runs Life in a 50 by 50 grid. Like we did with the gradual development of your Slot Machine game, this doesn't involve many new concepts, but it does take what you should already know and push it a little further.

Your game should:

1. Create an initial board and and choose cells randomly to be alive or dead. (Use Math.random() for this.) 25% live cells seems to produce pretty good runs.

2. Update the board according to the rules. For each generation:
   • Live cells with 2 or 3 neighbors remains alive.
   • A dead cell with exactly 3 neighbors comes to life (is born).
   • In all other cases a cell dies or remains dead.
   These counts of neighbors are done before any updates and all cells are then updated at once. For purposes of counting neighbors, the grid border is considered dead.

3. The game continues to run until either there are no remaining life cells, or the population remains unchanged for 10 generations. (You may want to write a census() method to count the number of live cells in the grid.)

Some help:

To help you along, we have provided the ScoreBoard classes from Lab9. These will provide a good windowing foundation for your Life game. While they are more fully described in the lab write-up, remember that these class files are:

Showlights.java

Board.java

Cell.java

ScoreBoard.java

ScoreBoard is the class that should hold the bulk of the code for the lab. You'll want to convert this into your controller for the Game of Life, so you should rename it to Life.java for this assignment. (You'll have to change your driver, Showlights so that it calls this new file, but that's fine. The driver that I'll use will have that change as well (as many times as necessary, but only that), to meet the assignment specifications.

Remember, the code for all the above can be found via links at: http://www.csc.calpoly.edu/~csturner/courses/101/Labs/Lab9/lab9_life.html

• This program decomposes into a set of mostly independent tasks. For example, board initialization, cell updating and, census taking are more or less unrelated tasks. Remember that independent tasks should be handled by independent methods.
• To simplify neighbor counting, embed the grid in which you're interested inside a grid which is one cell larger and make all those cells dead. (You'll note that the ScoreBoard is already set up this way. It's no coincidence: ScoreBoard was extracted from our game of life.)
• To keep everything clear in your Life program, rename methods and fields to reflect their new significance in the game of life. isLit() might become isAlive().
• Work on this program in stages. Make sure you can draw the initial board before you try to write the update engine. Similarly, be sure you can do one generation properly before you try to loop it.
• When testing the game, try generating patterns you can predict (like a block or blinker) and see if they do what you want.

Use the "handin" facility available from your Central Unix account on Polylog1 to submit these required files to the Pgm6 folder for your section:

Required (all teams or individuals must submit their own copy of these files):

• Life.java (your well-documented source code, including any information the grader or I may need about how to run your program)
• Life.html (the page that calls your code for Life)
• readme.txt (an extra little bit of commentary...but it really is required!)
  There is something nicely tricky about the code that we provided to you: it takes care of the fact that we normally handle array indices in (row/down, column/over) order but handle screen coordinates in (x/over, y/down) order. To show that you really do understand the code we have given you, and how the 2-D array info you are working with relates to what is displayed on the screen, you must also submit a readme.txt file (and it must really be in plain text only: use your basic programming editor to create it) explaining briefly both where and how this transposition occurs. This explanation must be short: both where and how can be explained in one sentence, but you may take up to three sentences if you find that easier!

Do not submit the corresponding .class files (the course account does not have enough space for all of those!); instead, we'll automatically compile them from the .java files you do submit. Note that you must use the exact names specified above for our automatic processes to work. If your filenames differ in any way from those indicated, or if your files do not compile, they will not be graded.)

It is expected that your source code will contain full internal documentation. Use the standard comment block at the beginning of the program for your design specifications and other general information. Use comments throughout your programs to clarify to anyone reading your program what you are doing at each step along the way. If you have additional comments to make, you may submit a supplemental README document, in plain text format, but its existence must be documented in the program file you submit. If you don't understand the expectations here: talk with some classmates, see your instructor during her regular office hours, or make an appointment with your instructor for a time well in advance of the due date.