Python辅导 | CSC108H Assignment 2

Python编程完成名为Battleship的游戏

Due Date: Monday, July 15th, 2019, before 10:00 pm

In this assignment, you will be completing a Python program to play the game Battleship. If you’re unfamiliar with Battleship, start this assignment by reading about Battleship on this Wikipedia page or on this board games page. You can play the game online at this games website and at many others. Note that some Battleship games on the Internet let you keep your turn after you hit a ship, but that isn’t how our version works: a turn is over whether it’s a hit or a miss.

You can download all the files for this assignment in this zip file. These files must all be placed in the same folder.

Here’s a description of each of the files provided:

In this handout and in the starter code, we refer to “cell”s in a “grid”, where a grid is a list of list of str and a cell is a str of length 1. A cell is a single grid element and its location is specified by its row and column indices. For example, grid[3][5] refers to the cell in row 3 and column 5. The first (top) row of a grid is row 0 and the first (leftmost) column is column 0. Increasing the row index moves down the grid; increasing the column index moves across the grid to the right.

Constants (fixed values) are variables whose values do not change once assigned. As you have seen, a different naming convention (uppercase pothole) is used for constants so that programmers know to not change their values. For example, in the Battleship starter code, the constant MAX_SHIP_SIZE is assigned the value 10 at the beginning of the module. The value of MAX_SHIP_SIZE should never change. When writing your code, if you need to refer to the maximum size of a ship, use MAX_SHIP_SIZE rather than 10. The same goes for the other constant values. They can be used anywhere in the battleship_functions.py module.

Note: do not change the values of the constants in the starter code, as the test cases may depend on them having the same values as in the starter code.

As the game progresses, a player’s target grid is updated based on their guesses, and their fleet grid is updated when their opponent makes a guess that hits one of their ships.

To gain a better understanding of how the functions you’ll write are to be used, start by reading through the battleship_functions.py and play_battleship.py starter code to see where the functions are called and which values are passed as arguments. Reading and understanding the starter code is an important part of completing this assignment.

In the starter code file battleship_functions.py, complete the following function definitions. Use the Function Design Recipe that you have been learning in class. We have included the type contracts in the following table; please read through the table to understand how the functions will be used. We will be evaluating your docstrings in addition to your code. Please include two examples in your docstrings. You will need to paraphrase the full descriptions of the functions to get an appropriate docstring description. Define these functions in battleship_functions.py only; do not include any new code in play_battleship.py.

Do not provide docstring examples for functions that have a file parameter.

For a fleet grid to be valid, it must contain the correct number of ship characters (based on the second and third parameters) and the correct number of EMPTY characters, and must have ships placed in consecutive cells, either horizontally or vertically (no other orientation). Note that this means that each ship appears exactly once in the grid.

Use the bad*.txt files that you downloaded to help you test your validate_fleet_grid function, although you should not assume that those files test all possible invalid cases!

If a ship is sunk (i.e. the value for that ship in the hits list reaches the size of that ship), then this function should make a call toprint_sunk_message to indicate that a ship has been sunk. The code for print_sunk_message is included in battleship_functions.py. Review its docstring to see what it does.

Each game file (e.g. game1.txt) contains the game parameters and the fleet grid for the player to use. The format of a game file is as follows:

All files provided, and all files we will test your code on, will follow this format, although they may not define a valid game.

The files game1.txt, game2.txt, and game3.txt are valid games of varying sizes. The files bad*.txt are invalid game files.

Your battleship_functions.py file should contain the starter code, plus the function definitions specified above. Your battleship_functions.py file must not include any calls to function print, other than the call in the provided print_sunk_message function.

Do not call input or open in the code that you write. Notice that one of the required functions takes an open file, not a string.

This program is much larger than what you wrote for Assignment 1, so you’ll need a good strategy for how to tackle it.

One way to test your code is to play the game using one of the play_ functions given in the starter code. However, you should also test each function individually by writing code to verify your functions in the if name == '__main__:' block in battleship_functions.py. In fact, playing the game is not a productive way to find bugs or problems you’re writing, because it’s difficult to see what leads to any problems that come up. Once you are confident that your functions are working as they should, then go ahead and play the game to discover more bugs. All verification code, including any calls to the starter code functions, should be entirely within the if __name__ == '__main__': block and not anywhere else in battleship_functions.py.

You can also uncomment the call to doctest.testmod() to run your doctests. Note that this requires your docstrings to be properly formatted!

We are providing a checker module (a2checker.py) that tests two things:

To run the checker, open a2checker.py and run it. Note: the checker file should be in the same directory as your battleship_functions.py, as provided in the starter code zip file. You can find a demo of the checker being run in the Week 3 Prepare exercises on PCRS.

If the checker passes:

If the checker fails, carefully read the message provided:

Make sure the checker passes before submitting.

These are the aspects of your work that we will focus on in the marking:

The very last thing you do before submitting should be to run the checker one last time. Otherwise, you could make a small error in your final changes before submitting that causes your code to receive zero for correctness.

Submit your battleship_functions.py file on MarkUs according to the instructions on the course website. Remember that spelling of filenames, including case, counts: your file must be named exactly as above.