Back to the faculty page for James Tam  

Return to the course web page


CPSC 233: Full Assignment 4

Index to the major sections

Due at 4 PM. For assignment due dates see the main grid on the course webpage.

New Concepts to be applied for the assignment

  • Hierarchies (which includes many sub-topics such as inheritance, method overriding etc.)

You may to review the material of past lectures for this assignment: "Advanced Java" (especially arrays of references to objects) or even the basics of Object-Orientation (references to objects vs. objects) if your grasp of that material is not strong. Relevant tutorial material to review would include the tutorials from Feb 7 - 13 and Feb 21 - 27 (deep vs. shallow copies).

Note: it is not sufficient to just implement a working program and expect full credit. Even if your program is fully working and the design is not as specified in this document (E.g. your program implements static methods other than the main method or only a single class is used) then your marks will suffer greatly. (Your raw grade point is quartered if you do these two things i.e. an 'A' becomes a 'D' grade). There are other crucial design requirements but I used two extreme examples to make a point. You are to learn and practice good Object-Oriented principles in CPSC 233 and you are expected to be able to apply these principles in higher level courses. Note: the prohibition on the use of static methods does not necessarily apply to static class constants (e.g. public static final double PI from class Math is an example of good style, the appropriate use of class constants.) These restrictions apply on to the code that you write and not prewritten code that you may or must for some assignments as they may represent an exception to these rules.

Brief description of the problem

The program will implement a text based version of Conway's biological simulation "The Game of Life" (and not the board game). The starting data from the file will be read in from a text file and the simulation will run on a turn by turn basis. The starting data consists of empty spaces or stars to be read into an array of references to 'Critters'. Spaces in the input file will result in a critter whose appearance is 'EMPTY' (a class constant representing a space in the definition of class Critter) while a star will result in a critter whose appearance is the 'DEFAULT_APPEARANCE' (a class constant representing a star in the definition of class Critter). Each turn the rules of births and deaths will change the pattern. Important: births and deaths must occur simultaneously otherwise all your simulation results will be incorrect (and you won't be awarded credit for the respective features).

The sole determinant if a birth or death occurs in a particular location is the number of critters in the neighboring squares. (There is a maximum of 8 neighbors to check for the inner-most locations, fewer for the ones at the edges and fewer still for the corners). [Example of what constitutes a neighboring cell]

Original rules for births and deaths for the Game of life.

Deaths: Cells that contain a critter will have the critter die under the following conditions:

Births: Cells that are empty will have new critter born into it if it has exactly 3 neighbors (otherwise it remains empty).  [Example of a critter birth]

Links to online web-based executable versions of the Game of Life:

Starting code (for the convenience of the marker please submit into D2L all the classes even if you don't modify them)

You must use the code for the classes. You cannot modify any of the code in the file I/O classes: FileContainer.java, FileInitialization.java. The file I/O code will return a reference to an array of references to Critter objects which can then be passed as a parameter to a constructor for a Biosphere object.

Example usage of the file I/O code:

Biosphere regular = new Biosphere(FileInitialization.read());

You must use all 7 starting classes in your solution. The amount that you can modify the starting code in these classes will vary (see the documentation for each class). You can also write other classes as needed (e.g. class Debug). Container classes such as ArrayList and Vector can be used but are not mandatory for this assignment.

Description of the other required starting classes

Critter

Tracks information associated with the basic life form inhabiting the simulated world. Although it currently has just one attribute, defining this class allows it's attributes and methods to be extended in child classes such as Taminator. (In other semesters students also were required to implement an additional 'FertileCritter' as well as a Taminator).

Taminator

The child class of class Critter The Taminator is not used in the critter count for births and deaths. Nor will a new Taminator ever be born nor will a Taminator ever die. There is at most only one Taminator. The only source of the Taminator comes from the starting input file. This class must implement in its methods two behaviours:

  • 'Tamination' of critters: Determining the location (row, column) of its neighboring critters. Checking if that information is valid given the current location of the Taminator and how that information is used (e.g. neighbors getting removed from the array) may be the responsibility of other classes (use the good Object-Oriented design principles from the Introduction to Object-Orientation lectures as a guide).
  • Unpredictable teleportation: Determining the random location (integer row & column values) that the Taminator will appear next. Again: checking the validity of that information and any necessary changes in the state of the container array may be the responsibility of another class.

Biosphere

Responsible for tracking the current state of the simulated world via the attribute which is a container array: Critter [][] current. To be awarded credit the container array that tracks the positions (critters vs. empty spaces) must be of type 'Critter' (the way it is defined in the Biosphere class). The array cannot be of type String nor can it be an array of 'char'. In programs that have implemented the Taminator critter: one array element may contain a reference to a Taminator object (depending upon whether a 'T' appears in the input file). Although most of your program code will likely be included within methods of this class take care that code and attributes that logically belong to another class are not included here.

ProsperousBiosphere

A child of class Biosphere, it has different rules for births and deaths vs. the rules for a regular biosphere.

GameOfLife

This is the Driver for the program. In the starting code it: reads the information from file, creates a biosphere object and runs a single turn (which then displays the state of the biosphere read in from file). Like most driver classes there likely won't be much code defined here (keep in mind you shouldn't define new methods in this class, whether they are static or not, nor should the existing method exceed length requirements).

