Course web page: Introduction to Computer Science for non-majors II James Tam Return to the course web page

## CPSC 219: Full Assignment 4

Due Friday Mar 31 at 4 PM.

### New concepts to be applied for this assignment:

• Inheritance, polymorphism/method overriding, casting within an Object-Oriented Hierarchy.

### Problem Statement:

Create a racing simulation with two separate driving tracks: arctic and desert. For this version of the program the arctic track contains an SUV (Sport Utility Vehicle) and the desert track contains a sports car. Each car will try to reach the end of its respective track without running out of fuel and prior to the other car (see Figure 1). If either or both cars reach the end of the track then the simulation ends: draw (if both reach it during the same turn), win (for the car that reached it first), and loss (for the car that didn't reach it first). If one car runs out of fuel then the simulation continues until: both cars run out fuel (tie) or the other car reaches the end (win for that car). The simulation is also a 'draw' if the user quits the program early.

 Figure 1: Race tracks with their respective vehicles

There is a random chance of a weather event occurring in each track. The arctic track can have a blizzard that prevents non-AWD (All Wheel Drive) movement (but doesn't stop the expenditure of fuel). The desert track can be hit with a heat wave that can cause sports cars to overheat and double the fuel consumption rate (movement distance is unchanged). Finally the simulation allows for a hidden 'cheat' option - see Figure 2 - for testing purposes: debugging messages can be toggled on/off, the fuel level of either car can be manually set, a car can be manually moved to any location within its current track, a weather event can be invoked in the other track (meant to hinder the other car so the cheat option shouldn't work on one's own track. Because the weather event for a track is determined immediately after the user's choice for that track, the user's option for causing a weather event in their own track will be ignored (the effect of randomly generating a weather event can 'override' the cheat).  Look at the section "Ordering of events during a turn" and you should see how trying to sabotage your own track will be cancelled out by the random occurrence of weather events).

 Figure 2: Cheat options available in the simulation

### Overall program description:

 Pre-created classes that MUST be used in your program: The code in these classes CANNOT be modified (except the Driver in order to call a starting method of the GameController instead of the display method of the Track). Classes that you must create and implement yourself Car ArcticTrack (child of Track) Debug DesertTrack (child of Track) Driver or equivalent (contains 'main()') GameController Track Sports (child of Car) SUV (child of Car)

### Ordering of events during a turn (do not deviate from this sequence of sub-turns):

1.      The two tracks are displayed

2.      SUV movement occurs (display menu, get input, move car if applicable, selecting the quit option will exit directly out of the game with an appropriate status message).

3.      The program determines if a blizzard occurs in the arctic track (affects next turn). Even if the SUV player tries to invoke a blizzard the random generation at this sub-turn overrides the choice.

4.      Sports car movement occurs (display menu, get input, move car if applicable, selecting the quit option will exit directly out of the game with an appropriate status message).

5.      The program determines if a heat wave occurs in the desert track (affects next turn). Even if the Sports car player tries to invoke a heat wave, the random generation at this sub-turn overrides the choice.

6.      Determine the outcome of the simulation (if a win/loss/tie occurred)

Note: invoking a 'cheat' option will use up the respective user's turn e.g., the SUV user who uses the cheat to sabotage the sports car user will not have an option to move his/her car that turn.

### Brief description of the pre-created classes

Car:

Each car is represented by a single character. The basic car is shown as a 'c' (the child classes have an appearance of 'V' for the SUV and 'P' for the Sports car). Individual cars have a fixed amount of fuel (40) that is consumed at a fixed consumption rate (2), allowing it to move a standard distance (2). If the fuel has been totally expended (zero or less) then the car can no longer move. (The movement menu for that car should no longer be displayed). All cars (including child classes) should display its current state during a turn: current fuel, consumption rate and distance traveled for that turn (see Figure 3). If the car is driving under extraordinary circumstances e.g., an SUV driving in non-AWD mode and consuming fuel without moving during a blizzard, then the actual movement and actual fuel consumption information for that turn should be displayed.

 Figure 3: Menu options, fuel consumption and distance traveled.

Debug:

The sole purpose of this class is to determine if the program is operating in debugging mode (it is the exception on the prohibition on using static variables, the only other exception is if you use different types of debugging flags for specific types of situations e.g., one to display a debugging message as a method is called, one for SUV movement, one for the movement of the sports car etc.). Debugging messages should inform the user about the state of the program. In terms of credit for the assignemnt: the exact content of the debugging messages is left to your discretion. Because however the flag is used for testing, in actual practice tools like this should be employed throughout the program.

If the program is debug mode (the flag is set to 'true') the messages will appear, otherwise they will not. Example:

main (String args[]) {

if (Debug.on == true)

System.out.println("<<< Driver.main() >>> "); // Shows series of method calls to the user

}

Driver (no pun intended):

The starting execution point of the program: it creates a game controller and sends it a message to start the simulation.

Track:

The parent race track class. All tracks will contain a fixed size array of 'Car' objects. The array will be empty (null) except for the one element that refers to a car. During the simulation the car will move along the array to simulate the movement of a car along a track. Some responsibilities of the class include: displaying the state of the track, putting a car at a particular location on the track (can be used in cheat mode or by the child classes to place the sports car and SUV at the start of their respective tracks and 'moving' the car), determining if a car has reached the end of the track.

### Brief description of the classes you must create and implement

GameController:

This class will act as the user interface for the program (responsible for input and output: displaying the appropriate menu, getting user input, validating input etc.). To a large extent it will then be directly or indirectly responsible for carrying out those actions. (Directly when the required code is included in a method of this class; indirectly when it calls the method of another class). Be careful that you don't break encapsulation by putting code in this class that should belong to another class! (The same applies to the other classes but the problem is most likely to occur with this class). Most likely this class will be the largest one for this program. There will be numerous variable and constant attributes for this class. At a minimum it should contain two attributes: one for the arctic track and one for the desert track. Each track is separate, cars cannot move from one track to another. Also the track type determines the type of car that will drive there (there's never an SUV in the desert track and you should perish the thought of a sports car being forced into the arctic!) The program doesn't have to implement this as error checking, just make sure that you don't mix and match tracks/cars. There was at least one example of a user-interface classes providing during the term that you can refer to for this assignment, the  . This class will also manage the 'rules' of the simulation e.g., has the simulation ended, which car has 'won' etc. This class similar to the class with the same name covered by the TAs in tutorial which can be found at [this link] or in UNIX under /home/219/tutorials/jan29_feb4/userInterface

ArcticTrack:

A child of class of Track with the additional ability to generate a blizzard. A car traveling during a blizzard will be stuck (not move forward and just "spin its wheels") yet still expend fuel amounts appropriate to the type of car and driving mode (if applicable). The exception is an SUV traveling in AWD mode (see Figure 4). Each turn there's a 10% chance of a blizzard occurring, otherwise the driving conditions will be normal. Note: regardless of whether or not a blizzard hits the SUV will only travel 1 unit when AWD mode is invoked.

 Figure 4A: AWD mode still consumes fuel but allows for some movement during a blizzard (image combines current turn with next) Figure 4B: Normal driving is not successful when a blizzard hits the arctic track (image combines current turn with next)

DesertTrack:

A child of class of Track with the additional ability to generate a heat wave. A sports car traveling during a heat wave will overheat (see the description of the sports car class for the effect of overheating). Each turn there's a 10% chance of a heat wave occurring, otherwise temperature will be normal.

 Sports: ("light and fast": sports cars in action (viewer discretion advised)")

A sports car is a child of class Car that has a different appearance ('P') with a standard fuel consumption rate of 2 units but the ability to move 3 distance units. To keep the car lighter (and faster) the fuel tank capacity is only 30 units. Normally a sports car has an efficient cooling system but if there is a heat wave, a sports car will overheat and consume fuel at double the normal rate (move distance is unchanged) (refer to Figure 5). The car will remain overheated only so long as the heat wave lasts e.g., if there is a heat wave during the current turn but not the next then the car will only remain overheated for only one turn.

 Figure 5: A sports car overheating during a desert heat wave.

 SUV:  (big and heavy but with good rough weather and off road handling, aka the 'Canyonero' from the Simpsons)

A child of class Car that has a different appearance ('V') and different movement options: under normal driving mode the distance traveled is still the default rate of 2 but fuel consumption is 3 units, under AWD mode the car can still move when there is a blizzard albeit at a reduce speed (refer back to Figure 4).  The fuel tank is larger with a capacity of 50 units.

Program functionality: To  make it easier to test (and mark) your program, there will be cases where the appropriate cheat feature MUST be implemented before you get functionality marks (see the note "Getting credit for this feature requires that the cheat..."

• Displays an introduction to the program that describes the rules. It only displays these instructions right after the program is run. The exact content of the instructions are left to your discretion but it should be sufficient to instruct the user how to run the program.
• Displays an appropriate status message when the program ends e.g., "SUV reached the end first", "quitting before the simulation ended" etc.
• Displays the appropriate menu for the SUV and sports car movement.
• Gets user input for the SUV and sports car menu and repeats prompts until valid input is entered.
• Program runs until the user quits.
• Cheat menu can be invoked from either car menu. At the main menu the 'cheat' option is hidden, it's not displayed with the other options. However if the user selects the cheat option at the main menu then the cheat menu options should be displayed: Figure 6: Cheat option used to make the opposing car run out of fuel (it can also be inflicted on your own car as well).
• Gets user input for the cheat menu and repeats prompts until valid input entered.
• Each track is properly initialized and displayed at the appropriate time when the program runs.
• SUV can move and consume fuel as specified in the class description (non-AWD mode).
• Sports car can move and consume fuel as specified in the class description.
• Program checks and properly handles when cars run out of fuel: Getting credit for this feature requires that the cheat menu allows the user to manually set the fuel levels of both cars (see Figure 6).
• SUV AWD mode working (fuel consumption and movement).
• Arctic track can randomly generate and properly handle the effects of a blizzard on the SUV (regular mode): Getting credit for this feature requires that the cheat menu allows the user to invoke a blizzard in the arctic track.
• AWD mode working properly during a blizzard (requires the other two features (AWD driving and blizzard) to be implemented first.
• Desert track can randomly generate and properly handle the effects of a heat wave on the sports car: Getting credit for this feature requires that the cheat menu allows the user to invoke a heat wave on the desert track.
• Program can determine when one or both cars have reached the end: Getting credit for this feature requires that the cheat menu allows the user to manually move either car to any location in the respective track.
• The output of the program is graphical rather than using text (input can still be console/text based).
• Program employs sound effects to enhance game play.

Note that the last two features are a 'bonus', you can be potentially awarded full marks ('A'/4.0) if your program does not include sound and graphics. Adding these features can allow you to be awarded a grade point higher than 4.0. Consequently you will need look through the Java documentation on your own and determine how to insert these features into your program.

### Using pre-written Java code

You will need to use the code in class Random. Beyond that (and common sense operators and operations such as those for input/output and mathematical operators), unless you are told otherwise, you will need to write your own code and cannot use other pre-written Java classes or operators. Also mentioned it is required that you must use the starting code in the A4 directory [/home/219/assignments/assignment4/code] because one main point of the assignment is to learn how to extent some pre-created classes that a third party has written. Of course if you add multi-media features (sound and graphics) then you can use 'multi-media' classes (e.g., Rectangle) as well. Note however if you are just calling the pre-written methods of a pre-created class then you generally don't need to cite the source (e.g., when using class Random) to generate numbers. But if you find code online that goes beyond simple library calls then you have to credit the source of the code and give a clear citation. As usual unless you told otherwise, you will need to write your own code and cannot use other pre-written Java classes or operators (as usual and specified below: Point #7)

### Sample execution

You can see sample output files in the A4 directory (/home/219/assignments/assignment4/output).

### UML class diagram

Draw a UML class diagram for the following classes: Track, Arctic Track, DesertTrack and SUV. Make sure that all the attributes and method (plus permission levels and parameter information) are represented along with all class relationships (including multiplicity) for these 4 classes. You are not required to use any formal UML drawing tools such as [Rational Rose] or [Argo/UML]. Instead you can use any structured drawing program (even something like PowerPoint if you wish).  Diagrams can be hand drawn and scanned (if they are neat and legible). Acceptable file formats for the UML diagram include: gif, pdf, jpg, png, ppt or pptx.

### 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" you will also be marked on non-functional requirements such as style and documentation. Consequently this assignment will include a separate [marking checklist]

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. The latest versions of the files that you have submitted in D2L as of the due date is what will be marked.
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. 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. (Note: Forgetting to hand your assignment or a component of your assignment in does not constitute a sufficient reason for handing your assignment late).
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 and student ID number) at the very top of your program in the class where the 'main()' method resides. (Note other documentation is also required for most assignments).
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 Java 8.x. If you write you code in the lab and work remotely using a remote login program such as Putty or SSH then should already be using the correct version. If you choose to install Java on your own computer, then it is your responsibility to ensure that your program will run properly on the CPSC Linux computers. 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 ".java" file or files. If you only submit your byte code files (e.g. Driver.class) then you will not be awarded any credit.
7. : unless otherwise told you are to write the code yourself and not use any pre-created functions from the Java libraries. For this assignment the usual acceptable functions include: System.out.print(), System.out.println(), the methods of the Console class and for some assignments the methods of the Random class. 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.
8. Style conventions, programming decomposition: the marking points from the previous assignment also apply to this assignment. The one blanket exception is the use of a static debugging flag (or flags) if you choose to implement multiple flags.

D2L configuration:

• Multiple submissions are possible for each assignment: You can and should submit many times before the due date. D2L will simply overwrite previous submissions with newer ones.
• Important!  Multiple files can be submitted for each assignment. I am allowing you to submit multiple files for each assignment so you don't have to worry about archiving/compressing multiple files using a utility such as zip. 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 because marking is enough work as-is).