PROJECT
CSC172 PROJECT
MASTERMIND
1 Introduction
The game MASTERMIND is a code-breaking guessing game that presents an interesting problem in
combinatorics. In the traditional game one player selects four pegs, each of which can have six
possible colors, and places them secretly in a row. Thus each peg has a position and a color. The
opposing player must determine the color of each peg in the order. The opposing player guesses an
answer: a color for each position. The first player tells the second player how many guessed pegs are of
the correct color and in the correct location (traditionally signified by a black token) and also how
many guessed pegs are of the correct color but in the wrong location (white token). The figure shows
a GUI and a game history. The first two guesses were right about the color of two pegs each, guesses 3
and 4 revealed the locations of a peg each, all colors were known after guess 4, and the answer found
on guess 5. Giving thought to guesses after the first is worthwhile because the answers are not
independent. You can learn a lot about the history of the game, along with a few hints about how to
play it at http://en.wikipedia.org/wiki/Mastermind_(board_game).
To think about: What is a strategy that does not repeat guesses but maximizes (!) the expected number
of guesses? How many yes-or-no questions would it take to get the answer in the above game (4
positions, 6 colors)? Hint: 10 and a bit. Why? There are 1296 possible answers, so very clever
questions should be able to discover any of 2048 = 2^11 answers. So what's the form of the 11
questions you could ask? it turns out that we quantify the amount of information you can get with n
yes-or-no questions as n bits (Wikipedia: Entropy(information theory)) . So we need to gain 11 bits of
information with our guesses. It's not obvious, but for the 4-6 game something like 5 questions as
above is a reasonable number to expect.
The internet has a lot of resources for this game. Intellectual collaboration is allowed. You may
discuss the project with other students in the lab. It is acceptable to write code on a white board for the
benefit of discussion, but you are not allowed to transfer code either electronically or on paper copy.
You must hand in a program that you and no one else wrote.
2 What to build
The interface below describes the four components you should implement. Your program is to
be the codebreaker, the human user is to be the codemaker. There are four key methods
required: a constructor that instantiates the codebreaker, a nextMove method that returns an
array of strings describing the next guess, a response method that processes the feedback from
the codemaker in response to guesses (moves), and a reset method to start the game over (not
construct a new game). The user should be able to specify how many colors and how many
positions for the game. (Maximum values are allowed, and you don't need to make the user
enter the peg colors, but you MUST support a variable number of tokens and positions for full
credit. )Your write up should include a discussion of your methods, and also the documentation
html files generated by javadoc.
public interface mm {
public mm(String[] tokencolors, int positions) {}
public void response(int colsOKPositionWrong, int positionsAndColsOK) {}
public void newGame() {}
// Reset the game
public String [] nextMove() {}
// return the next guess
}
The constructor must take an array of color-name strings and a number of positions
as input. For instance, if: tokencolors == {"ORANGE", "PINK","RED", "BLUE",
"GREEN", "YELLOW"}; then the engine returns guesses from this set. It would be
whimsical put possible to pass in tokencolors ==
{"SNEZZY", "SLEEPY", "DIRTY",
"FILTHY", "GRUMPY", "HAPPY", "DOC"}; the computer won't know!
Extra Credit Thoughts: It's not hard to extend your code-breaker program to play
the other side and let the user be the breaker. And at that point the obvious
thing to do is have programs play each other. Have fun.
3 Hand In
Hand in the source code at the appropriate location on the blackboard system at
my.rochester.edu. You should hand in a single compressed/archived (i.e. “zipped”) file that contains
the following.
1. A plain text file named README (see 172/grading.html for the minimal README content).
Also, add some extra README information for this project: your contact information, a brief
explanation of the lab (A one paragraph synopsis. Include information identifying what class
and lab number your files represent.). And a one sentence explaining the contents of all the
other files you hand in.
2. Source code files (you may decide how many you need) representing the work accomplished in
this project. All source code files should contain author identification in the comments at the top
of the file.
3. A plain text file named OUTPUT that includes author information at the beginning and shows
the compile and run steps of your code. The best way to generate this file is to cut and paste
from the command line.
4 Grading
Each method in the interface is worth 20%. The “driver” program that performs user I/O is
worth 10%. Even though this is a command line (text) game, you are expected to have a reasonable and
pleasant human-computer interface (greeting the user prompting the user, providing feedback, etc).
Code is graded as per 172/grading.html.