Resources:

• Starting code: /home/assignments/assigment4/code (you must use this starting code, if you write your own code it must have the equivalent capability)

• Input files:  /home/assignments/assigment4/inputs (your program must work with these inputs files)

• Output files:  /home/assignments/assigment4/outputs (the TA will compare your program output vs. the output in these files, the patterns must match in order for credit to be awarded).

You are to implement a text-based version of Conway's "Game of Life" biological simulation. Each location in the simulated world either contains: an empty space or a life form ("critter"). As each time unit (a "turn") passes in the simulation a new critter may be born into an empty square or an existing critter may die off. The rules of births and deaths will be specified in the next section.

Initialization of the program

With the pre-written There are two approaches for reading the starting information from file. There is no advantage to using one vs. another. One approach splits the task into two functions to make things easier for students to understand while the other combines the tasks into one function. Both functions return a list that has been initialized from the data in the specified file. If there is problems reading from the input file (e.g. wrong file name entered) then the list will display all exclaimations '!'.

1) Option I, using a single function: createListFileRead(). The function creates a new empty row with each iteration of the outer loop. The inner loop successively appends new data (read in from file) onto the new row.

2) Option II, using two functions: initialize() and readFromFile(). The first function creates the list row by row and then appends a default value for each element '!' to the end of each row. The second function performs all of the file input. Line by the line the text from the input file is read in and the along that line each character is used to set each element of the list.

The input file will specify the starting positions for most of the main elements in the simulation:

• '*' represent an instance of a Critter.

• A space represents an empty location in the world.

There are several input files in the course directory with different starting patterns of Critters that range from an empty world to complex patterns of biospheres. The more of these input files that your program can correctly process, the higher will be your grade. Each of these input files will produce a 10x10 list. Your program does not have to handle input files that produce lists of other sizes.  To allow you check your work there are also output files (one per input file) that show the effect of different starting patterns. Important grading point: Your program functionality marks will only be awarded if your program produces the same results as these outputs. For example, file "1empty.txt" starts out empty and should therefore never contain a Critter in the pattern. Input file "6complex.txt" will produce a stable pattern of 4 Critters in a square by turn 20. Partial marks will not be awarded if your pattern of Critters is "close" to the pattern produced my program. Both of these requirements (producing the same patterns in your output and documenting which input files that your program correctly handles is necessary to make the marking process reasonable - don't expect the marker to spend hours tracing code to figure out if things are working). However, providing ahead of time the results that your program must display is also an advantage for you. You will know if your program is "working or not" based on the pattern match (immediate and continuous feedback). But looking at the patterns is not a substitute for implementing and employing a debugging mode. The debugging mode can be very useful for helping you determine why and how your program is malfunctioning (if you have good debugging output messages)

The input files can be found under: /home/231/assignments/assignment4/inputs.  The corresponding output files can be found under: /home/231/assignments/assignment4/outputs.

Another requirement to get any credit for your assignment is that the display of the grid must be done using the display() function provided or you must write an equivalent function yourself. This grid is required because it makes the display of world easier to read and interpret for both you and the marker.

Running the simulation

Once the information has been read into the 'world' list and copied into the 'newWorld' list your program will employ the [rules of births and deaths]. When the program first runs the list displayed on the left should display the state of the world read in from file ("before") while the one on the right displays the state of the world after births and deaths have occurred. You will need to modify the starting program so that each turn the state of the world before the turn is displayed on the left and the results of the turn (after births and deaths have occurred) are displayed on the right [Sample screenshot using the input file "5edge_cases.txt"].

Rules of births and deaths

After initializing the starting positions, the program will simulate the births and deaths of the critters over time on a turn-by-turn basis. The user can either hit <enter> to advanced the simulation by another turn, 'q' or 'Q' to end the simulation.  [Debug mode] can be toggled by entering 'd' or 'D' when prompted to proceed to another turn. The births and deaths of critters is based solely upon the number of neighbors in neighboring squares. Each square will have from 3 - 8 neighboring squares (inner squares have 8, outer squares can have 3 at corners or 5 on the top/bottom/left/right edges). The square where the possibility of a birth or death is being examined is marked with a question mark ? in the examples below.

Births (square is currently empty)

A birth can occur in an empty square if that square has exactly 3 neighbors, some (non-exhaustive) examples:

*      * ?       *

*       ?    *   *

Deaths (square currently contains a Critter).

A Critter can die of loneliness if it has zero or only one neighbor.

?

?      *

A Critter can die of overcrowding if it has four or more neighbors (non-exhaustive number of examples below):

*      * ?  *   *

* ? *   * * *

The Critter will remain living if it has 2 or 3 neighbors.

?	*
*	*

Births and deaths will occur simultaneously in the simulation. How do the rules of births and deaths relate to the 10x10 world? Each turn the check for births and deaths must be made in each of the 100 squares. As was the case when reading from file the 'before' case is shown on the left and 'after' case is shown on the right.

Debugging mode

Entering 'd' or 'D' will toggle debugging mode (on becomes off, off becomes on). The flag 'debugOn' will track whether debugging message are to appear or not:

The exact content of the debugging messages is left to your descretion. As the name implies the debugging tool should be used to help you test and debug your program. Here are examples of debugging messages[1) Display of the neighbor count for each square (using data file: "5edge_cases.txt") 2) Messages specifying where births and deaths have occurred (using data file "3one_birth.txt")]. Again you are not bound to produce these exact messages in order to get credit for the debugging feature but they are provided to give you an idea of how you can use this feature to test your program.

