handout #17

CSE190L—Object Oriented Programming & Design

Group Project: Qubic

due: Saturday, June 2nd, 11 pm

checkpoint due Friday, May 18th, 11 pm

early bonus date: Thursday, May 31st, 6 pm

This document is subject to revision, so be sure to read the message board for any clarifications or other modifications.

The only assignment you will have between now and the end of the quarter is the Qubic final project.  Recall that this is worth a total of 25% of your final grade.  The project due date is Saturday, June 2nd.  If you manage to complete the assignment early and submit it by 6 pm on Thursday, May 31st, every member of your group will receive 3 extra-credit points (out of a possible 100).  Because of these extra-credit points, it is possible that some students will receive a score higher than 100% on the assignment.  If you do not complete your assignment on time, you can submit it by noon on Sunday, June 3rd for a loss of 10 points.  As with the extra-credit points for early completion, the late points will be applied to every member of the group (each member loses 10 points).  No solutions will be accepted after noon on Sunday, June 3rd.

As mentioned above, the group project will be worth a total of 100 points, distributed as follows:

checkpoint

20 points

final program, minimal requirements

60 points

final program, extra features

20 points

The group will receive an overall score on each part, but the TA has the discretion to assign different points to different group members if there is evidence that some members worked more than others.  The TA will assign different scores only after consulting group members about how much work each group member has completed.  Any group member who disagrees with the TA’s assignment of individual scores should contact Stuart to mediate.

Each team will meet with their TA for two one-hour grading sessions.  The first session is referred to as the “checkpoint” in this writeup.  During the checkpoint session, you must convince your TA that you have made substantial progress toward the completion of this project.  As mentioned in class, you should go through a complete development cycle on some substantial subset of the program (analysis, design, coding, testing/debugging). We will use electronic turning to verify that your checkpoint was completed on time.  You may schedule the checkpoint session with your TA whenever your group is ready.

You will schedule another one-hour meeting with your TA after you have completed the assignment.  Again, use electronic turnin to verify that your project was completed on time.  Your interview does not have to happen the instant you complete your project.  For example, if you finish your project by the early Thursday deadline and submit it electronically, you will receive the bonus points even if your interview doesn’t take place until several days later.

Don’t interpret these two interviews as an indication that you can talk to your TA only during these sessions.  You are required to have two grading sessions, but you can talk to your TA as much as you want.  If you want to schedule additional meetings between your group and your TA, you can do so as often as you like.  You should also not feel that you can talk only to your TA.  All of the TAs will continue to hold regular office hours and you are welcome to ask any one of them for assistance with your project.

The project will involve creating an interactive game that allows the user to play Qubic (4 by 4 by 4 tic-tac-toe) against the computer.  Your solution must implement at least two nontrivial levels of play (e.g., novice and intermediate).  Your two levels of play must be substantially different.  Your program must also provide at least two views of the Qubic board that show each square at least once.  In terms of controls, the user should be allowed to click on a square in any view to move to that square.  There should also be controls for starting a new game, quitting and undoing a move.  The undo command should undo the user’s most recent move and let the user make another choice.  It should be possible to call undo several times in a row, potentially undoing all the way back to an empty board.

There will be a minimum set of requirements for all groups.  Each group must implement at least this much.  If you look at the table on the previous page, you’ll see that if you turn in a perfect solution that meets the minimal requirements and you complete the checkpoint on time, you will get a total of 80 of 100 points.  To receive more points, you will have to implement features beyond the minimal requirements.  This document contains several specific suggestions, but you are not limited to these possibilities.  If you have your own ideas about extra functionality that you would like to implement, you can receive credit for implementing them as well.  When in doubt, talk to your TA.

Your TA will assign the first 80 points.  The points for extra features will be assigned at a joint meeting between Stuart and all TAs.  Basically the TAs will argue for points for their groups and some kind of agreement will be reached.  There will be no predetermined quota.  If somehow every group manages to create a fantastic program, then each can be given all 20 points.  It is more likely that some solutions will be significantly better, so probably about half of the groups will receive 0 to 10 points and about half will receive 10 to 20 points.

In addition to producing code, you also must use Javadoc to comment your programs.  The resulting Javadoc html files will constitute the major documentation of your system.  You probably won’t want to put this off until the last minute.  It is essential that you agree among your team members about how the different parts of your program will communicate with each other.  So you might want to consider writing the JavaDoc comments first as a way to decide among yourselves how the different parts of your system will fit together.

As noted earlier, one score is generally assigned to the entire group.  But if it becomes clear that some group members contributed significantly more than others, we will assign different scores to different group members.

Recursive look-ahead strategy

You are encouraged to implement a strategy described in class where the computer searches for a guaranteed winning strategy that involves forcing the user to make a series of moves that leave the computer ultimately with a win.  This extra feature will be worth 5 points.  You are to implement this algorithm recursively.  The basic algorithm can be described as follows:

