1. Goals of this assignment
   1. Collaboration Policy
   2. Style & Design Policy
2. Specifications
   1. How to Play
   2. Implementation Details
      1. BattleshipGame
      2. Ship
         1. The Ships
         2. EmptySea
      3. Ocean
3. Testing
4. Documentation
5. Submission
6. Grading
7. Appendix
   1. Board Examples
   2. Testing Overload

Goals of this assignment

This assignment is due Tuesday, December 14 at 11:59pm. Late submissions may be subject to significant point deductions and delays in grading. Extensions may be granted in extreme circumstances, but the student may be required to temporarily take an “incomplete grade” as a result. In short, please do not plan to submit this project late.

In this assignment, you’ll implement your third and final game for this class. You’ll make a single-player version of the game Battleship. This final project will use the skills you’ve developed throughout the semester, and it will also give you ample practice with abstract classes and derived classes.

Collaboration Policy

You may collaborate with one other student on this assignment. You may write code with this one other student, and you may view each other’s code. You cannot write or read code with other students. If you collaborate with a partner, you must also document your work using commits to a Git repo.

Include in your README.txt file the partner you worked with, if any. You should also include a link to the private GitHub repo that you’re using to host your code. We will be able to determine who was responsible for what code by reading the commits from your Git repo. When you submit, we also ask that you provide a screenshot of your mutual commit history from the repo.

Style & Design Policy

Good style includes:

• Consistent indentation in code, with lines of code indented to the correct level representing the block they belong to.
• Identifiers for methods and variables that follow the correct camel case convention and are appropriately descriptive.
• Correct spacing between operators, parentheses, and brackets.
• Closing File Streams after using them
• Correct and detailed JavaDoc headers for each field and method, as modeled in the provided JavaDocs.

Fortunately, most good style practices can be automatically enforced using Eclipse. From Preferences, choose Java -> Editor -> Save Actions and check the Format source code box under the Perform the selected actions on save option.

Additionally, you’ll need to make good design choices for this assignment. We won’t be too strict, but some things to look out for are:

• Declaring variables only in the scopes where they’re needed and avoiding the creation of unnecessary fields
• Fields should be set to private with access moderated by getter and setter methods

Style and design scoring will consist of 5% of the assignment grade.

Specifications

Access the starter files here. This project will walk you through building a simple version of the classic game Battleship. Battleship is usually a two-player game, where each player has a fleet in an ocean hidden frome the other player. Players take turns attempting to sink the other player’s fleet by shooting missiles at specific tiles in the ocean. You can play a version of two-player Battleship here. Our version of Battleship will be a one-player game, where the computer places the ships and the human player attempts to sink them.

Your submission must include and implement all of the fields and methods enumerated in the JavaDocs for this assignment.

Our game will take place on a 10x10 ocean with the following fleet:

How to Play

Please read these rules even if you have played Battleship before!

The computer will place the ten ships in the ocean in such a way that no ships are immediately adjacent to each other horizontally, vertically, or diagonally. We have included in the appendix four examples of game boards with legal and illegal placements.

To start, the human player will not know where the ships are. The initial display of the ocean will show a 10x10 array of locations, all the same. The human player tries to hit the ships by providing a row and column number. The computer will respond with a single message: hit, if the coordinate corresponds to a tile containing a ship, or miss if the coordinate corresponds to an empty ocean tile.

A ship is “sunk” when every tile making up the ship has been hit. It takes four hits (in the four different tiles) to sink a battleship, but only one hit to sink a submarine. When a ship is hit but not sunk, the program does not provide any information about what kind of a ship was hit. However, when the last tile of a ship is hit and the ship sinks, the program will print out the message: You just sunk a <SHIP_TYPE>.

After each shot is taken, the computer should again display the ocean with all information about all tiles attacked, including a marking for hits and for missses.

The object of the game is to sink the fleet with as few shots as possible; therefore, the best possible score is 20, and the worst possible score is 100.

When all ships have been sunk, the program should print out a message that the game has concluded, and indicate how many shots were required.

Implementation Details

Your program must contain the following classes. No additional ones are needed, and you may not omit any of these. There are some summaries of these classes provided below. The full description of each class, field, and method, can be found in this project’s JavaDocs.

• class BattleshipGame.java
  • The “main” class, containing the main method and an instance variable of type Ocean.
• class Ocean implements OceanInterface
  • This class maintains a 10x10 array of Ship objects, representing both the ocean tiles and the ship tiles.
