BattleShip Human Player
Game Description
Battleship is a classic two-player game in which you aim to sink all of your opponent's ships before they sink yours.Each player has a fleet of ships that they place on a grid, and they take turns guessing the locations of theiropponent's ships. In this game version, one player is a human, and the other is a computer.
SETUP
Board: Each player has a 10x10 grid (board) where they place their ships.Ships: Each player has a fleet consisting of different types of ships:
Battleship: Occupies 4 cells.Carrier: Occupies 5 cells.Submarine: Occupies 3 cells.Patrol Boat: Occupies 2 cells.Ships can be placed either horizontally or vertically othe grid.
GAME PLAY
Ship Placement: Human Player: The human player manually places their ships on their grid. They are prompted to select the type ofship, its starting coordinates, and its orientation (horizontal or vertical).Computer Player: The computer player's ships are automatically placed on its grid based on predefinedconfigurations read from a configuration file (config.txt).
TAKING TURNS:
Players take turns guessing the locations of their opponent's ships by specifying coordinates (x, y) on the grid.The game announces whether the guess is a "hit" or a "miss." A hit means that part of a ship is located at theguessed coordinates. A miss means there is no ship at the guessed coordinates.
WINNING THE GAME:
The game continues until one player has sunk all their opponent's ships.A ship is considered sunk when all of its cells have been hit.The player who sinks all of their opponent's ships first is declared the winner.Game Specifications:The 代 写BattleShip Human Player game board is a 10x10 grid, each cell represented by square brackets []. The grid is used to place ships andmake guesses. Each cell can either be empty, contain part of a ship, or be marked as a hit or miss.
This is what the empty game board looks like before ships have been placed:Here is a sample board that the human player will see when placing their own ships:
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][P][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][P][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][B][B][B][B][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][C][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][C][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][C][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][C][ ][ ][ ][S][S][S]
[ ][ ][ ][C][ ][ ][ ][ ][ ][ ]TRACK HITS AND MISSES
Another board is used to keep track of the hits and misses.A hit is marked with an X.A miss is marked with an O.Here is an example board:
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][O][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][X][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][O][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][X][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
CONFIG.TXT
A configuration file must be read to set up the computer player's arrangement of the board. The configuration fileshould contain a separate line for each type of ship. Each line should include the ship's name, the x coordinate, they coordinate, and whether the placement ishorizontal (H) or vertical (V).Here is a sample config.txt:
Submarine 2 2 H
Battleship 3 3 H
PatrolBoat 4 5 V
Carrier 5 6 H
This is the result:
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][S][S][S][ ][ ][ ][ ][ ]
[ ][ ][ ][B][B][B][B][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][P][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][P][C][C][C][C][C]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]PROMPT
The program will first read and parse the config file, building the game grid for the computer player. Then, thehuman player will be prompted to input the type of ship, the starting x and y coordinates, and whether the shipshould be placed horizontally or vertically on the game board. After entering the details of each ship, the playerhould see the grid displayed. Once all of the ships have been placed (one of each kind), the player will beprompted to guess the location of one of the computer’s ships by entering the x and y coordinates. If the playerguesses the correct location of one of the ships, the player receives a message indicating a hit. The player shouldbe able to take another turn if they correctly “hit” the computer’s ship. If the player receives a “miss,” the
computer should take a turn, printing out its guess to the player and indicating whether it was a hit or miss. Theprompt should also indicate when a ship has been “sunk” (all spots on the grid for that ship are guessed). Thegame continues until one player sinks all of the opponent's ships. The player who sinks all of the opponent's shipsfirst is declared the winner.
Requirements
The base game components have been provided to you in D2L. Those *.java files contain the clues you need tocomplete a functioning Battleship game. You shouldn’t need to re-write any existing code provided; you must use
the methods and data types indicated. However, you can add any additional classes or enums if you wish.You are to avoid the use of global variables or non-private class variables (using enums is permitted).SubmissionSubmit your completed *.java files to D2L. Do not submit *.class files or any other files. Include your name andUCID at the top of both of those files.DemonstrationYou must demonstrate your assignment to the tutorial leader. The tutorial leader will ask questions to test your
understanding of your submitted code. If you cannot sufficiently answer the questions, your assignment will
receive an incomplete. You will then need to arrange a peer-programming session with the TA to demonstrate
your knowledge of the fundamental aspects of this assignment, where you will be capable of receiving a maximum
grade of C-. Failure to complete this session satisfactorily will result in an F for the assignment.
Unit Tests
To prove your implementation, you must create unit test cases for the code’s functionality.Grading
We will simplify the grading process for this assignment.
A GRADE REQUIREMENTS:
Submission: The assignment is submitted on time to D2L with all required files and a link to GitLab with the TA as adeveloper.Full Functionality: All required functionality is implemented.Code Documentation: The student explains the code with clear comments and documentation.Code Explanation: The student satisfactorily answers the tutorial leader's questions about the code and clearlyunderstands the implementation.
Unit Tests: Adequately tests the program and demonstrates the various principles of unit testing.B GRADE REQUIREMENTS:Submission: The assignment is submitted on time to D2L with all required files and a link to GitLab with the TA as adeveloper.Full Functionality: All required functionality is implemented.
Code Explanation: The student satisfactorily answers the tutorial leader's questions about the code and clearlyunderstands the implementation.One or more of these are insufficient:Test Cases: Some test cases are missing or not comprehensive.
Documentation: Some parts of the code are not adequately documented.
Code Quality: The code is mostly clean and well-organized but may have minor issues in naming conventionsor structure.
C GRADE REQUIREMENTS:Submission: The assignment is submitted on time to D2L with all required files and a link to GitLab with the TA as adeveloper.Code Explanation: The student satisfactorily answers the tutorial leader's questions about the code and clearlyunderstands the implementation.One or more of the following apply:Limited Functionality: File reading/user input is complete, but other methods/mechanics are not.Limited/No Test Cases: Some test cases are missing or not comprehensive.Limited/No Documentation: Some parts of the code are not adequately documented.Code Quality: The code is mostly clean and well-organized but may have minor naming conventions orstructure issues.