• Battleship is a guessing game for two players. The objective of the game is to destroy the opposing player's entire fleet.
• It is played on four 10 x 10 grids.
• Two grids (one for each player) are used to mark each players' fleets of ships (including battleships).
• The locations of the fleet (these first two grids) are concealed from the other player so that they do not know the locations of the opponent’s ships.
• Players alternate turns by ‘firing torpedoes’ at the other player's ships. In our game, ‘firing a torpedo’ will be allowing the player to take a guess at where on the grid their opponent may have placed a ship.

In the requirements below, we will set forth other simplifying rules to limit the scope of this project.

Requirements

Given the requirements as a rough specification, you are to design the classes and implement the game. As the Product Manager of this game, you are in full control of

• the choice of classes (please use classes appropriately or points will be deducted)
• data structures,
• algorithms,
• internal file format,
• detailed user interface scheme,
• or any other pertinent design decisions you need to make.

As the Product owner of this game, I care that it compiles and runs like it is supposed to, meets all the functionality and requirements I have set forth, and is easy to play and understand.

• The game is played on four grids, two for each player.
• The grids are typically square and in our case will be 10 by 10.
• The individual squares in the grid are identified by the x coordinate (indicated by a letter) followed by the y coordinate (indicated by a number). The following is an example of a 5 by 4 grid with an X in the position B3.

  

• Each player uses two grids. Each player uses one of their grids to arrange their ships and record the torpedoes fired by the opponent. On the other grid, the player records their own shots and whether they hit or missed.

• Before play begins, each player secretly arranges their ships on their primary grid:
  • Each ship occupies a certain number of consecutive squares on the grid (sizes of ships are in the following table), arranged either horizontally or vertically.
  • The number of squares for each ship is determined by the type of the ship.
  • The ships cannot overlap so only one ship can occupy any given square in the grid.
  • The types and numbers of ships allowed are the same for each player.

Ship Type	Number of Grid Squares
Carrier	5
Battleship	4
Cruiser	3
Submarine	3
Destroyer	2

• The game is played in rounds. In each round, each player takes a turn to fire a torpedo at a target square in the opponent's grid. The opponent then indicates whether the shot was a hit (a ship occupied the square) or a miss (there was not ship in the square). If the shot is a “miss", the player marks their primary grid with a white peg (X in our game); if a "hit" they mark this on their own primary grid with a red peg (O in our game). The attacking player then indicates the hit or miss on their own "tracking" grid with the appropriate color peg (red (0) for "hit", white (X) for "miss") so that they can understand where the opponent’s ship might be.

• In the board game, once all of the coordinates of a ship have been hit, the ship is sunk, and the ship's owner announces “You sunk my battleship! (Or whatever the particular ship that was destroyed).

• For our purposes, we will consider a battleship sunk if the opponent has a single hit. When all of one player’s ships are sunk, the other player wins the game.

• For your game, you will create a one-person version of the game where ‘the computer’ will play for the second player.

Part 1: Ship assignment in the Grid

In part 1, you will read a file called ship_placement.csv which contains:

1. the type of ship,
2. the first grid square for the ship placement, and
3. whether the ship is placed vertically or horizontally (V or H in the field).

The file will be in csv format (comma separated values). This is a common format and is comma separated (instead of being on separate lines). There will be commas between the values. Blank values will just have a comma noting to go to the next field (the game input should not have blank fields so you should handle the case where a field is blank).  

If you want to view the file, often this will be opened by a spreadsheet unless you specifically open it with a text editor. Do not open it with Microsoft Word, as this may change the format. The first line of a CSV file notes the data descriptions as follows:

TypeOfShip, Location, HorizOrVert

Several sample files are posted as well for your convenience and testing purpose. They contains good scenarios and scenarios with placement issues that you will need to handle using exception handling. Your game should run with any of these files, but should also be able to run with any valid file in the correct format.

You will need to check:

• whether all ships were included in the input file (and appropriate action to take if not),
• whether all ships have been placed,
• whether they fit on the board in the configuration given, and
• whether more than one ship occupies a space (which is not allowed) when you read the input file from the user and how to recover if an error occurs.

You will then need to randomly position the computer’s (your opponent) ships on the grid taking into consideration the same factors as you did for the player’s input.

Part 2: Playing the Game

You will need to prompt for and allow for the user to input their next guess in the form of a letter (A through J) and a number (1 – 10) indicating where they are targeting for their torpedo and you should error check the input.

In our simplified game, you will determine if the torpedo shot was a hit or a miss. If the shot was a hit, consider the ship to be sunk. You should display a hit or miss, whether the ship was sunk and which one, and display their tracking grid so they know what they have guessed and where they have made hits. The entire ship which was hit will display as sunk.

After the user takes his turn, you must have the computer randomly select a shot that it has not previously taken. Then you must display to the user what the computer guessed, whether it hit any of the player’s ships, whether a ship was sunk, and then display the player’s placement grid showing where ships are located and what has been hit.

You should continue this until someone wins or quits the game – meaning you should allow the player to gracefully quit at any turn.

At the end of the game, you should indicate the game is over and who the winner was. You should also allow the user to quit the game by entering a Q when prompted for their next guess.

If a player decides to quit the game, the grid with all of their guesses and the locations of the computer’s ships should be displayed.

Overall System Design

1. You must have two different classes in your design.
2. You must use inheritance in one of the classes.
3. When reading from a data file, your program should test the input file to ensure that data is of valid format (basic error detection) using Exception Handling.
4. You do not need to have 4 grids for this but if you decide to use only two grids, you need to make sure you do not show the player the computer’s ship location when you display the grid after each turn.
5. Each component of the overall program should be modular.
6. Program should be fairly fault tolerant of user input and the appropriate user prompts and on-screen directions should be displayed
7. Split the program into multiple files based on the roughly categorized functionality or classes.