You are to implement a text-based biological simulation: Conway's "Game of
Life". Given a starting pattern of life forms in the simulation ('biosphere')
the program will update the pattern
according to new births and deaths that occur during that time period
(turn). Each location in a biosphere (element in a 2D list) either contains: an empty space
or a life form ("critter"). As each turn passes in the simulation a
new critter may be born into an empty square or an existing critter may die off
in an occupied location. To get any credit for your
submission your program must be able to
initialize the two lists to any of the
6 starting patterns and it must
display the before/afterstate of the world with the same appearance as the code
provided in the display function.
One requirement in order to get any credit for this assignment your program must,
at a minimum,
use the six starting patterns:
oneEmpty(),
twoSingleCritter(),
threeSingleBirth(),
fourthSimpleBirth(),fifthCreateListEdgeCases()
and
sixthComplexCases().
The more of the initial six cases that your program can correctly
process, the higher will be your grade. Each of the functions will produce a
10x10 list. Your program does not have to handle lists of other sizes. When it
first runs your program must allow
the user to choose via a menu which of the 6 starting patterns will be used for
the simulation. The choice will only appear once at the beginning.
If you wish you can write additional functions with different initial patterns.
Although additional test cases won't increase your grade it may reduce the
likelihood of bugs in your program.
Important grading point: Your program functionality marks will only be awarded
if your program produces the same results as these outputs. For example,
function "oneEmpty()"
starts out empty and should therefore never contain a Critter in the pattern.
Function "sixthComplexCases()"
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. In addition you need
to correctly and comprehensively document which starting patterns that your
program will handle. Both of these requirements (producing the same
patterns in your output and documenting which cases that your program correctly
handles are 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 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 code in the starting program is extremely simple
and just initializes the references to the lists ('newWorld'
and 'oldWorld') to an
empty world and displays the result for the latter two lists.
The program that you will submit will not do things
this way.
The old world is the state
of the biosphere before the
birth/death rules have been applied during that turn while the new world is
the state after those rules were applied. The starting code does apply
those rules, you need to write the code yourself to get credit.
As mentioned 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 your own function yourself that produces the same output.
Even the grid is required because it makes
the display of world easier to read and interpret for both you and the marker.
Running the simulation
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 advance the simulation by another turn, 'q' or 'Q' to end
the simulation. A hidden feature (not displayed as an option), the [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 adjacent/neighboring
squares. Each square will have from 3 - 8 neighboring squares (inner squares
have 8, outer squares can have 3 at the 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.
|
|
|
|
| Bottom right corner |
|
An inner square |
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. So as
mentioned the 'old' world contains the state of the biosphere for that turn
before the rules have been applied and the 'new' world will track the after
state.
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:
debugOn = False
When the flag is set to 'True' debugging messages will appear, otherwise they
will not:
if(debugOn == True):
print("<<<Some
debugging message>>>")
This global variable for the debugging flag is the sole
exception on the prohibition on the use of global variables in your program. No
penalty will be applied for using this debugging flag but the usual penalty will be applied for other global
variables. Global constants should be used
when appropriate. Penalties for lack of constants may be applied when
it's appropriate to define one and one hasn't been defined for that program.
The exact content of the debugging messages is left to your
discretion. 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
greater details: the neighbor count as well as births and deaths for each
square 2)
More sparse annoucements specifying
only where births and
deaths have occurred.
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.
In addition to grading on whether the above functionality was correctly
implemented TAs will also look at documentation and style.
- Header documentation (very top in the form of
Python documentation):
- Contact information (your name, student
identification number and tutorial number).
- What does the program do.
- What are its limitations e.g. the program
doesn't perform type checking (crashes when non-numeric information is
entered).
- The version number of the program (dates are
acceptable).
- Inline documentation: list the features of each
room that were implemented in a particular function e.g. living room:
display menu options continuously, can pick up the string
- Naming conventions: You should employ good naming
conventions for identifiers (variables, constants, function names, program
file names).
- Named constants should be used as appropriate.
- The program code should have appropriate white
space (specified in the "Intro to programming lecture') and alignment
(specified throughout the lecture notes).
-
Code is self documenting e.g. Clear expressions (e.g. mathematical,
Boolean).
-
Of course if a student implements an extreme case
of inefficient code (e.g. multiple loops or branches are used when one will
do) then penalties may be applied but this is generally rare.
- Your program should follow the 5 rules of thumb
for designing user friendly software (Jakob
Nielsen's 10 usability heuristics) which were
included at the notes on 'Repetition' e.g. good error handling (such as
prompts to the user to enter the required information clearly indicate what
is required, good error messages should be provided for erroneous input)
minimizing the user's memory load, being consistent, providing clearly
marked exit & providing feedback as appropriate.
- Function specific:
Functions are one screen in length (normal screen resolution say ~30 lines
max of code (excludes whitespace and documentation).
- Function specific: Functions implement one well
defined task (e.g. processLivingRoomCommands() vs. processlivingRoomRunIntroductionRunConclusion())
- Function specific: Code in one function is not
duplicated in another function (not in the notes but this is just common
sense that you don't write two functions where there's overlapping code -
the overlap should likely be taken out of both functions and moved to
another separate function). In this assignment there may appear to be
some overlap (e.g. each room displays a menu of options but the specific
options displayed will not be identical).
- Function specific: No global variables (unless you
have a compelling reason that you have justified to the course instructor or
something explicitly allowed such as a debugging flag).
Your program should consist of at least 5 functions
including the starting function.
Because the new learning concepts to be applied are
related to functions and tools/topics related functions your
grade will be severely impacted if you bypass the use of these
concepts in this assignment and all other subsequent assignments (or projects if
required during the semester)..
Submitting your work:
- The document must be electronically submitted
using D2L. This
applies to on-time or late submissions.
- D2L configuration for this course
- Multiple submissions are allowed for this assignment: You can (and
really should) submit work as many times as you wish before the due
date. Due dates are strict, only what is in D2L by the deadline is what
will be marked. Other methods of verifying that your work was completed
on time (e.g. checking timestamps, emailed files etc.) will NOT be
accepted.
- Multiple files can be submitted for this assignment (e.g.
A1_version1_May7, A1_version2_May8 etc.) Consequently all versions of
your submissions will be retained. However only the latest versions of
each individual document (for assignments that require multiple files to
be submitted) are the ones that will be marked, everything else will be
ignored (because it is not fair to your marker to sort through multiple
versions of your files).
- Do not use compression utilities (such as zip) or
archiving utilities (such as tar) otherwise your submission may not be
marked.
- 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 your submit your assignment with enough time before it
comes due for you to do a check)
Marking
-
All the projects will be marked by
one Teaching
Assistant (ashratuzzavin.asha@ucalgary.ca). 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 the marker, then you can talk to your course
(lecture) instructor.
-
As well as being marked on whether "your program
works" you will also be marked on non-functional requirements such as style
and documentation. Consequently this assignment will include a separate [marking
checklist]. 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:
-
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.
-
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).
-
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).
-
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].
-
Execution: programs must run on the computer
science network (if applicable during that particular semester) 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 won't run using Python 3.x then it won't be
awarded credit. It's up to you if you wish use the graphical program
builder IDLE to write/run your programs but if you do you submit your
program in the form of text ".py"
file or files.
-
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(),
len()
as well as the open(), append(), readline()
methods
-
Extensions may
be granted for reasonable cases by the course instructor with the receipt of
the appropriate documentation (e.g., a sworn declaration with a commissioner
of oaths). 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 (TAs) will not be able
to provide extension on their own and must receive permission from the
course instructor first.
-
Questions about marking: Your Teaching
Assistants will be marking the assignments so I will first direct your
questions to them regarding the marking.
-
Late submissions (no extension granted):
|
Submission received: |
On time |
Hours late : >0 and <=24 |
Hours
late: >24
and <=48 |
Hours
late: >48
and <=72 |
Hours
late: >72
and <=96 |
Hours
late: >96 |
|
Penalty: |
None |
-1
GPA |
-2
GPA |
-3
GPA |
-4
GPA |
No |