Programming of Interactive Systems 

In-class work and Homework 1 and 2: Minesweeper

Your goal is to storyboard and then develop a simple version of an interactive game inspired by the legendary legacy game Minesweeper. Mines are placed in a grid and then hidden, and players try to uncover grid cells without hitting a mine, while uncovered cells can give them clues about the number of mined in the neighbouring cells. A version of the game can be found online here,  and a bit on its history can be found on wikipedia.


You must work individually.

We suggest to implement the user interface in Java. If you want to use another language you should ask the instructors first.

concept and proposed functionality

We expect from the game the following basic characteristics and functionalities. The game is some form of grid of cells that can be empty or contain a mine. Players can open a cell, and this can reveal a mine (if one is underneath) and the game ends. If the cell is empty, and is adjacent to one or more mines, the cell shows the number of adjacent mines. A player wins when he has opened all the cells not containing a mine. The game should indicate its state (lost, in progress, number of cells opened, time spent in game). Players should be able to start a new game, or play games of at least 3 difficulties (size + number of mines). 

You can use any interactions your can think of for doing the above actions. Although this is a basic interface there is a lot of room for improvement or extensions. We are interested in how everything fits together in your system, how creative you are in your interactions and additions to the basic functionality. To get a good mark we expect you to go beyond the above recommended functionalities: they will be judged by their complexity and how they fit overall with your prototype (storyboard or code). 

evaluation criteria

Your work will be evaluated based on the following criteria: 

  1. Breadth and depth of the functionality. You are expected to implement the recommended functionality, and come up with another 2 features in storyboard, and 2 in code (not necessarily the same). But these features have to be well-thought and integrate well into the overall design.
  2. Quality of the design and implementation: clean and usable user interface, appropriate use of UI design guidelines, fluid interaction, well-thought labels and messages.
  3. Quality of the code for H/W 2: well-structured code, separation between model, look-and-feel and interaction components, meaningful names for classes, variables and packages.
  4. Documentation for H/W 2: clarity about what has been implemented, clear instructions about how to run the application (e.g., README file), code documentation.
  5. Bonus points will be given for creative extensions.

Criteria 1 and 2 have a higher weight. However, a poorly documented submission risks to get evaluated more strictly, e.g., if we do not manage to run or use it. If you decide to code in a platform other than Java Swing/Java 2D, make sure that you provide clear instructions about how to run it. Also make also sure that your TA has the necessary hardware to test it!

some text

Homework 1:To do by September 19

The first h/w assignment is a sketch and a storyboard. We ask you to first sketch what your interface would look like. Then we want you to storyboard 4 interaction sequences. The first two should relate to the basic functionality described before. The remaining two should present functionality beyond the basic one. You can be as creative as you want them to be. Do not limit yourself to what you can actually code, you can consider a different input (e.g. voice), revealing additional information on the game (e.g. stats), other gaming contexts (e.g. collaborative), weird grids, annotations, ways to help users, etc.

You need to give enough details in your storyboard so that it is clear how to use your techniques and their results.  The storyboard can be done by sketching on paper, with pictures of paper prototypes, on Powerpoint, etc. You can include scanned sketches or any material you want, but please, include widely supported file formats (e.g., pdf, jpg, ppt, doc).

Examples of interaction storyboards as sketches can be found here. If you want to learn more about storyboards than what we cover in class you can have a look here.

what to submit

Bring your paper version in class. Also create a compressed archive (zip or tar.gz) named or firstname-lastname.tar.gz that includes your storyboards, and email it to Anastasia and Stacy by Mon, September 19 at 23:00 the latest. Use the subject [ProgIS] Assignment 1 in your email. If you have a paper copy as well, bring it in class (we will return it to you).  

some text

Homework 2: Version one to do by October 3, version two by Oct 24

The second h/w assignment (in two versions) is an implementation of your minesweerper. We expect you to implement the basic functionality described before. To get a good mark  you need to go beyond this functionality and implement at least 2 extensions. We will judge your project based on the criteria mentioned above. 

In the first version of the minesweeper, we expect you to have built the window(s) you will need in your game, with their interface components layed out, and at least one type of interaction (it does not need to be the finalized one, e.g., clicking on a button gives you on the console some information about what is under the button). In the second version of the assignment, you need to hand-in the complete game, that includes all interface components and all interactions implemented.  

some advice

Define the limits of your project before starting. Developing more functionalities will not necessarily give you a better mark (or a better product). 

Focus on aspects of the tool that conform to the described requirements. Your implementation should be usable. You should prevent users from reaching unexpected states in the system and provide feedback and feedforward mechanisms to avoid user errors. 

You are encouraged to be creative, but make sure what you decide to do is inside your competence level and abilities. If some aspects seem too hard, try to simplify things. 

Try to structure well and comment your code. 

what to submit

Be ready to show your program running in class. Also create an archive (zip or tar.gz) named or firstname-lastname.tar.gz that includes: 

  1. A short document (1-2 pages, preferably a pdf) with a brief description of your result: what functionalities you implemented, what simplifications you made (bullet points are ok) and how the application can be used.
  2. Your code: both the source code and an executable version (in java a .jar), or your eclipse project. Add any necessary instructions for running your project.

Email your compressed archive to Anastasia and Stacy by Tue October 3 and Monday Oct 24 at 23:00 the latest. Use the subject [ProgIS] Assignment 2 v1 or v2 in your email. Depending on time, you may be asked to give a brief presentation of your project, so make sure you have it handy.