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
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:
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:
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:
You must write at least two separate classes.
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>
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:
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%).
* * @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 groupsSection 001:
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:
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:
What to Submit
Grading [12 points]
Then, the remainder of your 12 points will be determined by your required group activities:
Grader input files: The input files used by Tamarin are now in the sample simulation files directory.
|~ztomasze Index :
TA Details: ICS111:
|Last Edited: 28 Nov 2009|
©2009 by Z. Tomaszewski.