Assignment 19

Task

Write a zombie-shooting simulation that reads in an initial scenario from a file and then reports whether the lone human survives or not.

Textbook: 7.4; 10.5; 10.6
Concepts: Review of class-related concepts; command line arguments; file I/O; exceptions

Steps

The simulation works as follows: A single human survivor is located at the origin (0, 0) of a theoretical coordinate plan. This human is surrounded by various mindless, brain-craving, flesh-eating walking undead (aka, zombies). Luckily, the human is armed with a high-powered automatic weapon, sufficient ammunition, and is well-trained in the "one shot, one kill" technique of zombie-apocalypse survival. (See Max Brooks' Zombie Survival Guide and World War Z.) However, the human is limited to only killing zombies within a certain killzone range.

Each zombie starts at its own (x, y) coordinate and has its own speed. Once each second, the human fires at the nearest zombie within the killzone, and all remaining zombies shuffle and moan their way directly towards the human at their top speed.

The simulation ends when either 1) at least one zombie reaches the human, or 2) the human slays all zombies with a positive speed.

File format (and zombie behavior)

The initial layout of zombies will be specified in a text file. (Thus, you can create different text files for different simulation scenarios.) A simulation file must define one zombie per line. It must define at least one zombie. Each line must include a name, x-position, y-position, and speed (in that order). The name can be any single word (or number). The other values must be integers, though they may be <=0. The different values on a line can be separated by any amount of whitespace (tabs or spaces).

Clarification (01 Dec 2009): Every line of the file, including the last line, must end with a newline character. (Thus, in a text editor, you would be able to move your cursor to the beginning of the blank line after the last zombie line, but there would be no characters on that blank line.)

Note that, although initial zombie positions are given as integers, a moving zombie is not restricted to an integer-based grid. Instead, the zombie moves directly towards the human located at (0, 0). Since zombies will scramble over each other and push each other aside in their haste to reach fresh brains, two zombies may effectively occupy the same location in the simulation.

You may need to recall the distance formula: d = √((x2 - x1)2 + (y2 - y1)2). (Of course, if you only care about the distance from the origin (0, 0), this becomes simply: d = √(x2 + y2).)

Though unusual, a zombie may have a negative speed, which means it moves away from the human. (This behavior has been observed occasionally in "disoriented" zombies that have suffered severe facial trauma.) Also, limbless zombies or those caught on certain obstacles might have a speed of 0.

Some sample simulation files can be found here. Files named "badsim" have file format errors that your program should be able to handle gracefully.

Command line arguments

You will not ask the user for any keyboard input. Instead, you will get all the information you need from command line arguments specified when the program is executed.

If the user runs the program without any arguments (or only 1 argument), they apparently do not understand how to use the program. Print a usage message explaining how to run the program and then quit.