method to search for a guaranteed win: {
  if (the computer has a simple win, a 3-in-a-row)
    you’ve found the guaranteed win
  else if (the user does not have a simple win) {
    for (every row with just 2 computer pieces)
      for (each empty square in the row) {
        pretend that the computer takes the square.
        pretend that the user takes the other square in the row.
        recursively call to see if this leads to a guaranteed win.
        if (win was found)
          remember winning move and return;
        undo pretend computer move
        undo pretend user move
      }
  }
}

Minimal requirements

To receive the first 80 points, your solution must meet the following criteria.

·        You must implement a Java program that allows a user to play Qubic with the computer.  You must use the Swing components to implement your user interface elements.

·        Your user interface must include at least two views of the Qubic game (three views for groups of 4).  At least two of these views must show the squares of the Qubic board and must allow the user to select squares by clicking on them.  Examples are a 4-plane flat view, a 4-plane 3-dimensional view and a “sequence of moves” view that shows the history of moves made by the computer and the user.

·        Your program must allow the user to decide whether to go first or second.

·        Your program must keep track of the Qubic game state, allowing only legal moves and reporting the winner.

·        The user must be able to select moves by clicking on a square displayed in a view.

·        The user must be able to undo moves all the way back to the beginning of play.  When a user selects undo, both the most recent computer move and the most recent user move are to be reversed and play reverts to the game state when the user last had a turn.

·        The program must implement at least two distinct levels of play on the part of the computer (three for groups of 4).  These must be nontrivial and distinct strategies, not just random play or minor variations of a single strategy.  The user must be able to select which strategy to play against.

·        The user must be able to save the current game to a file.  The user also should be able to open a previously saved game from a file.  Each request should bring up a file dialog box.

·        The program must have a menu bar with a “File” menu including commands “New”, “Open”, “Save” and “Exit”.  If the user is in the middle of a game and either asks for a new game or requests an exit from the program, the user should be asked whether or not to save the current game.  The user should have the option of canceling the request or asking to save the file, which should bring up the file dialog.

·        The user must be able to select the “close” button in the upper-right corner of the frame and if the user is in the middle of a game, the user should be asked whether or not to save the current game, as described in the previous item.

·         (only for groups of 4) Your program must have another menu that allows the user to select the level of play.  Only one level of play can be selected at a time.  It must be possible to change the level of play in the middle of a game.  For example, a user could play against a novice that makes bad moves and then switch to playing against the expert.  The expert can’t redo the previous moves, but it can take over where the novice left off and make the best of the current configuration in deciding future moves.

These are the functional requirements of your program, the behavior that must be implemented.  There are also design, documentation and testing criteria that must be satisfied.  You should create well-structured code that is well documented and easy to extend or modify.  For example, adding a new strategy option or a new view should not require significant rewriting of your code.  In particular, you should follow the Model/View/Controller design pattern described in lecture.  This design pattern indicates that you have three sets of classes, not that you have just three classes.  The model classes keep track of the state of the game and should not include any references to user interface elements (e.g., the model shouldn’t have words like JPanel and JFrame anywhere).  The view classes keep track of a single view of the game state (probably a JPanel that does a particular kind of drawing, getting information from the model about what to draw).  The controller should handle all user interface events (menu selections, button selections, mouse clicks, etc).  It should tell the model about any changes to the game state and the model, in turn, should tell the views about the updates.

Also remember that you must include Javadoc comments to document your solution.

Extra features

The last 20 points of the project will be awarded based on the implementation of additional features.  You are allowed to pursue any reasonable extension to the program that interests your group.  Here is a very short list of ideas (definitely not complete):

Data Files

You will need to keep track of information about the state of the Qubic board.  To facilitate this, you are being given two data files that store information about rows and about squares.  Squares are specified as three integers between 1 and 4 (plane, row, column).  There are 64 squares in all.  The rows have been arbitrarily numbered from 1 to 76.  The first data file called rows.dat has 76 lines each with a row number followed by four sets of square coordinates (4 sets of three integers) indicating which squares are in that row.  The second data file is called squares.dat and has 64 lines each with a set of square coordinates (three integers) followed by a list of rows that square is in (the number of rows varies from square to square).  You can obtain these files from the class web page.  You are allowed to modify them in whatever way you wish.  They represent a starting point for your representation of the Qubic board.

It will not be possible to use program constants to make the Qubic game general.  If you wanted to play tic-tac-toe on a 6 by 6 by 6 board, it would require significant changes to your program.  So don’t worry about trying to introduce constants for the fact that the Qubic board is three-dimensional or that it has 4 pieces on a side.  Given that, it isn’t likely that the number of squares or the number of rows will change.  But if you find yourself wanting to refer to numbers like 64 and 76, you should use named constants to do so for enhanced readability.