A racing simulation with two separate driving tracks: arctic and desert - SOLUTION

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.

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) while 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 '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. 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).

Ordering of events during a turn: 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 heatwave 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 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.
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 show the series of method calls, 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. The exact content of the debugging messages is left to your discretion. 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() "); } Driver: The starting execution point of the program: it creates a game controller and sends it a message to start the simulation. 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 ["GameInterface class" covered during the week of Jan 31 - Feb 6]. This class will also manage the 'rules' of the simulation e.g., has the simulation ended, which car has 'won' etc
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. 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 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.

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.
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.
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.
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 A3 directory [/home/219/assignments/assignment3/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. Sample execution You can see sample output files in the A3 directory (/home/219/assignments/assignment3/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 or png.