Spring Semester 2008

January 28, 2008 – May 2, 2008

Assignment 9: A Battle of Ships

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

Overview

The ninth assignment deals with ships on the high seas of some abstract ocean doing virtual and decidedly non-lethal battle. Peace through war games? Oh well, anyway... Your "big project" from now until the end of the semester is to implement a variation of the classic Battleships game. It won't exactly be Quake of course, but hopefully it'll be fun anyway.

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 our version of Battleships are as follows: The game is played on a 10x10 square grid on which each player places his or her ships. There is one aircraft carrier of size 5, one battleship of size 4, one cruiser of size 3, two destroyers of size 2, and two submarines of size 1. These ships can be placed anywhere, either vertically or horizontally, as long as each ship fits.

After the game is set up, it proceeds in turns: One player announces a square on the opponent's grid to attack; the other player checks his or her setup and replies with whether the attack hit a ship or missed all ships; if it is a hit, and if the hit eliminates the last remaining square of a ship, the player also has to announce that a ship was sunk; if the last ship of a player was sunk, the attacking player wins; otherwise the roles are switched and the player who was attacked becomes the attacker.

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 in order to check how flexible your design is.

Designing the Battle

Your first task, hopefully before you start hacking your game, is to develop a basic object-oriented design for your game. What you should do is identify the necessary classes (including their attributes and operations) as well as the important relationships between classes (associations and generalizations).

Note that you don't necessarily have to document this as a UML diagram, although you're of course free to do that. You can simply produce a well-formatted section of your README file. You can also include a more prose-style description, as long as you accurately reflect the classes and their relationships.

Probably the best way to approach this design task is to get together as a group and have a fun brainstorming session. Once you have a bunch of classes and relationships, try to "play out" the game using those classes; anything you can't explain in sufficient detail indicates areas where your design is not quite clear enough yet, so work a little more.

If you run into a problem that you simply cannot resolve, no matter how hard you try, make a note of it and file it away. After some hacking, you might be able to go back to the problem and solve it quite easily. :-) A little "back and forth" between design and implementation is quite healthy.

Implementing the Battle

Your second task, obviously, is to actually implement the game. Please name your executable battle so we can easily run it.

For this assignment, your focus is on a human-computer version of the game. This implies that you have to keep track of both sides in your program, whereas the later version that allows two computers to play against each other will only track its own "view" of the oceans. It also means that you should somehow display the two relevant "maps" for the human player on each of his or her turns, something that won't be necessary in the later version either. Please keep these things in mind as you design and implement the current version of the game.

The initial setup, i.e. placing ships on the grid, for both sides is generated randomly in this version. Furthermore, the computer strategy should be random as well: Don't implement some fancy strategy for now, focus on getting the rest of the game done and not on making the computer play particularly well. Simply choose positions to attack randomly from all positions not previously attacked.

If the option --first or -f is given, the computer has the first move, otherwise the user has the first move. The user can either enter quit or q or use CTRL-D to abort the game. Anything else the user enters is interpreted as a coordinate for an attack. For example, A 7 means square A/7 on the board is attacked. After an attack, the user should find out if the attack hit, missed, or even sunk a ship; the next time the map is displayed, the corresponding square on the user's radar should also be filled appropriately. The game ends if all ships of one player have been sunk.

Oh, please note that A 1 is the first row, first column of the board, while A 0 is the first row, last column of the board. Also, For the user, is an attack is impossible or nonsense (because the square was attacked before) you should respond with a nice error message and give him or her another chance.

Hints

Deliverables

Please turn in a gzip compressed tarball of your assignment; the filename should be cs120-assign-9-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!