If there are two arguments given, one of these is the input file to load, and the other is killzone radius. These two arguments can be specified in either order. (You can recognize the killzone radius because you can successfully parse it into an integer. However, it must be >= 0 to actually be a valid range. If you can parse both arguments into integers, it's up to you which one you treat as the range and which as the input file.) If you cannot open, read, or successfully parse the contents of the input file, print an error message and end gracefully.

If there is a third argument, it is an output file to append the simulation output to. That is, the simulation should run normally, but it should also print everything it prints to the screen into the file. (The idea is that you could run a number of different simulations, dumping all the output into one or more log files for later review.) It is up to you what to do if you cannot write to the output file: either abort the entire simulation with an error message, or else run the simulation normally and print an error message at the end that the output could not be written to the output file.

Simulation rules and output requirements

As mentioned above, the following should occur in this order each round (second) of the simulation:

• If one or more zombies is within the killzone range, the human shoots the closest one and automatically kills/disables it.
• All zombies then move their speed towards the human. (Although units are not required, you can think of each round as 1 second, distances in feet, and speeds in feet/second. 1 mile/hr = ~1.5 feet/second. "Fresh" zombies have been known to run at least as fast as a human.)
• If a zombie reached the human at (0, 0), the simulation ends: the human DIED.
• If the are 0 zombies left or if all remaining zombies have speeds of <= 0 (stationary or moving away): the human is safe and has SURVIVED.
• Otherwise, continue with another round.

The simulation begins at second 1. Note that the human can fire a shot during the first part of the round and still be eaten by a different zombie during the second half of the round.

It is strongly recommended that you print out the details of each zombie "kill" (which may not occur each second) to aid in portraying the unfolding events of the simulation. However, the only required output is as follows:

• If (and only if) the human survives, your output must include the string "SURVIVE" or "SUCCE" (such as "success" or "succeeds"). On the same line, you must indicate the number of zombies that remain active.
• If (and only if) the human dies, your output must include the string "DIE" (as is "dies" or "died") or "FAIL". On the same line, you must indicate the second during which the human died, as well as the name/label of the zombie that reached the human. (If more than one zombie reaches the human during the same second, it's your choice which one to print.)
• The output requirements are not case-sensitive (though CAPS may be easier to spot quickly).

You must write at least two separate classes.

Sample Output

D:\TA\grading\A19>java ZtomaszeA19
Error: You must specify at least two command line arguments.

To run this program, you must specify an input file (containing initial zombie
positions) and a killzone radius as command line arguments.  These can be
given in either order.  Optionally, you may then specify an output file to
append output to as third argument.

Command format: java ZtomaszeA19 [input file] [range] [[output file]]

Example: java ZtomaszeA19 sim3.txt 100
Example: java ZtomaszeA19 100 sim3.txt
Example: java ZtomaszeA19 zombies.txt 50 simlog.txt


D:\TA\grading\A19>java ZtomaszeA19 nofile.txt 100
Error: Could not find/read simulation file: nofile.txt (The system cannot find t
he file specified)

D:\TA\grading\A19>java ZtomaszeA19 badsim1.txt 40
Error: Incorrect format of file contents in simulation input file: badsim.txt

D:\TA\grading\A19>java ZtomaszeA19 sim1.txt 100
SIMULATION: sim1.txt.  Killzone radius: 100ft.
Second 1: shot Z1 (10.0ft away; speed: 5ft/s)
Second 2: shot Z2 (5.0ft away; speed: 5ft/s)
Second 3: shot Z4 (17.213203435596427ft away; speed: 2ft/s)
Second 15: shot Z3 (99.42135623730951ft away; speed: 3ft/s)

Human SURVIVES with 0 zombie(s) remaining.


D:\TA\grading\A19>java ZtomaszeA19 100 sim3.txt
SIMULATION: sim3.txt.  Killzone radius: 100ft.
Second 1: shot Z5 (1.0ft away; speed: 1ft/s)
Second 2: shot Z2 (3.0ft away; speed: 7ft/s)

Human FAILS: Eaten at second 2 by Z1 (0.0ft away; speed: 6ft/s)


D:\TA\grading\A19>java ZtomaszeA19 sim4.txt 20 log.txt
SIMULATION: sim4.txt.  Killzone radius: 20ft.  Logging to: log.txt
Second 10: shot TheShuffler (19.0ft away; speed: 2ft/s)
Second 11: shot Granny (16.0ft away; speed: 4ft/s)
Second 12: shot SockEye (14.0ft away; speed: 3ft/s)
Second 13: shot Burt (9.0ft away; speed: 6ft/s)
Second 14: shot BigDrooly (4.0ft away; speed: 7ft/s)

Human FAILS: Eaten at second 14 by LeftField (0.0ft away; speed: 5ft/s)


D:\TA\grading\A19>java ZtomaszeA19 sim4.txt 30 log.txt
SIMULATION: sim4.txt.  Killzone radius: 30ft.  Logging to: log.txt
Second 5: shot TheShuffler (29.0ft away; speed: 2ft/s)
Second 7: shot SockEye (29.0ft away; speed: 3ft/s)
Second 8: shot Granny (28.0ft away; speed: 4ft/s)
Second 9: shot LeftField (30.0ft away; speed: 5ft/s)
Second 10: shot Burt (27.0ft away; speed: 6ft/s)
Second 11: shot BigDrooly (25.0ft away; speed: 7ft/s)

Human SURVIVES with 0 zombie(s) remaining.


D:\TA\grading\A19>more log.txt
SIMULATION: sim4.txt.  Killzone radius: 20ft.  Logging to: log.txt
Second 10: shot TheShuffler (19.0ft away; speed: 2ft/s)
Second 11: shot Granny (16.0ft away; speed: 4ft/s)
Second 12: shot SockEye (14.0ft away; speed: 3ft/s)
Second 13: shot Burt (9.0ft away; speed: 6ft/s)
Second 14: shot BigDrooly (4.0ft away; speed: 7ft/s)

Human FAILS: Eaten at second 14 by LeftField (0.0ft away; speed: 5ft/s)


SIMULATION: sim4.txt.  Killzone radius: 30ft.  Logging to: log.txt
Second 5: shot TheShuffler (29.0ft away; speed: 2ft/s)
Second 7: shot SockEye (29.0ft away; speed: 3ft/s)
Second 8: shot Granny (28.0ft away; speed: 4ft/s)
Second 9: shot LeftField (30.0ft away; speed: 5ft/s)
Second 10: shot Burt (27.0ft away; speed: 6ft/s)
Second 11: shot BigDrooly (25.0ft away; speed: 7ft/s)

Human SURVIVES with 0 zombie(s) remaining.


D:\TA\grading\A19>

Groups

You may collaborate on this assignment provided you are in an official group. (If you are not in an official group, you must do your own work, as for all other assignments.)

Working in a group is likely to be a useful experience. While it will hopefully mean less of a programming load for each member, remember that you will instead need to spend time planning and coordinating with your group. Once in a group, you are responsible for that group's overall success.

Regardless of whether you are in a group or not, you will still submit an individual copy of your A19.

Group Formation (Due: 17 Nov)

Groups should have 3 members each. (If you really can't find a 3rd member, pairs are also acceptable.) All group members must have the same TA.

You may form your own group. To do so, one member of the group should send me an email (CCed to all other members of the group) listing the group members.

If you'd rather be assigned to a group, send me an email saying so. I will do my best to match you up with other people also interest in being assigned to a group.

These emails are due by 1pm, 17 Nov. If you miss this deadline, you must work individually on this assignment.

Group Division of Work (Due: 22 Nov)

By the 22nd, you must send me one email per group (CCed to all group members) that:

1. outlines how you plan to break the problem down into classes and/or methods. This should include specific method signatures and return types.
2. which group member will be responsible for which part(s)

This is effectively a contract between group members. Even if you end up collaborating to get the various pieces working together properly, each person is responsible for ensuring that their parts are ultimately correct. You may also consider what order you're going to write the pieces in--what parts must you have done before you can test other parts?

See the second FAQ for some sample designs as we discussed in lab (Sections 001 and 002).

Example division of work for a pair (using design1.txt):

  Samantha: Zombie class, loadFile method, main method
  Andrew: runSimulation and its three helper methods, appendToFile method

Example division of work for three people (using design2.txt):

  Chen: Zombie class, main method
  Ralph: ZombieSim constructor (including reading from file), three private ZombieSim methods
  Andrew: appendingToFile method, ZombieSim run method

Report of Group Member Participation

When you submit your own copy of the code, list each @author separately in the documentation at the top of the class. In this documentation, briefly summarize the group experience and comment on how well your other group members participated.

In particular, indicate how you think the group's total points should be distributed among its members based on their participation. The total points = (100% * group size). In short, giving someone a 100% means they did everything they were supposed to as part of the group. If someone gets less than 100%, it means they were slacking (maybe only doing 75%) and someone else had to pick up their slack (+25%), and so that second person should get more points for the extra work (125%).

Examples:

 *
 * @author Jimmy  100%
 * @author John  100%
 *
 * We both worked really hard on this, and I think we should split
 * the total points evenly.  I was late to one of our meetings, but
 * I stayed up really late another night helping John get his file
 * reading method working.
 */

 *
 * @author Alice  20%
 * @author Bob   185%
 * @author Ralph  95%
 *
 * I (Ralph) came through with my part and it worked the way it was supposed
 * to.  Alice totally slacked off and didn't reply to any of our emails.
 * She did send us one of the methods she was supposed to write, but it
 * had a bunch of compile problems and didn't work.  Bob wrote all of Alice's
 * part and also got all the pieces glued together and working in the end.
 */

Official groups

• Phillip Ruan, Michael Cheng, Danny Yu
• Stanley Ronquillo, Annalynn Macabantad.
• Brad Kitashiro, Kelsie Kanetake.
• Landon Ocreto-Silva, Cristina Luke
• Joneal-Anthony Altura, Steven "Ikaika" Rodenhurst

• Brandon Moriguchi, Stephanie Soon, Kenneth Kuroda
• Donna Gonzales, Jonathan Imai, Donald Alanis
• Joey Bradner, Kyle Tsuneda, Ryan Whitenack
• James Vu, Alan Sheen
• Ben Lang, Calvin Wong

Consultants

As an alternative to working in a group, you may serve as an advisor to other individuals or groups. Consultants should generally be people who have already finished the assignment. For individuals volunteering to do this, the experience will teach you how to read other people's code and to understand other solutions than your own. For those who request the help of a consultant, it should hopefully provide another source of help than the TA.

Consultants can offer advice on both design and on code. However, they must adhere to the following rules:

• Your job is to help your client reach their own solution, not to simply provide a solution. First, strive to understand what client is trying to do so far. Then, advise either on how to achieve this design or on what drawbacks there might be to this approach.
• Never show your own code to those you are advising. (You may demo your .class files, though, if you want to prove that your really did solve the problem correctly.)
• Don't write code for your client. (Try to stick to pseudo code. Providing two or three lines of code as a demonstration is okay. You can help debug errors. In short, use your best judgement on this in light of the first rule.)
• Consulting is on a volunteer basis, so you may decline to help if you get too busy or if you feel the group/individual is relying too heavily on you. (Do at least reply to any emails though, so that clients know to look elsewhere to help.) You may meet in person or work by email, as you see fit.
• A client is not obligated to follow the advice of a consultant.

To volunteer to be an A19 consultant, just send your TA an email. To contact a consultant, speak to or email one directly.

List of consultants:

• [Removed]

What to Submit

Upload your UsernameA19.java file to Tamarin. Remember that the file must include all the classes needed for your program to run!

Grading [12 points]

1 - Compiles + Coding Standards

Your program compiles successfully (no errors). Your code follows Java coding standards.

1 - Wrote at least 2 classes

For example, you might have UsernameA19 and Zombie.

3 - Command line arguments

Prints error/usage message (without crashing) if given less than 2 arguments (1.0). Gets killzone radius and name of input file from cmd line args; these two args can be in either order (2.0).

1 - Optional output file

If a third command line argument is given, writes any screen output to this file as well (0.5). Appends to, rather than overwriting, the file (0.5).

1.5 - File I/O errors

Program reports error (without crashing) if input file does not exist or cannot be read (0.5) or if the file's contents are not formatted correctly (0.5). Program reports an error if the optional output file cannot be written to (0.5).

4.5 - Simulation results and output

After loading initial zombie locations from the input file and following the rules given above, the simulation gives correct output on whether the human succeeds/survives or fails/dies (3.0). Output must be formatted as described above. Also, if the human survives, correctly print how many zombies remain (0.5). If the human dies, correctly report at which second this occurred and which zombie got to the human (1.0).

Then, the remainder of your 12 points will be determined by your required group activities:

0.8 - Group division of work

I received an email from your group explaining how you would break the problem down into pieces (classes and methods) and who would be responsible for which piece.

1 - Report of Group Member Participation

When you submit your assignment, you included a rating and comments concerning the participation of your other group members. (See above for format.)

Grader input files: The input files used by Tamarin are now in the sample simulation files directory.

FAQs

Demo code from lab?

On command line arguments: Adder.java.
On reading from a file: FileViewer.java.
On writing (appending) to a file: FileAppender.java

Where is that design sketch we came up with in lab (Sec 001 and 002)?

Here is basically the design we discussed in lab: design1.txt. Note that it includes method signatures and brief description of what each important method does. For the more complicated methods, it also includes a summary of that method's algorithm.

If you're working in a group, you will need to produce a design document similar to this so that everyone in the group knows what the various methods will be and so can write their code accordingly. For example, someone working on the main method could write a temporary "dummy" runSimulation method that simply returns an arbitrary String. This is enough that main will compile and shows that everything main does is correct. Then, later, you can replace that dummy method with the real runSimulation method that actually does something.

As mentioned in lab, you could make ZombieSimulation its own class, and also remove dead zombies from the list rather than simply marking them as dead. Here is a second design with those changes made: design2.txt. Also, writing your javadoc document before you start coding means you don't have to do it later!

You are welcome to use these designs as a starting point and change them in any way. Or you can do your own thing.

How do I input command line arguments if I'm running my program in jGrasp?

Select Build -> Run Arguments. This will add an input field above your code. Type your command line arguments in there before you run the program.

Should the human kill fleeing/passive zombies?

Yes. The rules state that the human should always shoot the closest zombie that is in the killzone. This is regardless of the zombie's speed--which could be 0 or less.