• abstract class Ship
  • This abstract class provides characteristics common to all ships. It will be subclassed extensively.
• class Battleship extends Ship
  • Implements a Ship with length 4.
• class Cruiser extends Ship
  • Implements a Ship with length 3.
• class Destroyer extends Ship
  • Implements a Ship with length 2.
• class Submarine extends Ship
  • Implements a Ship with length 1.
• class EmptySea extends Ship
  • Implements an empty ocean tile. It may be unintuitive to have an EmptySea extend from Ship, but it will allow us to maintain an Ocean as a 2D array of Ship objects.

BattleshipGame

BattleshipGame.java is the main class; that is, it contains a main method. In this class, you will set up the game, accept shots from the user as coordinates, display the results, print final scores, and ask the user if they want to play again. All I/O will be called from here, although some will be completed by calling a print() method in Ocean as well. No computation should be done here–all of that will take place in the Ocean class and the Ship subclasses.

To aid the user, row numbers should be displayed along the left edge of the game board and column numbers should be displayed along the top. The numbers should range from 0 to 9 in both directions. The top left corner square should be (0, 0). Use different characters to indicate locations that contain a hit, locations that contain a miss, and locations that have never been fired upon.

Don’t cram everything into one or two methods; instead, divide the work into sensible parts with reasonable names. That way, your main method should contain a short loop with carefully named method calls.

Ship

Ship.java must be an abstract class–we will never directly instantiate a Ship, only subclasses of the Ship.

Ships will always be facing up or to the left. That is, relative to the “bow”, or front, of the ship, all other tiles will be in higher numbered rows or columns.

This class should not include a constructor.

The Ships

Battleship, Cruiser, Destroyer, and Submarine are all subclasses of Ship, and they should each provide their own constructors as well as override the getShipType() method.

EmptySea

EmptySea also extends Ship. The reason for this is that the Ocean contains a Ship array, every location of which is a reference to some Ship. If a particular location is empty, the obvious thing to do is to put a null in that location. But this obvious approach has the problem that, every time we look at some location in the array, we have to check if it is null or risk throwing a NullPointerException. By putting a non-null value in empty locations, denoting the absence of a ship, we can save all that null checking.

Ocean

This class is responsible for maintaining much of the game state: keeping track of Ship locations, tracking player progress, and more. The full set of methods that you need to implement are enumerated in the JavaDocs for Ocean.java.

To get practice in implementing an interface, we’ve provided OceanInterface.java and the start of Ocean.java for you. Your submission must keep the relationship that Ocean implements OceanInterface in your final submission.

Testing

We expect you to write unit tests for every public method except for main. This will be a lot of testing. You can read more about that here.

There is no minimum coverage required to earn full points in testing. Instead, use a black-box testing approach to generate a number of interesting inputs for each of the methods you write. If you’re concerned that you might be missing interesting cases, then you can consider using coverage analysis to identify gaps in your testing strategy.

Documentation

OceanInterface and Ocean both feature JavaDoc comments; you should use what we’ve learned in class and follow these provided examples in order to thoroughly comment every method and every field in your project. If done correctly, you should be able to replicate the JavaDocs that I’ve provided to you.

Submission

Submit all of the files specified above. Make sure you adhere exactly to the specifications provided in the JavaDocs. Submit all of your tests as well. Additionally, you should include a README.txt that includes:

1. who you worked with (if anyone)
2. a link to your GitHub repo

Finally, submit a screenshot of your GitHub repo if you worked with a partner.

Ensure that your files do not have a package header! Specifically, the first lines of your file should not read package xyz or similar.

Please find these files locally on your file system. By default, they will be found in a folder called eclipse_workspace, often in your user’s directory. You should select each of the files and upload them as files (not as a directory, and preferably not as a .zip either). If you need help, please reach out on Piazza or in Office Hours.

Grading

Appendix

Board Examples

Valid board

Invalid placement, horizontal adjacency

Invalid placement, vertical adjacency

Invalid placement, diagonal adjacency

Testing Overload

You are required to write a substantial number of test cases for this assignment. It’s great practice for your life as a programmer in general, but it will be specifically useful for you as an MCIT student. CIT 594 is where you will use the programming maturity you’ve developed in this course to great effect, implementing many interesting data structures that can be used to solve exciting and challenging problems.

On the other hand, programming data structures and using them to solve problems is HARD. Getting used to writing tests, and lots of them, will prepare you for the process of designing expansive and challenging projects.