代写program、代做java设计程序

日期：2024-10-22 09:28

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 their

opponent'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 on the grid.

GAME PLAY

Ship Placement:

Human Player: The human player manually places their ships on their grid. They are prompted to select the type of

ship, its starting coordinates, and its orientation (horizontal or vertical).

Computer Player: The computer player's ships are automatically placed on its grid based on predefined

configurations 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 the

guessed 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 game board is a 10x10 grid, each cell represented by square brackets []. The grid is used to place ships and

make 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:

IDENTIFIERS FOR SHIPS:

Ships: Ships are represented by their identifiers in the cells they occupy.

Battleship (B)

Carrier (C)

Submarine (S)

Patrol Boat (P)

Here is a sample board that the human player will see when placing their own ships:

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:

CONFIG.TXT

A configuration file must be read to set up the computer player's arrangement of the board. The configuration file

should contain a separate line for each type of ship. Each line should include the ship's name, the x coordinate, the

y coordinate, and whether the placement is horizontal (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:

PROMPT

The program will first read and parse the config file, building the game grid for the computer player. Then, the

human player will be prompted to input the type of ship, the starting x and y coordinates, and whether the ship

should be placed horizontally or vertically on the game board. After entering the details of each ship, the player

should see the grid displayed. Once all of the ships have been placed (one of each kind), the player will be

prompted to guess the location of one of the computer’s ships by entering the x and y coordinates. If the player

guesses the correct location of one of the ships, the player receives a message indicating a hit. The player should

be 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. The

prompt should also indicate when a ship has been “sunk” (all spots on the grid for that ship are guessed). The

game continues until one player sinks all of the opponent's ships. The player who sinks all of the opponent's ships

first is declared the winner.

Requirements

The base game components have been provided to you in D2L. Those *.java files contain the clues you need to

complete 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).

Submission

Submit your completed *.java files to D2L. Do not submit *.class files or any other files. Include your name and

UCID at the top of both of those files.

Demonstration

You 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 a

developer.

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 clearly

understands 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 a

developer.

Full Functionality: All required functionality is implemented.

Code Explanation: The student satisfactorily answers the tutorial leader's questions about the code and clearly

understands 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 conventions

or 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 a

developer.

Code Explanation: The student satisfactorily answers the tutorial leader's questions about the code and clearly

understands 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 or

structure issues.