Spring Semester 2008

January 28, 2008 – May 2, 2008

Assignment 10: Mutually Assured Destruction

Out on: April 14, 2008
Due by: April 21, 2008, 3:00 pm (before lecture)
Collaboration: Teams
Grading: Packaging 10%, Design 20%, Style 20%, Functionality 50%

Overview

The tenth assignment deals with ships on the high seas again, changing the rules of war somewhat from the previous assignment and opening up a competitive market (not related at all to really existing markets (which are not competitive (but 180.101 probably didn't mention that))) for the generals encoded in your programs. Sounds pretty impressive, eh? Well, it is! :-)

This is a team assignment, and all of you should know which team you're in (I hope). Decide early on who is going to be responsible for submitting the assignment and when. Make sure to include all the relevant information (who is in the team?) in your README file! Decide on a schedule early on as well, nothing delays working in a team more than having to schedule meetings ad-hoc; compare your schedules and arrange to meet in advance! All members of a team will receive the same score for the product you submit together. After the assignment is over, each of you will be asked to evaluate the contribution your partners and yourself made to the assignment.

Rules of the Game

The rules for this version of Battleships are changed in two minor ways compared to the rules we had for the previous assignment.

First, if the option --nosubs or -n is given, then there are no submarines of size 1 anymore. Instead the list of ships each side starts out with is as follows: There is one aircraft carrier of size 5, one battleship of size 4, two cruisers of size 3, and three destroyers of size 2. If the option -n is not given, the ships are as in the previous assignment.

Second, if the option --room or -r is given, then ships cannot be placed "next to each other" anymore. This means that there must be at least one square of ocean between any two ships in all four cardinal directions. If the option -r is not given, the placement of ships is as in the previous assignment.

Please be advised that we don't guarantee that these rules stay as described here in the future; we reserve the right to change the rules further in order to check how flexible your design is.

Playing Against Others

The major extension for this assignment is the addition of a protocol that allows two Battleship programs to play against each other. If the option --duel or -d is given, the input and output of your program must follow the protocol exactly, otherwise things will go awry. You can't output anything but the protocol to standard output, and you can't expect anything but the protocol on standard input.

We provide you with a simple tool hacked in Python that can be used to start two Battleship programs and have them talk to each other. The tool is used as follows: 

  python piper.py programone programtwo

Here programone and programtwo are the two Battleship programs that are playing against each other. You can provide the same name twice, in which case the program will play against itself (hint for testing your code I guess?). As part of starting the programs, piper will provide the -d option to both, telling them to adhere to the protocol. It will also provide the -f option to programone telling it to go first (see the previous assignment about -f).

The protocol consists of the following messages (in the form of strings): 

  FIRE row column
  MISS
  HIT
  SUNK size
  CONCEDE
  CHEAT some string

The game starts with the program going first sending a FIRE message to attack the given position. As before, positions are encoded in rows from A to J and columns from 1 to 0 (which is column 10). The response for most attacks will be either HIT if a ship was hit or MISS if no ship was hit; note that the program not attacking right now sends that message, so after sending FIRE you need to wait for a reply from the other side. After sending the reply, sides change, and the other side sends a FIRE message; and so on.

If an attack sinks a ship, instead of replying HIT you must reply SUNK and give the size of the ship just sunk as an integer; so sinking the aircraft carrier would lead to SUNK 5. Eventually an attack will sink the last ship, in which case you reply CONCEDE instead of SUNK and the game ends. The only other way the game can end is with a CHEAT message. The party sending that message is accusing the other party of cheating, and needs to provide a detailed message about why the accusation is being made. Both programs stop at this point.

Note that all messages sent this way have to end with a single linefeed character, so the string for CHEAT can not include linefeeds except at the very end.

Real Strategies

Your game should still play randomly by default. If the option --strategy or -s is given, you should use whatever strategy you can come up with to win faster. It's up to you how that strategy works...

Development Tasks

In updating your current Battleships program, you should also update your design as documented in your README file. Include a short section that discusses the problems you had in adapting your design and implementation to the new specificiations, and tell us how you solved them. In your revised design and implementation, pay attention to those problems and try to anticipate future changes as far as you can. Enjoy!

Hints

Deliverables

Please turn in a gzip compressed tarball of your assignment; the filename should be cs120-assign-10-teamcode.tar.gz with teamcode replaced by the code assigned to your team for your repository and your mailing list. The tarball should contain no derived files whatsoever (i.e. no executable files), but allow building all derived files. In particular, make sure you don't submit all those .svn folders from your repository! Include a README file that briefly explains what your programs do and contains any other notes you want us to check out before grading. Include a Makefile to build your project.

Grading

For reference, here is a short explanation of the grading criteria. Packaging refers to the proper organization of the stuff you hand in, following the guidelines for Deliverables above. Style refers to C++ programming style, including things like consistent indentation, appropriate identifiers, useful comments, suitable documentation, good use of private and const, etc. Simple, clean, readable code is what you should be aiming for. Performance refers to how fast your program can produce the required results compared to other submissions. Design refers to proper modularization (into files and classes) and the proper choice of algorithms and data structures. Functionality refers to your programs being able to do what they should according to the specification given above; if the specification is ambiguous and you had to make a certain choice, defend that choice in your README file.

If your programs cannot be built you will get no points whatsoever. If your programs cannot be built without warnings using g++ -ansi -pedantic -Wall -Wextra -std=c++98 -O -Wabi -Weffc++ -Wctor-dtor-privacy -Wold-style-cast -Woverloaded-virtual -Wno-pmf-conversions -Wsign-promo we will take off 10% (except if you document a very good reason). If your programs cannot be built using make we will take off 10%. If your programs fail miserably even once, i.e. terminate with an exception of any kind or dump core, we will take off 10%. Finally, make sure to include your name and email address in every file you turn in!