Description
1) Preparation This lab assumes you have Python 3.5 or later installed on your machine. The following file contains code and other resources as a starting point for this lab: lab3.zip (https://6009.csail.mit.edu/fall17/lab_distribution.zip? path=%5B%22fall17%22%2C+%22labs%22%2C+%22lab3%22%5D) Most of your changes should be made to lab.py , which you will submit at the end of this lab. Importantly, you should not add any imports to the file. This lab is worth a total of 4 points. Your score for the lab is based on: answering the questions on this page (0.5 points) passing the test cases from test.py (1.5 points), and a brief “checkoff” conversation with a staff member to discuss your code (2 points).
2) Introduction International Mines tournaments have declined lately (http://www.minesweeper.info/wiki/Tournaments), but there is word that a new one is in the works, and rumor has it that it could be even bigger than the legendary Budapest 2005 (http://www.minesweeper.info/tournaments.html) one! In preparation for the tournament, several people have written implementations of the Mines game. In order to prepare yourself, you decide to look over their implementations in detail. 2.1) 6.00Mines 6.00Mines is played on a rectangular n×m board (where n indicates the number of rows and m the number of columns), covered with 1×1 square tiles. Some of these tiles hide secretly buried mines; all the other squares are safe. On each turn, the player removes one tile, revealing either a mine or a safe square. The game is won when all safe tiles have been removed, without revealing a single mine, and it is lost if a mine is revealed. The game wouldn’t be very entertaining if it only involved random guessing, so the following twist is added: when a safe square is revealed, that square is additionally inscribed with a number between 0 and 8, indicating the number of surrounding mines (when rendering the board, 0 is replaced by a blank). Additionally, any time a 0 is revealed (a square surrounded by no mines), the surrounding squares are also automatically revealed (they are, by definition, safe). Feel free to play one of the implementations available online to get a better feel of the game! 3) Our Implementation of 6.00Mines 3.1) Game state The state of an ongoing 6.00Mines game is represented as a dictionary with four keys: dimensions : a list containing the board’s dimensions (nrows, ncolumns) board : a 2-dimensional array (implemented using nested lists) of integers and strings. game[‘board’] [r][c] is “.” if square (r,c) contains a bomb, and it is a number indicating the number of neighboring bombs otherwise. mask , a 2-dimensional array (implemented using nested lists) of Booleans. game[‘mask’][r][c] indicates whether the contents of square (r,c) are visible to the player. state , a string containing the state of the game ( “ongoing” if the game is in progress, “victory” if the game has been won, and “defeat” if the game has been lost). The state of a new game is always “ongoing” . For example, the following is a valid 6.00Mines game state:
game2D = {‘dimensions’: (4, 3), ‘board’: [[1, ‘.’, 2], [1, 2, ‘.’], [1, 2, 1], [‘.’, 1, 0]], ‘mask’: [[True, False, False], [False, True, False], [False, True, True], [False, True, True]], ‘state’: ‘ongoing’}
You may find the game.dump method (included in lab.py ) useful to print game states.
3.2) Game Logic The game is implemented via three functions:
new_game(nrows, ncols, bombs) dig(game, row, col) render(game, xray) Each of these functions is documented in detail in lab.py and described succinctly below. Notice how each function comes with a detailed docstring (https://www.python.org/dev/peps/pep-0257/) documenting what it does. new_game(nrows, ncols, bombs) creates a new game state. dig(game, row, col) implements the digging logic and updates the game state if necessary, returning the number of tiles revealed on this move. render(game, xray) renders the game into a 2D grid (for display). render_ascii(game, xray) renders a game state as ASCII art (https://en.wikipedia.org/wiki/ASCII_art). 3.3) An example game This section runs through an example game, showing which functions are called and what they should return in each case. To help understand what happens, calls to dump(game) are inserted after each state-modifying step. Running new game produces a new game object as described above:
game = new_game(6, 6, [(3, 0), (0, 5), (1, 3), (2, 3)]) dump(game) dimensions: [6, 6] board: [0, 0, 1, 1, 2, ‘.’] [0, 0, 2, ‘.’, 3, 1] [1, 1, 2, ‘.’, 2, 0] [‘.’, 1, 1, 1, 1, 0] [1, 1, 0, 0, 0, 0] [0, 0, 0, 0, 0, 0] mask: [False, False, False, False, False, False] [False, False, False, False, False, False] [False, False, False, False, False, False] [False, False, False, False, False, False] [False, False, False, False, False, False] [False, False, False, False, False, False] state: ongoing render(game) [[‘_’, ‘_’, ‘_’, ‘_’, ‘_’, ‘_’], [‘_’, ‘_’, ‘_’, ‘_’, ‘_’, ‘_’], [‘_’, ‘_’, ‘_’, ‘_’, ‘_’, ‘_’], [‘_’, ‘_’, ‘_’, ‘_’, ‘_’, ‘_’], [‘_’, ‘_’, ‘_’, ‘_’, ‘_’, ‘_’], [‘_’, ‘_’, ‘_’, ‘_’, ‘_’, ‘_’]]
Assume the player first digs at (1, 0) ; our code calls your dig() function. The return value 9 indicates that 9 squares were revealed.
dig(game, 1, 0) 9 dump(game) dimensions: [6, 6] board: [0, 0, 1, 1, 2, ‘.’] [0, 0, 2, ‘.’, 3, 1] [1, 1, 2, ‘.’, 2, 0] [‘.’, 1, 1, 1, 1, 0] [1, 1, 0, 0, 0, 0] [0, 0, 0, 0, 0, 0] mask: [True, True, True, False, False, False] [True, True, True, False, False, False] [True, True, True, False, False, False] [False, False, False, False, False, False] [False, False, False, False, False, False] [False, False, False, False, False, False] state: ongoing render(game) [[‘ ‘, ‘ ‘, ‘1’, ‘_’, ‘_’, ‘_’], [‘ ‘, ‘ ‘, ‘2’, ‘_’, ‘_’, ‘_’], [‘1’, ‘1’, ‘2’, ‘_’, ‘_’, ‘_’], [‘_’, ‘_’, ‘_’, ‘_’, ‘_’, ‘_’], [‘_’, ‘_’, ‘_’, ‘_’, ‘_’, ‘_’], [‘_’, ‘_’, ‘_’, ‘_’, ‘_’, ‘_’]]
…then at (5, 4) (which reveals 21 new squares):
dig(game, 5, 4) 21 dump(game) dimensions: [6, 6] board: [0, 0, 1, 1, 2, ‘.’] [0, 0, 2, ‘.’, 3, 1] [1, 1, 2, ‘.’, 2, 0] [‘.’, 1, 1, 1, 1, 0] [1, 1, 0, 0, 0, 0] [0, 0, 0, 0, 0, 0] mask: [True, True, True, False, False, False] [True, True, True, False, True, True] [True, True, True, False, True, True] [False, True, True, True, True, True] [True, True, True, True, True, True] [True, True, True, True, True, True] state: ongoing render(game, False) [[‘ ‘, ‘ ‘, ‘1’, ‘_’, ‘_’, ‘_’], [‘ ‘, ‘ ‘, ‘2’, ‘_’, ‘3’, ‘1’], [‘1’, ‘1’, ‘2’, ‘_’, ‘2’, ‘ ‘], [‘_’, ‘1’, ‘1’, ‘1’, ‘1’, ‘ ‘], [‘1’, ‘1’, ‘ ‘, ‘ ‘, ‘ ‘, ‘ ‘], [‘ ‘, ‘ ‘, ‘ ‘, ‘ ‘, ‘ ‘, ‘ ‘]]
Emboldened by this success, the player then makes a fatal mistake and digs at (0, 5) , revealing a bomb:
dig(game, 0, 5) 1 dump(game) dimensions: [6, 6] board: [0, 0, 1, 1, 2, ‘.’] [0, 0, 2, ‘.’, 3, 1] [1, 1, 2, ‘.’, 2, 0] [‘.’, 1, 1, 1, 1, 0] [1, 1, 0, 0, 0, 0] [0, 0, 0, 0, 0, 0] mask: [True, True, True, False, False, True] [True, True, True, False, True, True] [True, True, True, False, True, True] [False, True, True, True, True, True] [True, True, True, True, True, True] [True, True, True, True, True, True] state: defeat render(game) [[‘ ‘, ‘ ‘, ‘1’, ‘_’, ‘_’, ‘.’], [‘ ‘, ‘ ‘, ‘2’, ‘_’, ‘3’, ‘1’], [‘1’, ‘1’, ‘2’, ‘_’, ‘2’, ‘ ‘], [‘_’, ‘1’, ‘1’, ‘1’, ‘1’, ‘ ‘], [‘1’, ‘1’, ‘ ‘, ‘ ‘, ‘ ‘, ‘ ‘], [‘ ‘, ‘ ‘, ‘ ‘, ‘ ‘, ‘ ‘, ‘ ‘]]
3.4) Check Yourself Before we dive in to the code, answer the following questions about the representations and operations described above. Consider the following four boards, where grey boxes represent bomb locations and white boxes represent open squares:
Which of these would result from calling new_game(3, 4, [(1, 2), (0, 1)]) ? –
A new game is created with 5 , 5 , and a list b passed in as arguments, and it creates the following board layout, where grey squares represent bombs and white squares represent open spaces:
What was the value of b that led to this board?
Consider the following board, where grey squares represent bombs and white squares represent open spaces. Assuming that no squares had previously been revealed, if a player were to dig at location (3, 0) , how many squares in total would be revealed?
Enter an integer in the box:
On the same board, if a player were to dig at location (2, 6) , how many new squares would be revealed? Enter an integer in the box:
4) What you need to do As usual, you only need to edit lab.py to complete this assignment. However, the nature of your changes to that file are somewhat different in this lab. lab.py contains a nearly complete, working implementation of the 6.00Mines game. Your job in this lab is threefold: 1. Complete the implementation of 6.00Mines in lab.py by writing the render and render_ascii functions; 2. Refactor the reference implementation of 6.00Mines to make it easier to read/understand; and 3. Implement a set of functions that tests a 6.00Mines implementation for correctness and returns a description of the bugs it contains (if any). 5) Render
Your first task is to complete the definitions of the render and render_ascii functions in lab.py . The details of the desired behavior for each function is described in that function’s docstring. In addition, each offers a few small tests (in the form of doctests (https://docs.python.org/2/library/doctest.html)), which you can use as basic sanity checks. Note that you can run the doctests without running test.py by running python3 lab.py . It is the lines at the bottom of lab.py that enable this behavior. Here is how the output of render_ascii might look (with xray=True ):
1.1112.1 1112..1 1.22.11…1 2221.211 1.12.31 112.2112432 1.111211 111111 222 2.2 111 1.1 111 1.1 14.3 123211221 11112.1 111 2..2 1..212..1 1.11.21 2.31 1223.32221211111 111 2.3111.1 111111111 111 112.1111 1.11.22.21111 1.1 111 111112.4.11.1 11211 12.323342 1.1111 113.3… 1122.1 111 2.33.3 2.31 111 1.1 111222 112.2 1.1 11211111 112.1 .1111 111 1.11.1 1.211
Once you have completed these functions, you can play your game in the browser by running server.py and connecting to localhost:8000 . 6) Refactor Although the implementation provided in lab.py is correct, it is not written in a style that is particularly conducive to being read, understood, modified, or debugged. Your next task for this lab is to refactor the given code (i.e., to rewrite it so that it performs the same function but in a more concise, efficient, or understandable way). In doing so, try to look for opportunities to avoid code repetition by introducing new loops and/or helper functions (among other things). Look also for opportunities to avoid redundant computation. Note that, after you make a change, your code should still pass all the same tests (since refactoring should not change the behavior of the code, merely its structure and appearance). If you get stuck looking for opportunities for improvement, take a look at some of the suggestions we give, on this “hints” page (https://6009.csail.mit.edu/fall17/labs/lab3/hints). 7) Bug Hunt Your final job (for this lab, at least!) has to do with debugging several implementations of the 6.00Mines game. In the resources directory in the lab distribution, there are several implementations of the game, each of which may contain one or more bugs (or may be completely correct). Your goal in this last part of the lab is twofold: Examine the implementations in the resources directory in the lab distribution and try to enumerate all of the bugs in these implementations to the point where you’ll be able to describe in detail both the nature of the bug(s) and a possible solution to each, but you do not actually need to fix the bugs. You
should be prepared to discuss your findings in detail with a staff member during a lab checkoff (you may wish to leave comments in those files near the bugs so that you remember them when the checkoff comes around). Complete the testing code near the bottom of lab.py to automate this process by programmatically testing whether a given implementation correctly implements the different behaviors described above. Note that you can try playing the game with these implementations in server.py , which can help with finding bugs. If you add new implementations to the resources directory, they will also be available for you to use from the browser. You can switch between running with the rendering functions defined in the module and a fully working implementation of the rendering functions by clicking the button near the bottom of the page. You may assume that the render and render_ascii functions are implemented correctly in each implementation, so there is no need to implement tests for them. There are several behaviors we would like each implementation to perform correctly, and each has an associated method in the TestMinesImplementation class near the bottom of lab.py . After looking over the implementations, you should fill in the definitions of the methods in the TestMinesImplementation class. Each test is described in detail in its docstring. The test should pass if that behavior is implemented correctly in the given implementation, and it should fail otherwise. Note that these behaviors should be considered independently; for example, a failure in an implementation’s new_game method should not be taken into account when testing the dig implementation (i.e., tests for dig should test dig on well-formed inputs, regardless of the correctness of the other pieces of the implementation being tested). You should also structure this code to avoid repetition where possible, and in such a way that each of the above tests can also be performed independently of the others. If you are having trouble coming up with test cases, look at some of the hints on the “hints” page (https://6009.csail.mit.edu/fall17/labs/lab3/hints). 8) Auto-grader (unit tester) As in the previous lab, we provide you with a test.py script to help you verify the correctness of your code. The script will call the required methods in lab.py and verify their output. Again, we encourage you to write your own test cases to further verify the correctness of your code and to help you diagnose any problems. 9) Code Submission Select File No file selected 10) Checkoff Once you are finished with the code, please come to a tutorial, lab session, or office hour and add yourself to the queue asking for a checkoff. You must be ready to discuss your code and test cases in detail before asking for a checkoff. You should be prepared to demonstrate your code (which should be well-commented, should avoid repetition, and should make good use of helper functions). In particular, be prepared to discuss: Your implementation of render and render_ascii The changes you made to refactor new_game The changes you made to refactor dig The bugs you found in mines1
\ / /\__/\ \__=( o_O )= (__________) |_ |_ |_ |_
Powered by CAT-SOOP (https://catsoop.mit.edu/) (development version). CAT-SOOP is free/libre software (http://www.fsf.org/about/what-is-free-software), available under the terms of the GNU Affero General Public License, version 3 (https://6009.csail.mit.edu/cs_util/license). (Download Source Code (https://6009.csail.mit.edu/cs_util/source.zip?course=fall17))
The bugs you found in mines2 The bugs you found in mines3 The bugs you found in mines4 The test cases you constructed related to new_game The test cases you constructed related to dig 10.1) Grade You have not yet received this checkoff. When you have completed this checkoff, you will see a grade here.