Sample input files (you don't need to submit the input files)1

These are the files to cover the cases specified in the assignment features you are to implement. However, your birth/death rules for the regular and prosperous biosphere (as well as the 'Taminator' implementation) must work for any 10x10 input file that contains any of the following characters, spaces, stars and up to one 'T'. (This doesn't contradict the 'X' marks you get for handling each of the input files show under the next heading, you have to have the rules correctly implemented to get full marks (except for the empty file case) and you can't, say, hard code the results to handle just one specific file and expect credit. [Link to input files]

1 That's because my File I/O classes will prompt the user for the location of the starting pattern your marker can simply enter the path to where the input files reside on that person's computer.

Specific program features to implement for the assignment (style and documentation will also play a role in determining your grade).

  1. Uses the File I/O classes to read the starting positions from file and displays the 3 states of the world side by side (information to display from left to right):
    1. The previous state before any birth/death rules and before the effect of the Taminator have been applied (first turn previous state = pattern from the file)
    2. The affect of births and deaths applied on the previous state i.e. state (a) above.   
    3. At the Taminator's current location in (b) critters are 'taminated' (locations switch their appearance from a star to s space) and the taminator teleports to a new random location.

    The cycle then repeats for the next turn: Turn  2's (a) = Turn 1's (c). Turn 2's (b) is applied on Turn 2's (a) and Turn 2's (c) is applied on Turn 2's (b). The  Links showing a sample run with the '5complex.txt' file as input (regular Biosphere, no Taminator): [Turn 1] [Turn 2/3+].  Links showing a sample run with the '5complexT.txt' file as input (regular Biosphere, has a Taminator in the starting positions): [Turn 1] [Turn 2/3+].

    In order to get credit for this feature and any of the other features below your program must clearly display and label the three states (a - c) all on one line with headings that clearly and unambiguously label each of the three states. [Image showing each state with the 3 required headings].

    What should displayed if you haven't fully implemented the program features for births/deaths and the taminator:

    1. If births and deaths haven't been implemented but the Taminator effects have been then the middle state (b) is the same as the left most state (a). The right most state (c) will show the effects of the Taminator.
    2. If births and deaths have been implemented then the middle state (b) will show births and deaths applied to the left most state (a). The right most state (c) will be the same as the state shown in the middle.
    3. If the births, deaths and Taminator have not been implemented then all three states (a-c) will be identical.
  2. Displays 3 states all on one row but with bounding lines (above, below, left, right of each element of all 3 states).
  3. (Previous feature must be correctly working to get credit) Displays 3 states all on one row but as well as bounding lines the display labels the columns and rows of each of the 3 states. (The numbers must align with the correct row and column). [Required appearance]
  4. Program runs the simulation until the user enters 'q' or 'Q' to quit the program. Each turn the program will display the 3 states.  A full version of the program will apply the birch/death rules as well as run the Taminator. This feature must be correctly and completely implemented in order to get credit for any of the features that follow.
  5. Can read in the information from the file '1empty.txt'. To get credit for this case: No Critters should ever appear in the display of the world. (Birth/death rules and the features of the Taminator do not have to be implemented but a critter should never appear however long the program is run).
  6. Can read in the information from the file '2one_critter.txt'. To get credit for this case: The first turn will show the critter in the 'Previous' state (a). The critter will be gone in the "Births & Deaths" state (b) as well as the Taminator state (c). No critter will ever appear in any subsequent turns.
  7. Can read in the information from the file '3one_birth.txt'. To get credit for this case: The first turn will show the 3 critters in the 'Previous' state (a). Those 3 critters will be gone but a new one will be appear in the "Births & Deaths" state (b) as well as the 'Taminator' stat (c). During the next  turn the critter will appear in the 'Previous' state but it will be gone in the two other states. After that the 3 states are empty.
  8. Can read in the information from the file '4edge_cases.txt'. To get credit for this case: your program properly handles the cases when critters lie along the edges and corners of the biosphere.
  9. Can read in the information from the file '5complex.txt'. To get credit for this case: the rules of births and deaths are correctly applied. With rules of the regular biosphere (original Conway Game of Life rules) the pattern of critters will eventually reach a stable pattern. 
  10. Implements a Taminator Critter (a child of class Critter). To get credit for implementing a Taminator your program must be able to read the starting positions from any of the required input files with have a 'T' included in the data (especially the 'TaminatorT.txt' file). The occurrence of this character will result in a Taminator object being instantiated in the corresponding array location and the Taminator will correctly exhibit the behaviours shown below. The Taminator is not counted in the birth and death rules for regular critters. As well a Taminator never die or spawn new critters (neither Tamintor nor regular critters). There will be at most one Taminator read in from file.

    Appearance is a 'T' rather than a 'C' but it includes two unique behaviours that must be implemented within methods of the Taminator class and not other classes:
     

    1. Taminate all neighboring Critters. Up to 8 neighboring squares that currently contain critters will be changed to an empty state. The actual removal of the
      neighbors from an array can occur in the methods of another class (according to the principles of good Object-Oriented design) but the determination of the neighboring coordinates of the neighbors must be done by the Taminator. That's because a Taminator object can potentially exist independent of the Biosphere or even the Game of Life simulation. E.g. A Taminator object can theoretically appear in another program in the "Game of fun" simulation and it lives inside a desert simulation, the instance of the Taminate object must still have the ability to determine the coordinates of the neighbors.
    2. After taminating neighbors the Taminator will randomly teleport to another location within the biosphere. The Taminator will randomly determine that (row/column) location although another class can then be the one that changes the state of the container array (it actually 'moves' the Taminator). A Taminator will only teleport into empty squares.

      As mentioned the effect of Taminator's abilities will occur on state after births and deaths have occurred. First the Taminator will taminate all its neighbors and after this it will teleport to its new location (cannot be the same location). The rightmost state (c) that's displayed for the world 'Taminator' should show the state of the world after these two abilities have been applied. [Example]
  11. The starting positions read in from the file can be used to create a 'ProsperousBiosphere' instead of a regular Biosphere object. A prosperous biosphere will have different rules for births and deaths.
    • Deaths occur if there is fewer than one neighbor or more than four neighbors.
    • Births occur if there is exactly 4 neighbors (allowing for 4 or 5 neighbors to produce a birth as stated previously would provide an apparent overlap with the 'births' rule)..

    If a ProsperousBiosphere is implemented then your program must prompt the user to specify the biosphere type to read the file into (class  'Biosphere' or 'ProsperousBiosphere' before reading the positions from the text file). A 'P' or a 'p' (regardless of the input file chosen by the user) will always apply the rules of the ProsperousBiosphere (although some of the files such as the empty one won't show a noticeable difference from the regular biosphere). An 'R' or an 'r' will apply the rules of the regular biosphere. Until one of these 4 values has been entered will result a repeat of the prompt until a valid value has been entered. Any of the input files should allow your program to apply the rules of either a  regular or prosperous biosphere. However, the two files you can especially focus on for your testing the prosperous biosphere include 'prosperous.txt' and the 'tamintor.txt' file.

A recap: if you implement all of the above features then your program should be written that it can automatically include a Taminator critter if a 'T' appears in the starting file and it should include the required behaviours of the Taminator. If when the program first runs the user opts to run the alternate rules then the program will create a ProsperousBiosphere and while the program runs it will thereafter apply the rules for this type of biosphere rather than a regular biosphere. If on the other hand the user opts to run the rules of a regular biosphere then the program will thereafter apply the regular rules of births and deaths while the program runs.

Implementing a debug mode (with a static debugging flag or flags) is not mandatory but it is highly recommended (even students who do not find the assignment features challenging may make silly mistakes and implementing a debug mode can be very useful for finding and fixing logic errors). While you can just include debugging output statements without a debug mode class do not have debugging messages automatically appear in output of the program you submit for grading. (Consider the submitted version a program that you are delivering to a client, debugging messages appearing in that output by default is not appropriate nor is it acceptable). That means you will have to: comment out the messages, delete them or implement a debug mode (the latter to control when the messages appear which by default should not appear).

Marking:E

  • If you have questions about your marking then the first person to talk to is your marker and that will be the person who teaches the tutorial in which you are officially registered. [Tutorial information] If you still have questions after this first step then feel free to contact your course instructor, just let me know that you talked to your TA first. Please do not come to the course instructor without taking the time to consult your TA first.
  • TAs will download this sheet and each student will get detailed feedback on this sheet (to be uploaded in the D2L Dropbox) about how their grade point was derived: [Marking spreadsheet].
  • Marking feedback. You will get a detailed marking sheet for each assignment that contains your TA's feedback. This marking sheet is uploaded in your D2L Dropbox. If you don't know how to access files that have been uploaded into D2L then follow this link [viewing uploaded files in the D2L Dropbox] 

Important points to keep in mind for all assignments:

  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 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. You should mitigate the occurrence of technical problems by submitting your work early and often and early in D2L as well as performing regular backups. Do not expect to get an extension if something like this has occurred. If you request an extension from me let me know the name of your tutorial instructor and the tutorial number because the markers won't accept late submissions without directly getting an email from me.
  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. What to submit: Java programs should be submitted in the form of .java source code. Do not submit .class files.
  5. 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 of the full assignments).
  6. Collaboration: Assignments must reflect individual work; group work is not allowed in this class nor can you copy the work of others. Students should not see each other's graded programs (don't post it, don't email it out, don't show it in a screen share). For more detailed information as to what constitutes academic misconduct (i.e., cheating) for this course please read the following [link].
  7. Execution: programs must run on the computer science network (if applicable during that particular semester) running the latest version of Java (this is what applies for the distance learning version of the course). If there libraries or classes external to what's included in Java then you must include clear and complete instructions for your marker as to exactly what needs to be done to compile and run your submission otherwise you may be awarded no credit. Also you should be wary of using external libraries rather than writing the code yourself because you may not be awarded credit for particular features if you didn't write the code yourself. 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 Java on your own computer then it is your responsibility to ensure that your program will run properly here. It's up to you if you wish use the graphical program builder to write/run your programs but if you do you submit your program in the form of text ".java" file or files.
  8. Use of pre-created  libraries: unless otherwise told you are to write the code yourself and not use any pre-created classes. For this assignment the usual acceptable functions include code in the Scanner class and methods for displaying output such as: printf(), print(), println(). Check the specific assignment requirements for other classes that you may be allowed to use.
  9. Late submissions Make sure you give yourself enough time to complete the submission process so you don't get cut off by D2L's deadline (when you get a zero). Unlike the mini-assignments you may be able to submit your work late and be awarded some credit.

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

Submission not graded.

Submitting your work:

  • The document must be electronically submitted using D2L.
  • It's recommended that you submit your work early and often to avoid problems such as forgetting the due date or problems with your computer (hardware failures, malicious programs etc.). Reminder: you will not be granted special considerations such as extensions in these cases!

D2L configuration for this course

  • Multiple submissions are allowed for this assignment (all versions are kept in D2L): 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. However only the latest version of all the files is what 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. The space savings in D2L is not worth the extra time required by the marker to process each submission.
  • 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).