Our neighbour country has decleared a war agaist us and layed a minefield along the current border. We need to train some fools... *ahem*, pioneers to demine the field so our forces can advance freely. And because field training is so 90s we want to be able to train our pioneers with a high tech minesweeper simulator. Your commanding officer has told us that you know Python so your task is to make that simulator for us. Your country needs you soldier, are you ready?
The minefield is a two dimensional rectangle shaped grid that contains mines. The player must be able to determine the dimensions of the field and the amount of mines on the field. All tiles on the field are initially unrevealed and the mines are on randomly selected tiles. Other tile types include a number tile, which displays the number of mines surrounding it, and an empty tile.
The player can choose one tile per turn by giving its height-width coordinates as an input. The chosen tile is opened and its content is shown to the player. Then one of the following happens:
- If the opened tile contains a mine the game is over and the player lost.
- If one or more of the tiles next to (i.e. horizontally, vertically or diagonally) the opened tile contains a mine, the number of the mines in the surrounding tiles is shown in the opened tile.
- If there isn't any mines in any of the tiles next to the opened tile, all the surrounding tiles are opened and all the tiles next to those tiles are opened and so on until the border of the minefield is reached or the opened tile is next to a mine. The tiles next to mines are also opened but not the tiles beyond them, regardless of their contents. An empty tile can be marked with a space or some other arbitrary symbol.
The game can end two different ways:
- If the opened tile contains a mine the player lost.
- If all mineless tiles on the minefield are opened, the player won.
You might want to do a little more research on the said game before you rush into making one yourself. For example: playing it for yourself certainly wouldn't hurt, Google could help you with that. The following instructions may also contain some important information regarding how you can pass this course, so keep on reading.
We like collaboration on this course. These weekly nice little exercises are actually made in cooperation with several different assistants. It's also probably much more pleasant to solve them together. Your friend may have a better understanding about something, and two pairs of eyes spot bugs more easily anyway. In most cases you realize your mistake when you start to complain to someone that your program doesn't work. Usually things work more smoothly in your head, compared to what it sounds like when you start to explain it to someone else. That's why we don't by any means want to take away the joy of collaboration from you and we actually encourage you to ask help not only from assistants, but your friends as well. We are quite good in giving advice, but your friend is more likely on the same wavelength with you and may be able to give you even better advice than we can.
However, on this course it's required that every student learns to write programs independently. This aspect is good to keep in mind when you are writing code with one or more friends. You shouldn't use code in your program if you don't know what it does. Ask your friend to explain if you don't understand the given piece of advice! Of course, if your friend is a good team player and has read this guide, then maybe he or she can instruct you in a way which you too understand what the code is doing. There's a tedious side to copying someone else's code: everyone loses. The one who copies doesn't get any smarter when he or she can't understand what the copied part of the code does, and the one who let his or her code to be copied can't get to deepen his or her understanding of the issue by shaping it to a more comprehensible format.
Unfortunately these cases are encountered annually, so along with the beautiful thoughts we have explicit and easily understandable rules concerning collaboration on this course. By following these rules you avoid problems - problems usually means, that your course credit can be postponed to the undefined future while the case is being resolved. In the worst case you may have to retake the whole course. These rules can be wrapped up to a few sections:
- Don't copy code from anywhere or anyone and make sure you understand everything you write to your program
- Always report if you have collaborated with someone. There's an individual text field for this in file tasks
- If you take an example from somewhere else (internet), tell this in comments above the code and tell where you found it
Wait, weren't the instructions kind of vague compared to other assignments on this course? Yes indeed, and this section tells you what is expected from an acceptable course work.
First and foremost: in order to be acceptable, the course work must be able to be recognized as Minesweeper. So the game must work at least so that the assistant evaluating your work knows that he's playing the game that was described in this assignment. Fulfilling the following, more detailed requirements shows that the student has learned the things taught on the course.
- The game situation is shown to the player in an (easily) understandable format
- The player can make moves; the canonicality of the moves is checked and illegal moves are prevented
- The game ends when it should (review the "Ending" section)
- If an erroneous input is given the game tells the player what went wrong (e.g. invalid input, illegal move etc.)
- The game keeps a record of the played games: when the game was played (the date and time), the duration (in minutes and turns) and the outcome (was the game won or lost and how many mines there were left on the field). The implementation of the statistics must be selfmade (i.e. using a ready implementation like SQLite or Pickle is forbidden)
- The game contains a main menu where one can choose to play a new game, quit or look at the statistics
Naturally you should start with the basics so the work can be accepted in the first place.
Your course work will be accepted if it fulfills the core requirements specified in this document. Unless your code is extremely obnoxious, any fully functional programs are accepted. In addition to submitting a functional program, you are also required to reserve a 15 minute review session with a course assistant. In this review session you will be asked questions about your code and if you fail to answer properly, you will be required to study your code and reserve a new review session. We are required to make sure students submit code they have implemented themselves, but that's not the sole reason. Simply put, no programmer should never ever submit code they don't fully understand. Remember: You are always responsible for your code.
Quality of the code¶
On this course we aim at teaching ways to produce good code, and we expect to see the results in the final assignment. Barely working implementation doesn't guarantee passing the course if the code is awful; correspondingly you can compensate a slightly incomplete implementation with great quality. There shouldn't be any problems if you've read the course material through with some thought. Below is some guidelines how the different quality factors are graded. The is to get at least "good" from every category.
Variables and naming¶
- bad: It is impossible to deduce what the variables and functions are for or what they contain based on their names.
- good: The names for variables and functions are usually informative about what they are used for, although some of the names can be a bit off. Variables can be named with several different languages and/or the naming convention is not very consistent.
- excellent: The program has a logical and consistent naming convention. The number of variables is low, and assignment to a variable is not used where it's not needed. Similarly, assignment to a variable has been used to simplify long lines of code.
- bad: No use of
else-clauses or is very lacking.
oroperators are not used or understood. As a result, the use of conditional statements is very shaky and might work more by accident than by purpose.
- good: Conditional statements are mostly sensible. Proper use of
else, nested conditionals, and logical operators. Conditional statements can however be a bit shaky or be needlessly complex or long.
- excellent: Conditionals are pretty and succinct. All the previously mentioned tricks are used in a way that they improve the readability of code. They make it possible to detect different states so that the user can be told what is happening in the game.
Data structures (tuples, lists, and dictionaries)¶
- bad: No use or very little use of data structures. This is apparent in the code by having a lot of numbered variables. The few data structures are misused in horrible and naughty ways.
- good: Lists and such are used to create sensible data structures in places where they are obviously needed. In places where the need is not as obvious, there might be use of numbered variables or other comparable means.
- excellent: Data structures have been used in places where they are obviously needed and in places where they make the code clearer and more succinct. Nested data structures are also clearly understood.
Loops and iteration¶
- bad: All loops are made in the same way, forcibly if not else. For example all loops might be made with a
while True, even if the loop clearly iterates a list.
- good: The student is able to recognize when to use
whileand when to use
for. The use of loop variables in for loops might be a bit unclear, or loop creation in general is not optimal.
- excellent: Loops are efficient and the number of iterations in them is as low as possible. Loop variables are used well, especially in the case of nested datastructures. Tricks such as enumerate are used where proper.
- bad: No functions at all, or used just to use functions. No division of code into logical pieces. Using global variables instead of proper arguments for functions.
- good: Functions divide the program into logical segments, even if the segments can be a bit too large at times. The use of arguments and return values is correct. The use of global variables is low and only in places where it makes sense.
- excellent: Functions are divided so that they are all short and limited in their purpose. Only the main function can be a bit longer and fatter, but even it should be within sensible limits. The passing of arguments is sensible in the way that everything does not have to be passed everywhere. If there is any use of global variables, they are clearly in places where they make sense.
- bad: No modules, the program does not function the proper way. Zero points can also come from using
from importeven when it does not make any sense.
- good: The required modules have been found and are used properly.
- excellent: The program uses some more complicated features of modules (for example the formatting in time) or a module has been used to create additional features. The program has been divided into modules of its own, if needed (in the case of clear and succinct code, usually not needed).
- bad: Program has no error handling, and every time something goes wrong, the Python stack trace is shown to the user. The program also doesn't solve erroneous states without breaking, which can result in a locked up or inescapable state in addition to crashing.
- good: Error are handled properly with the exception of some exotic cases. The user always has some sort of clue how to act so that the program does not report an error. Error handling methods might not be the most optimal.
- excellent: Error handling methods have been selected so that the user always gets the best possible information in the case of an error.
try-dblocks mostly contain a minimal amount of code. The program can deal with even the exotic error cases.
- bad: No use of files or reading files is done with some odd way (that was not taught on this course). Alternatively, the code only writes files but does not read them.
- good: Files are read and written in some way that the statistics requirement is filled. Alternatively the game has some other way to use files, like saving and loading.
- excellent: Files are used intelligently so that anyone can deduce just by looking at the files how it should be interpreted by the program.
These can be thought of as extra achievements.
- Readability: The readability of code is very good. This means that names, spaces, and such follow the conventions and guidelines taught on this course. In addition the code has been commented where necessary, and mostly in function documentations.
- 'No bugs: If the assistant testing your program cannot get it to crash or function erroneously (for example to break the rules of Minesweeper) in any way.
- Usability: This is awarded to a game where the user does not get frustrated with the user interface. The usability should be good and the presentation of game state should be clear. For example making a move should be possible with just one short input.
- Joker: One point can be awarded for a neat additional feature, the proper use of a tool not presented on the course, or a feature done in an exceptionally funny or neat way.
Returning the work¶
In order to pass the course the student must undergo a 15-minute personal evaluation session with the course assistant who revised his or her work. You can book your evaluation time with a form which will be added to this site at the end of the course. If you want to return your assignment before that, you have to book your session via email: firstname.lastname@example.org. Also tell us why did you decide to do your course work beforehand and where have you learned the required skills to do the it.