CSC171 – Project 3 – GameOfLife

Due: April 29th by 1159pm (anywhere).

This project will give you practice integrating all the knowledge and skills you have obtained thus far into the semester. You are asked to implement a graphical simulation of Conway’s Game of Life. You are allowed to complete this project solo, or team of up to three students.

1 The Game of Life

The simulation maintains a rectangular grid of locations, called cells, where each cell is either empty, or has life. The simulation proceeds by repeatedly applying two rules:

• birth - any cell with exactly 3 live neighbors comes to life

• death - any cell with fewer than two live neighbors dies (by underpopulation), and any cell with more than 3 live neighbors dies, as if by overpopulation.

For the above rules, the neighbors of a sale are simply all the adjacent cells, including the diagonals. They do not include the cell itself. It is important to see that the update is calculated in one pass – it is meant to be a simulation of many things happening simul-taneously. Therefore you must compute and store the neighbors value for all cells before applying the life or death rules. (Otherwise this typically causes all cells to die due to repeated application of the death-by-underpopulation rule.) It’s easier to see graphically. Please take a moment to study Figure 1.

Figure 1: An example step of the simulation. You can see each of the cases: birth, death, and unchanged cells.

2 Project Requirements

1. Your program should simulate a 20x20 grid by default; however, see below regarding extending this as a flourish.

2. Your program should behave “reasonably” when resized – the grid should visually expand/shrink as appropriate, and the controls should remain visible.

3. You must include a button to reset/randomize the board. By default, you can simply set each cell to be dead or alive with equal chances; however, see below regarding extending this as a flourish as well.

4. You must include a way to start and stop the simulation. This could be two buttons, or a toggle button. By default the simulation should update once per second. See below regarding extending this as well.

5. Your program should display the number of steps since the simulation was most recently reset. This can be drawn as text, or you may use something like a JLabel. This will be particularly helpful when viewing still life patterns.

6. In addition to the above requirements, you must also choose and implement at least two flourishes:

(a) Include a slider to set the simulation speed (include labels to indicate the limits).

(b) Include a slider to set the density (between 0% and 100%) when resetting/randomizing the board. labels to indicate the limits.

(c) Add a way to control the size of the simulation grid – as in the number of cells, rather than visually. This could be a text field or a slider.

(d) Add a toggle/checkbox to enable/disable “wrap around”.

(e) Add buttons to load/save the board from/to a given file. (Hint: check out the JFileChooser tutorial.)

(f) Add a way to interactively configure the board by clicking to switch cells from alive to dead, and vice versa. You should include a button for entering/exiting this mode.

(g) Make it look cool. Explore different colors for the dead cells, live cells, and the grid.

(h) Something else? Feel free to post an idea for an extension to slack within *one week after posting this assignment*. I will either approve (for credit) or deny the idea publicly on slack, that way everyone gets an equal chance.

3 Collaboration and Academic Honesty

You may choose to complete this project alone, or with a small team.

Each person added to a team increases the number of required flourishes by one. A two person team must complete three flourishes. A three person team must complete four, and a four person team must complete five.

If you choose to work as a team, you must choose a team name. This is not a joke. A team name will help us organize the submissions when grading them. One student per team will submit the project zipfile. All students in a team must submit a plain text file stating their team name, the other team members, and who is submitting the zipfile.

Lastly, all team submissions must include a collaboration statement in their readme which states the team name, the team members, and describes the contributions of each member of the team. (E.g., person A worked on flourish X, person B debugged the grid, ...)

4 Submission and Grading

Zip your solution program, GameOfLife.java and a readme file and into a zip file named gameoflife_XXX.zip, where XXX is replaced with your netid for solo students (what you use to log in to blackboard), or your team name for students working together as a team. This will help us to efficiently grade your submissions.

Submit your zip file to Blackboard before April 29th 2021 at 1159PM.

Your grade for this assignment will be based on the following criteria:

• Basic Requirements - 60%.

• Style, documentation, file names and formats - 16%

• Flourishes - 24%

5 Parting Comments

Conway’s Game of Life is a simulation with a rich literature full of interesting and surprising results. There are many patterns which repeat, called oscillators. There are patterns which, one they show up, never change, called still lifes. And there are patterns which “leave the board” called gliders. There are even patterns which replicate themselves. The game of life is also relevant to computing culture, as it was one of the earliest applications of computing for fun. If you get lucky with an interesting seed, then watching the simulation unfold can be a thing of mathematical beauty as well – like a digital fishtank. There is a good article on Wikipedia, here: https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life

5.1 How to Solve this Project

• Understand the rules of the simulation: birth and death.

• Break the problem down into subproblems, such as implementing the simulation, and visualizing it. E.g., imagine you have a magic function that solves the simulation – how could you use it to build the GUI? How would you design the GUI to look – maybe try using a pencil and some graph paper.

• Stuck? Look for subproblems. Break it down. Not sure how to draw a grid? Think about how to draw a line. Need to do something several times? Remember the things you learned about iteration and looping. Keep typing the same code, or copy and paste? Think about defining a helper method. Is your code getting too complex to understand? Remember what we learned about encapsulation – consider a helper class.

• Really stuck? As in, trying to figure out one bug and it’s 3am and you’ve been working since lunch? Walk away! Most people hit a state of diminishing returns where one can actually get more work done in a given time-frame by taking breaks.