Game of Life
Conway's Game of Life
Authors: Alexander Booth, Jackson Mandeville, Theo Chitayat
What is the problem?
The game of life is a cellular automaton where cells can either be alive or dead. Given a start state of alive cells, the game evaluates which cells should live or die in the next state based on the four following rules. (Rules from here)
- Any live cell with fewer than two live neighbours dies, as if caused by under-population.
- Any live cell with two or three live neighbours lives on to the next generation.
- Any live cell with more than three live neighbours dies, as if by over-population.
- Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
Though the game of life has no players and no goal, interesting patterns and "machines" can be created. Using Haskell, we want to be able to replicate the game of life.
What is the something extra?
For our something extra, we want to try to create a GUI so that a user can define a start state. Then we want to either render a number of steps from the given start state or show the simulation in real time. If we have extra time we will try to add color to the images which might show the lifetime of a cell or other interesting information.
What did we learn from doing this?
NOTE: Must open .gif files in new tab to view animations.
During the course of this project we learned several things about writing programs in Haskell.
First, we learned that Haskell does not work very well with 2d-arrays because arrays in Haskell are immutable; this makes editing a single value in a 2d array very costly. We ended up using a list of (x,y) coordinates to make it run faster. Second, we learned that compiled Haskell is much faster than interpreted Haskell. Our program was very slow when using the interpreter, but it runs at a reasonable speed when we compile it with O3 optimization. We also learned how to implement a graphical interface with Haskell