Introduction to multidisciplinary Computer Science II by James Tam Return to the course web page

CPSC 219: Assignment 5

New concepts to be applied for the assignment1

  1. Object-Oriented design
  2. Solving a moderately sized problem using Object-Oriented decomposition
  3. Using random number generators
  4. Relationships between classes and message passing

Introduction

Figure 1: Race simulation

Computer simulations are re-creation of a real-world scenario. Simulations are important for many reasons including (but not limited to) safety and cost. Also simulations may assist in decision making by allowing alternatives to be tested before a course of action is chosen. For this assignment you are to implement a simple race simulation (see Figure 1). There will be four competitors in the race. Three will be controlled by the computer program 'X', one is controlled by the user 'P'. Each runner will start at row 1 and try to make their way to row 50. When one or more racers reach the last row the simulation will end. If the runner controlled by the user is the only one to have reached row 50 then that race is won by the user. If any of the computer controlled runners reaches the final row before the user controlled runner then the race has been lost by the user. If the user controlled runner and at least one of the computer controlled runners have reached this row then the race is tied. Finally if the user quits the simulation prematurely then the race is neither won nor lost. Because of the length of the track only a part of it will be displayed at a time.

Figure 2: End of the race, at least one runner reached the last row.

Each runner can run at one of three speeds: jog, run, sprint. The latter two speeds results in move rows being traveled but they come at a risk. There is the possibility when traveling at higher speeds that the runner becomes winded and if so the runner must jog the next turn. When sprinting there is the additional chance that the runner will burn out and be forced to jog for the remainder of the race. The user controls the running speed of one runner. The other three have a even chance at travelling at one of the three possible speeds. There is a chance that each runner will be unable to maintain a running speed faster than a jog (the runner's discipline breaks). That means even if the user selects a faster running speed or the computer randomly determines that one of the other runners should move faster, the runner becomes distracted and slows to a jog. This slowing down is different from becoming winded. Becoming winded or burnt out is (for this simulation) determined by physical characteristics, the runner's body has given out. Breaking discipline means that the runner's mind has become distracted and even though the body is able to run at a faster speed, the runner has become distracted and does not maintain the faster pace (slows to a jog).

The running styles of the runners are determined by three attributes: strength, endurance and discipline. Strength may increase the sprint distance. Higher endurances reduces the chance that a runner will become winded or burn out. Having a higher discipline reduces the chance that the runner will become distracted. At the start of the simulation the user can determine their runner's strength's and weaknesses (increasing one attribute will take away from the others).

Finally this simulation will randomly determine the current weather for that day's race. The weather will consist of two properties: the wind speed and the temperature. Higher wind speeds can reduce the amount of distance traveled by runners (or even push slower runners back!) Higher temperatures increase the chance of getting winded or burnt out. One set the weather will remain the same for the duration of the simulation.

Required classes for this program

CommandProcessor: it's similar to the Menu class from the previous assignment. This class is responsible for all the user-interface operations in this program e.g., displaying menus, getting user input, determining if the user's selection was valid/determining which option was selected. Once the user's selection has been determined then it will pass messages to (call methods of) other objects (as was the case with the Menu class).

Minimum required attributes: a reference to an instance of class Track (the race track) as well as something to store the user's selection.

Minimum required methods: will include everything associated with the user interface (e.g., Displaying menus, getting user selections, determining what selection was made etc. It should also be responsible for starting and ending the simulation).

Mode: identical to the Mode class that you used for the previous assignment. It's sole purpose is to determine if the program is operating in the debugging mode. By default the program will not be operating in debugging mode.

public class Mode
{
     public static boolean debug = false;
}

RaceSim: The 'Driver' class for this program. The starting execution point that should contain a reference to the user interface class:

public static void main (String [] args)

{
     CommandProcessor anInterface = new CommandProcessor ();
                 :                        :       
}

Runner: the entities that travel along the race course. As mentioned one will be controlled by the user, three will be controlled by the computer program.

Minimum required attributes: strength, endurance, discipline, current running mode (jog, run, sprint), and if the runner is 'winded' or 'burnt out' (see Feature #8). Also each runner needs an 'appearance' field, a single character that determines how the runner is represented (the runner controlled by the user is a 'P' while the three controlled by the program are 'X'). Finally each runner should track it's current location (row/column) on the race track because the destination is going to be based on the current location. These are just a few of the attributes needed for class Runner you will almost certainly have more.

Minimum required methods: everything that modifies/retrieves the attributes (there will be many). It should also include methods that are somehow related to the attributes even though they don't directly access or modify the attribute for other objects. For example determining if the runner gets distracted (see Feature #5c) should be implemented as one or more methods of this class because the probability of distraction is determined by the runner's discipline.

Track: similar to the Manager class in the previous assignment it tracks the core data used by the program. The previous program's Manager class tracked information about the list, this program's Track class is responsible for storing and managing all the information used in the simulated world (the race track).

Minimum required attributes: the simulated world (a 2D array of 'Runner' objects): private Runner [][] raceCourse; references to the one runner controlled by the user and three runners controlled by the program. Each element in the race course array will either be null (signifying an empty location on the track) or refer to a runner object.

Minimum required methods: all behaviors associated with managing the data attributes (e.g., displaying the world, changing data in the world - moving runners between locations, checking if the race is finished (when one or more runners reaches the end).

Weather: This class is similar to class Mode in that there will only be one instance of this class for the whole program. Consequently it should have an entirely static implementation (alternatively you can employ the Singleton design pattern, if you don't know what I mean then just stick to making all attributes and methods static). This simulation tracks two aspects of the weather: the wind strength and the current temperature. There are three possible wind strengths: no wind, mild wind and heavy wind. There's four possible states for the temperature are: average, hot, very hot, heat wave. There's an equal probability for a particular wind strength to occur and an equal probability for a particular temperature. The weather conditions will be determined at the start of the simulation and stay the same for the remainder of the race.

Minimum required attributes: wind and temperature.

Minimum required methods: one or more methods to randomly determine the weather conditions.

Program features (you will also be graded on other criteria such as style and documentation as listed in the marking key):  After creating the above class definitions here are features that should be included in a working program.

Note: the marking key for this assignment will be set up so you can get a top grade without necessarily implementing each and every feature (there will be a margin of error built in). However in order to prepare yourself for the exam make sure you attempt (better yet complete) as many features as possible.

  1. Displays an introduction to the program that describes the rules. It only displays these instructions right after the program is run.
  1. Displays a sign off exit message when the program ends.
  1. Program runs until the end condition has occurred. If the program can determine the win conditions (human controlled runner is the only one on the final row), lose conditions (one or more of the computer controlled runners reaches finish while the human controlled runner has not yet reached this row) or a tie (human controlled and one or more computer controlled runners reached the last row) then the status of race should be displayed at this time. Otherwise the program will only end if the user quits the game (enters 'q' or 'Q') at the end of a turn. To make it easier for the user to see the results the program should display the last few rows of the track when the simulation ends (see Figure 2).
  1. Each turn a menu of options will be displayed that allows the user to select the running speed of the human controlled runner: (j)og, (r)un (s)print (q)uit simulation.
  1. The track is displayed using a numbered grid. Because the length of the track will exceed most screen displays the program should pause the display the track part way through the display and wait for user input (see the sample program outputs for an example). To help your marker (and you) determine if features of your program are working properly, as the program displays the track it should also show the following information for each runner:
 
  • The running mode (jogging, running or sprinting).
  • The distance to be traveled that turn (this is the final distance after all modifications have been taken into account, wind and the strength modifier for sprinting runners).
  • If the runner is okay, winded or burnt out.
  1. By default all 4 runners will have 210 points that are evenly distributed between: strength, endurance and discipline. (Debug must show feature working)
  1. Strength: an integer from 1 – 100.  Add 1 unit of sprint distance per 20 units of strength, drop fractions (0 – 19 equals no units unit, 21 – 39 equals one unit, 40 – 59 two units, 60 – 79 three units, 80 – 99 four units, 100 five units). It has no effect on runners who are running or jogging.
  1. Endurance: an integer from 1 – 100, reduce the chance of being winded or burnt (running and sprinting speed only) out by 1% per 10 units of endurance (drop fractions) e.g., 1 - 9 produces no effect, 10 - 19 reduces the chance by 1% etc.
  1. Discipline: an integer from 1 – 100. Getting winded and burning out are physical limitations. Discipline describes the runners ability to focus and concentrate. There is a 25% possibility that when the runner is traveling at a speed faster than a jog (whether that speed was selected by the user or randomly generated by the computer program) that the runner will become distracted and slow to a jog anyhow. This chance is reduced by 2% for every 10 units of discipline over 50: 60 - 69 disciple the chance is 23%, 70 - 79 units the chance is 21%, 80 - 89 discipline the chance is 19%, 90 - 99 discipline the chance is 17%, 100 discipline the chance is 15%.
  1. When the program starts, the user is given an option to change the default allocations among the three attributes. The runner controlled by the user can have the points distributed in a way that is different from the default. However the following constraints must be met: each attribute must be set to a value between 1 and 100 and the sum of the 3 attributes totals 210. If an attribute is set so that one of the above constraints is violated then the program will continue prompting the user to either accept the default allocations (and proceed to the start of the race) or re-enter valid values for the attributes.
  1. The current weather conditions are determined for the race day. Wind effects the number of squares that can be traveled by each runner: 0 (no wind), -1 (mild wind) to - 2 (heavy wind) movement. It's possible that the wind can actually push a runner backwards (but not back from the first row). Temperature will reduce the runner's endurance, which can affect if a runner gets winded or burns out: -0/no effect (average) -10 endurance points (hot), -20 endurance points (very hot), -30 endurance points (heat wave) units of endurance. In this case endurance won't go below the minimum of one point. (Debug must show feature working)
  1. Runners can move at one of three speeds: jog (move 1 unit), run (move 2 - 3 units), sprint (move 4 - 6 units plus modifications due to strength). The user will be prompted for which traveling speed that they wish the human controlled runner to travel at. The computer program will randomly determine which of the 3 speeds that the three computer controlled runners travel at. Traveling at the faster speeds has a risk. When running there's 20% chance per turn may get winded and must (no option) switch to a jog the next turn, the turn after that the runner may start running faster again. When sprinting there's 20% chance to get winded and switch to a jog for a turn, 20% chance that the runner may burn out and be stuck at a jog for the remainder of the race, 60% chance can maintain the sprint that turn. (Debug must show feature working)
  1. Debug mode implemented: Debug mode can be toggled at the start of each turn with a hidden menu option ('d' or 'D' instead of selecting one of the listed options) to toggle debug mode. Similar to the previous assignment in order to get credit for debug mode you must use debugging messages in some form. In order to get credit for features labeled "Debug must show feature working" debug mode must show enough information so that the marker can quickly determine if the feature has been implemented correctly. You can check with your marker for the specifics on this but generally you are should show the value of different variables in order to demonstrate that the feature works. For example to show that your program increases the sprint distance it might show the following information when debug mode is engaged: base sprint distance (the randomly generated value between 4 and 6), the value of the strength attribute, the extra distance that could be traveled because of strength. How many marks you receive for these features will be determined by how well your debugging messages communicate this information.
  1. Additional bonus feature: instead of displaying the simulation in text, a graphical library (e.g., Java 2D, QuickDraw is used). The interface itself can still be console based (i.e., select a menu option via console input) just the output can be graphical. Your graphics don't have to be fancy (e.g., you can use different primitives, color and/or text to distinguish the runners) but the graphical version must clearly represent the same information as the text-based equivalent (e.g., don't use rectangles of the same size and appearance for each runner). You won't get a lot of extra marks for implementing this feature (because graphics isn't a key feature of this program) and you will either have to be familiar with a library or be willing to invest the time to learn one on your own. But I did include this feature in case you wanted to spice up your program and/or you wanted to increase the probability that your assignment received a higher grade.

Resources:

They can be found in the UNIX directory: /home/219/assignments/assignment5. Within this directory are three sub-directories: 'java_code', 'sample_runs'. The first directory contains the dot-java files that are needed by your program. The second directory contains text files that show the output of my solution program under different situations. Since there is no byte code solution to run for this program you can look through the output of these files to clarify assignment requirements.

Submitting your work:

  1. Assignments (source code/'dot-java' files) must be electronically submitted according to [the assignment submission requirements]. Also you need a README text file that lists which of the features of the assignment you have completed. If there are any special instructions needed to run your program, e.g., images needed, the instructions should be included in the README file and these additional files submitted as well. You are to electronically submit the README file along with your source code (make sure you don't forgot to submit all the dot-Java files). There is no need to compress the files via zip or another program.
  2. As a reminder, you are not allowed to work in groups for this class. Copying the work of another student will be regarded as academic misconduct (cheating).  For additional details about what is and is not okay for this class please refer to the following [link].
  3. Before you submit your assignment here is a [checklist] of items to be used in marking.

External libraries that can be used

  1. Libraries that allow for text-based (console) input and output.
  2. Classes used to generate random values such as Class Random or class Math.
  3. (If the last feature is implemented).  Java libraries that draw two-dimensional graphics.