Back to the faculty page for James Tam

Return to the course web page

 

CPSC 233: Full Assignment 3

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

New Concepts to be applied for the assignment

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.

Overview

This program consists of an overhead view of a text-based strategy combat simulator of orcs vs. elves. Initial positions of the armies will be read from a starting text file (using the prewritten Java classes that have provided). To make it easier to test specific cases the user will specify the name of the input file. After the starting positions have been read into the program it will run on a turn-by-turn basis. Each turn the state of the world will be displayed. After displaying the state the orcs and elves will move and then attack the members of the opposing forces. Movement will stop for an individual entity when: 1) the edge of the 'world' is reached 2) an obstacle is encountered (another entity) 3) there is an opposing entity an adjacent square (orcs and elves are in opposition). You need some sensible rules for handling special cases that arise during movement (e.g. don't move an entity more than once during a turn and multiple entities should not move into the same location during a turn).1 Casualties who have fallen unconscious (hit points reduced to zero or less) after combat will be removed at the end of the turn. The changes caused by movement and combat will be displayed during the following turn. Before moving onto the next turn the simulation pauses and waits until the user hits enter before moving onto the next turn. The simulation repeats the cycle for each turn until one of the end game conditions has occurred.

1 One approach: The entities at the top move and attack before the ones below them, entities to the left move and attack before those on the right.

Classes required:

You must use these starting classes. Except for the two File I/O classes you can modify these classes by adding new code but you cannot delete or otherwise modify existing code. You cannot make any modifications to the two File I/O classes. You must follow these requirements in order to get credit for this assignment.

Usage format:

  FileInitialization.read();

Example usage (because the method is static no instance should be created)

  Entity [][] aWorldFileInitialization.read(); // Array 'aWorld' is now initialized with the positions specified in the text file.

if (GameStatus.debugModeOn == True)
    System.out.println("<<< Debugging message >>>");

The following class is only nominally implemented. Likely much of the program will be written here. But make sure that you don't include all your code here! Attributes and methods must be logical to a class.

The next class can be useful for tracking locations in the 2D array. You can use it as you desire. However, your solution must still follow good programming conventions (e.g. clear self documenting code). If you don't use this class take care that your alternative for tracking locations is still an approach that follows good design principles.

If you wish you can implement other classes but again your design must be logical and follow the good design principles that you have been taught.

Starting data files:

While you can change the contents of the starting file for testing make sure that it always remains 10 characters by 10 characters in size. Also make sure 'empty' locations are still filled with spaces! Tip: you can see spaces in your editor if you open a .txt file in Word and turn on formatting marks. Be aware that your markers may produce different versions of input files for testing purposes but all test files will conform to the basic requirements (10x10, valid characters will consist only of: 'O', 'E' or spaces). Your program should be able to properly handle anything that they come up with that is within these parameters.

The position of a character in the text file will correspond to the position of an array of "Entity" in the simulated world. Each 'O' in the text file becomes an orcish fighter while the 'E' becomes an elven warrior. Both are instances of the Entity class each with a different values for attributes such as: hit points, appearance and damage. Empty spaces will become null elements in the array.
Link to some sample data files.

Program features (Features marked 'Debug must work first' require that debugging mode can be toggled and will require specific debugging messages to appear in order to be awarded credit for that feature. Output must be clear, correct and reasonably formatted).

  1. Program runs endlessly until an end game condition occurs (loop can be endless for credit for this feature, end game conditions are separate credits) with a prompt to hit enter at end of each turn.

  2. The user can toggle debugging mode along with appropriate message as the debugging state changes. The option to toggle will occur at the end of each turn. The user can type in 'd' or 'D' and enter to toggle debug mode after which the simulation proceeds to the next turn. Typing anything else (along with enter) will simply advance to the next turn.

  3. Displays the array with bounding lines around each element: above, below, left and right.

  4. (Debug must work first): Orcs move diagonally downward (to the right and down a row). Debugging messages must show the previous (row/column) and the destination (row/column) before and after the move for each entity.

  5. (Debug must work first): Elves move diagonally upward (to the left and up a row). Debugging messages must show the previous (row/column) and the destination (row/column) before and after the move for each entity.

  6. Boundary checking prevents orcs and elves from moving past the bounds of the array.

  7. Elves and orcs will only move onto empty squares.

  8. (Debug must work first): Entities only move if they are not adjacent to an enemy. Debugging messages must show the (row/column) of the entity that is constrained from moving and the (row/column) of the adjacent enemy opponent.

  9. (Debug must work first): Entities can attack members (clarification: entities only attack once per turn) of the opposing side (no marks if same side attacked). Debugging messages must show information about the entity doing the attacking: row, column and its appearance. Also the debugging messages must show information about the entity being attacked: row, column, appearance, its original hit points and the hit points after its been attacked. (Clarification: Entities stop moving when they are adjacent to an enemy because they are no in range to attack each other. An entity will attack one adjacent enemy).

  10. Unconscious entities (with zero or fewer hit points) removed at the end of the turn. (Clarification: unconscious entities don't get to attack back).

  11. Can determine when the orcs have won (there are no elves remaining but there's at least one orc), game ends with appropriate status message.

  12. Can determine when the elves have won (there are no orcs remaining but there's at least one elf), game ends with appropriate status message.

  13. Can determine when there is draw (no entities left), game ends with appropriate status message.

  14. (Debug must work first): Can determine when there is a ceasefire (no attacks have occurred for 10 successive turns), game ends with appropriate status message. The debugging message must display (and clearly label) the number of turns that have passed since an attack has occurred.

  15. Extra bonus features. You can be awarded a bonus mark (Bonus is where GPA > 4.0) for this assignment if you implement all of the above features correctly and completely as well as meeting style and documentation requirements (GPA = 4.3). This is highest grade that you can be awarded for this assignment. For students who want an additional challenge or an alternative way of earning your marks (i.e. completing the multi-media features instead of one of the features above) there are two additional features listed below. Because these last two features are an extra bonus you will need to learn how to use the necessary Java classes on your own. (This is an exception to the prohibition on using prewritten Java classes). However, if you use Java classes other than the ones provided by Oracle then you must do the following:

Marking:

Important 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 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!