Life - Part 1: Assignment Specification
CAB201 Semester 2, 2020
Last Updated: 04/09/2020
Assigment Details
Progress Due Date: 13/09/ XXXXXXXXXX:59pm
Final Due Date: 20/09/ XXXXXXXXXX:59pm
Weighting: 35%
Type: Individual Project
Version: XXXXXXXXXX/09/2020
Change Log
There is no intention to have this assignment specification change over time. However, if anything does
change or additional detail is added to the specification, the table below will be updated to reflect the
changes.
Version Date Description
1.0 11/08/2020 Initial Specification
1.1 13/08/2020 Added warning about external li
aries to the Academic Integrity section
1.2 17/08/2020 The minimum valid grid size has been increased to 4
1.3 04/09/2020 Added more test cases
Overview
In memoriam of the legendary mathematician John Conway, we will be be exploring one of his most famous
creations as an exercise in programming principles - the Game of Life. Also refe
ed to as Life, the game is
a zero-player game, meaning that it’s behaviour is determined by it’s initial state with no additional input.
Conway explains the rules for the Game of Life in a Numberphile interview (explanation starts at 1:00). The
ules will be described in detail further into the document.
Your task is to create an command line application that can simulate Life. The application must be designed
to be invoked from the command line, where game states and program settings can be provided. Additionally,
the application must display a running animation of Life in a graphical display window (this functionality
has been partially completed for you in the form of a small and simple API that you must utilize). This
assignment is designed to test your ability to:
� Build command-line applications
� Develop high-quality file I/O functionality
� Design a solution to a non-trivial computational problem
� Understand and utilize an external API
1
https:
en.wikipedia.org/wiki/John_Horton_Conway
https:
en.wikipedia.org/wiki/Conway%27s_Game_of_Life
https:
youtu.be/E8kUJL04ELA
Game Behavio
The game of life exists in universe comprised of a two-dimensional grid of square cells. The number of rows
and columns in the universe may be specified by command line arguments (see Command Line Interface
elow). By default, the dimensions of the universe will be 16× XXXXXXXXXXrows and 16 columns). Each cell can
e refe
ed to by it’s row and column, starting in the bottom left with 0 for each dimension. An example of
a 5× 5 Life universe is illustrated in Figure 1.
XXXXXXXXXX
0
1
2
3
4
Figure 1: A 5× 5 Life universe. Row and column indices are labelled. All cells are dead (inactive)
Each cell in the grid can exist in one of two states - dead or alive (also refe
ed to as inactive and active
espectively). Each cell is aware of it’s eight closest neighbours during any generation of the life universe.
These neighbours are the cells positioned horizontally, vertically and diagonally adjacent of any given cell.
XXXXXXXXXX
0
1
2
3
4
Figure 2: Visual representation of a neighbourhood in Life. The neighbours of the cell highlighted in blue
are highlighted in light blue.
Life progresses (or evolves) through a series of generations, with each generation depending on the one that
proceeded it. The rules that determine the next generation are rather simple and can be summarized by the
following:
� Any live cell with exactly 2 or 3 live neighbours survive (stay alive) in the next generation.
� Any dead cell with exactly 3 live neighbours resu
ect (become alive) in the next generation.
� All other cells are dead in the next generation.
XXXXXXXXXX
0
1
2
3
4
Generation 0
XXXXXXXXXX
0
1
2
3
4
Generation 1
XXXXXXXXXX
0
1
2
3
4
Generation 2
XXXXXXXXXX
0
1
2
3
4
Generation 3
XXXXXXXXXX
0
1
2
3
4
Generation 4
Figure 3: Generational evolution of a glider. Note how the pattern repeats after 4 generations of evolution.
An example of the effects of these rules is given in Figure 3, which contains five consecutive generations.
To describe how one of the rules work with an example, from generations 0 to 1, cell (3, 1) is changed from
2
dead to alive because it has exactly 3 live neighbors in generation 0 (cells (2, 0), (2, 2), and (2, 3)). For this
assignment, life will continue to evolve for a pre-determined amount of generations (50 by default).
Seeds
The first generation of the game is called the seed, which will be determined randomly, or through a formatted
file. The long term behaviour of the game is determined entirely by the seed, meaning that the future state
of any game is deterministic. This is one way you can determine whether your program is running co
ectly
and will be the basis for grading your assignment.
Randomisation
The default method for generating a seed is through randomization. For each cell in the seed, the probability
of the cell being alive is 50% and is otherwise assumed dead. The probability that any given cell is initially
alive can be modified through command line arguments.
File
Alternatively, the seed can be defined by a file that is supplied through the command line arguments. If
a file is supplied in the command line arguments then the randomization process described above will not
occur. The seed files will have the extension of .seed and will be formatted according to the following rules:
� The first line of the file will always be #version=1.0.
� Each line of the file represents a cell that is initially alive (the rest are assumed dead).
� Each line will contain two integers, separated by a space character.
◦ The first integer represents the row index of the live cell.
◦ The second integer represents the column index of the live cell.
Below is an example of a seed file that would result in the glider pattern shown in Figure 3 (Generation 0):
#version=1.0
3 2
2 0
2 2
1 1
1 2
Because the file and the universe size are specified independently, it is possible for a file to specify alive cells
that exist outside the bounds of the universe. If this occurs, the user should be presented a warning and the
ecommend universe size that would suit the seed file (the maximum row and column indices). See detailed
equirements in Command Line Interface below.
Periodic Boundary Conditions
Periodic boundary conditions can be applied to a Life universe for some more interesting behaviour. Unde
periodic boundary conditions, a cell that exists on the boundary of universe will have neighbours that "wrap
around" to the other side of the universe.
You will find it particularly useful to draw on your knowledge of integer arithmetic operators (such as
modulus) when attempting to implement this feature.
This is best described visually, see Figure 4. Consider the last pair of examples in the figure. In the
non-periodic case, the the neighbouring cells that would exist if the universe was any larger ((5, 3), (5, 4),
(5, 5), (3, 5) and (4, 5)) are non-existent. In the periodic case...
3
� The neighbouring cells that would normally be located at (5, 3) and (5, 4) are located at (0, 3) and
(0, 4).
� The neighbouring cells that would normally be located at (3, 5) and (4, 5) are located at (3, 0) and
(4, 0).
� The neighbouring cell that would normally be located at (5, 5) is located at (0, 0).
XXXXXXXXXX
0
1
2
3
4
Non-Periodic
XXXXXXXXXX
0
1
2
3
4
Periodic
XXXXXXXXXX
0
1
2
3
4
Non-Periodic
XXXXXXXXXX
0
1
2
3
4
Periodic
XXXXXXXXXX
0
1
2
3
4
Non-Periodic
XXXXXXXXXX
0
1
2
3
4
Periodic
Figure 4: Examples of neighbouring cells in contrasting non-periodic and periodic boundary condition based
universes. The neighbours of the cell highlighted in blue are highlighted in light blue.
Update Rates
Even in the most inefficient implementations of Life, the computation time for a single generational evolution
can be quite fast (for small universes). As such, it is often necessary to limit the number of generational
evolutions that can occur every second. This can be accomplished using a number of different different
methods, two of which are
iefly described below:
� (Simple) Add a delay between each generational evolution by sleeping the main thread. Although
simple, this method can be inaccurate, particularly if your algorithm for evolving your universe is slow.
� (Accurate) Use a stopwatch or timer to delay the next evolution until the co
ect time has elapsed.
Keep in mind that the time between updates can be found with the following formula (where T is the time
etween updates in seconds, and f is the update rate/frequency):
T =
1
f
Display
You will not be required to write your own display component for this program. Instead it has been provided
to you in the form of a li
ary called Display. It is your task to integrate this li
ary into your program. The
project li
ary is already contained within the assignment template provided on Blackboard. To interface
with the display, you will need to use the Grid class. The classes in the li
ary are well documented using
XML style comments, you are encouraged to read these comments to help you understand the code. Ensure
that you do not modify the code in this li
ary so that the display works as intended.
Command Line Interface
Many modern software applications are controlled via graphical user interfaces (GUI), however command line
interfaces (CLI) are still frequently used by software developers and system administrators. The creation
of GUIs are outside the scope of this unit (event driven programming is covered more in CAB302), so
your application must be created using a CLI instead. Depending on the application, CLIs have different
usages. This section will describe the general structure and usage of a CLI, and the specific usage that you
program’s CLI must follow. Failure to follow these CLI requirements precisely will mean that
your program cannot be tested co
ectly and will likely result in severe academic penalty.
4
CLI Command Structure
A lot of single purpose CLI programs follow the following structure:
executable [
]
The right angle
acket (>) indicates the beginning of the command line prompt, you do not type this
yourself. The executable is the name of the program. In this assignment, the program will be called life.
More specifically, because we are creating a .NET Core application, the .dll file that is built for our program
can be executed on MacOS and Windows like so:
dotnet life.dll []
The [] are a series of optional arguments for your program. These arguments will allow the
program to run with a variety of different settings that differ from the defaults. Each of the option type
arguments