D2L configuration:

• Multiple submissions are possible for each assignment (may not apply for all assignments but I have the same configuration to be consistent(: You can and should submit many times before the due date. However, this means that TAs will only mark the latest versions of each file submitted via D2L. Even if the version of a document that you want marked has been uploaded into D2L if it isn't the latest version then you will only get marks for the latest version. (It's unfair to have the TAs check versions or to remark assignments simply because you didn't check that the latest version was the correct one).
• Important!  Multiple files can be submitted for each assignment. I am allowing you to submit multiple files for each assignment so don't archive/compress multiple files using a utility such as zip otherwise your work may not be graded.

Marking

• Assignments will be marked by your tutorial instructor (the "Teaching Assistant" or "TA"). When you have questions about marking this is the first person that you should be directing your questions towards. If you still have question after you have talked to your TA, then you can talk to your course (lecture) instructor.
• As well as being marked on whether "your program works" for full assignments you will also be marked on non-functional requirements such as style and documentation (this is not the case with mini-assignments). Style and documentation requirements of the previous assignment must also be followed and implemented for this assignment. This assignment will include a separate [marking checklist] so you can tell ahead of time how marks will allocated. As well you can see how marks were and were not awarded after marking is done. Besides seeing your grade point in D2L you can also see the detailed feedback that your TA will enter for each student. You can access the grading sheet in D2L under Assessments->Dropbox and then clicking on the appropriate assignment link. If you still cannot find the grading sheet then here is a [help link]

Points to keep in mind:

1. Due time: All assignments are due at 4 PM on the due dates listed on the course web page.  Late assignments or components of assignments will not be accepted for marking without approval for an extension beforehand. Alternate submission mechanisms (non exhaustive list of examples: email, uploads to cloud-based systems such as Google drive, time-stamps, TA memories) cannot be used as alternatives if you have forgotten to submit work or otherwise have not properly submitted into D2L. Only files submitted into D2L by the due date is what will be marked, everything else will be awarded no credit.
2. Extensions may be granted for reasonable cases by the course instructor with the receipt of the appropriate documentation (e.g., a doctor's note). Typical examples of reasonable cases for an extension include: illness or a death in the family. Example cases where extensions will not be granted include situations that are typical of student life: having multiple due dates, work commitments etc. Tutorial instructors (TA's) will not be able to provide extension on their own and must receive permission from the course instructor first.
3. Method of submission: You are to submit your assignment using D2L [help link]. Make sure that you [check the contents of your submitted files] (e.g., is the file okay or was it corrupted, is it the correct version etc.). It's your responsibility to do this! (Make sure that you submit your assignment with enough time before it comes due for you to do a check).
4. Identifying information: All assignments should include contact information (full name, student ID number and tutorial section) at the very top of your program in the class where the 'main()' method resides (starting execution point). (Note other documentation is also required for most assignments). Not necessary graded for mini-assignments but still a good idea to do this.
5. Collaboration: Assignments must reflect individual work; group work is not allowed in this class nor can you copy the work of others.  For more detailed information as to what constitutes academic misconduct (i.e., cheating) for this course please read the following [link].
6. Execution: programs must run on the computer science network running Python 3.x. If you write you code in the lab and work remotely using a remote login program such as Putty or SSH then you should be okay (assuming you don't login to a non-Linux computer). If you choose to install Python on your own computer then it is your responsibility to ensure that your program will run properly here. If it's not running in the lab computers using Python 3.x then it won't be awarded credit. It's not recommended that you use an IDE for writing your programs but if you use one then make sure that you submit your program in the form of text ".py" file or files.
7. Use of pre-created Python libraries: unless otherwise told you are to write the code yourself and not use any pre-created functions. For this assignment the usual acceptable functions include: print(), input() and the 'conversion' functions such as int(), float(), str(). Look at the particular assignment description for a list of other classes that you are allowed to use and still get credit in an assignment submission.