Mastermind (Due 13 November 2011)

You will design and implement a program to play a text based version of the board game Mastermind. You may use any classes from the standard Java library. You may also work with a partner.

The version of the game you implement will have the following properties.

The output of the game should be a simple text based display. Look at this page for sample output. (User responses are in bold italics.) Your program does not have to match this output exactly. You can make changes to the style of the output if you like.

Part of the assignment grade will be determined by how easily your program could be altered to allow a different number of pegs in the code and how easily different colors could be added, assuming they start with a different letter than other existing colors. (Up to 26, one for each capital letter. Are there any colors that start with an X?) For example how easily would it be to change the code to have 5 pegs and allow pegs to be the color Maroon?

Part of the assignment grade is based on breaking the problem up into a number of small, simple classes. One of the criteria of the assignment is to break the problem up into multiple classes even if you think the problem could be solved more easily with no discernible structure or one big class. For this assignment you should err on the side of having lots of simple classes instead of a few complex ones.

The top level class of your program must be called Game. It must have a constructor that takes a boolean. The boolean is used for testing purpose. If it is true, then the secret code is revealed throughout the game. The Game class must also have a method named runGames() that carries out the actual games. Your program must run correctly when the main method of class Mastermind.java is called.

You must provide a description of the tests you ran. Even though your testing code will not be executed you must include your testing code in your submission (simply comment it out) and a file that describes your testing strategy. Saying " I ran the program and it worked." is NOT a valid testing strategy. On this assignment you can't share testing code because you are all doing your own design.

Include all the source code for all the classes you created in Mastermind.java, and TestSummary.txt. Include a README file and a data file if you used one. Create a zip file and name it ASSGN4.UTEID.zip, where UTEID is your UT EID. If you work with a partner turn in only a single version of the code.

We will be looking at good documentation, design, and adherence to the coding convention mentioned below. Here is the initial structure of your program. Your code must have the following header:

/*
  File: Mastermind.java

  Description:

  Student Name:

  Student UT EID:

  Partner's Name:

  Partner's UT EID:

  Course Name: CS 312

  Unique Numbers: 

  Date Created:

  Date Last Modified:

*/

You will follow the standard Java Coding Conventions. You can either view the HTML page or download the PDF or Postscript and print it out. There is a modification that I would like to make to the standard coding conventions. Please align the opening and closing braces vertically so that you can easily make out the blocks of code. For example:

Do this:
if ( x > 5 )
{
  a = b + c;
}

Not this:
if ( x > 5 ) {
  a = b + c;
}

Use the turnin program to submit your Mastermind.java file. The TAs should receive your work by 11 PM on Sunday 13 November 2011. There will be substantial penalties if you do not adhere to the guidelines. The TA in charge of this assignment will be Yun-sik Choi (yunsik@cs.utexas.edu).

Tips

  1. This is a difficult assignment because you must design (and design is messy!) and implement the program. You have designed algorithms but this is the first time you must design classes from scratch. Spend some time away from the computer, with pencil and paper, brainstorming what classes you need, what instance variables they need, and what methods they should have.

    Recall when designing a program in an object oriented way you should consider implementing a class for each type of thing you see in the problem. For example in Mastermind there are pegs, colors, codes (the secret code and the player's guesses can both be considered the same data type, a code), a board, results, a computer player, a human player, and an over-all game. Some things are so simple you may choose not to implement a class for them. For example the computer player doesn't do anything more than pick the secret code. Maybe that is simple enough for the Game or Board class to do. Also you may use some pre existing type, primitive or a class, to represent things. For example, you may choose not to have a color class. You could represent colors as single char, String, int, or possibly use the built in Java Color class. For this assignment you should err on the side of having lots of simple classes instead of a few complex ones.

    Avoid putting too much in the Game class. The suggested solution consists of 6 classes in addition to MasterMind and Game.

  2. After deciding what classes you need, implement them one at a time, simplest ones first. Test a class thoroughly before going on to the next class. You may need to alter your design as you implement and test classes. Remember Design a little - code a little - test a little. Repeat.

    I can't stress this point enough! The whole point of object oriented decomposition is to simplify the problem, but you need to make sure one class works before going on to another. To do this you will have to write code to test the class even though that testing code will not be used in the final program. Don't try to code all the classes and then test by running the game.

  3. You are free to use inheritance if you wish, but are not required to. (On this assignment inheritance and polymorphism are marginally useful at best.)

  4. This assignment is different than others because you are responsible for designing and implementing all tests. (Do this as you go! Not at the end! Saying "I ran the program and it worked." is not a valid testing strategy.)

  5. If you have never played mastermind one of the hardest things is understanding the feedback. The feedback gives no information about which peg in the guess generated the feedback.

    Assume we use capital letters for colors: B = blue, R = red, G = green, P = purple, W = white, and K = Black.

    Assume the secret code is BRGR. The guess PBRP generates the feedback WW. All I know is I have two pegs of the correct color, but I have no idea from that guess alone which of the two pegs are the correct color. The feedback is not xWWx. Given the same secret code the guess PRBP generates the exact same feedback as PBRP, WW.

    When showing the feedback, give the number of black pegs first, then the number of white pegs as shown in the sample output. With the same secret code of BRGR, the guess RBGP would generate the feedback KWW (K for black).

    Finally a given peg in the secret code can generate at most one feedback peg with black given priority over white. Given the secret code BRGR the guess GGGG would generate a feedback of K only.

References