# Mastermind Group Project

### Overview

For this assignment, you will create a text-based version of the popular game Mastermind.

This is a two-player game in which one player is the code maker and the other is the code breaker. The "code" consists of four different elements. These are typically colored pegs, but for the text-based version will be capital letters.

There is a fixed number of possible different elements that can make up the code. This number must be agreed on before play begins.

For example, if the number of letters is 8, then letters A - H can make up the code. Duplicates are allowed. The following are all valid codes in this scheme:


CHFA
BDCA
EEEE
HAHA


Once the code maker has chosen the code (which the code breaker cannot see), the code breaker begins guessing the code.

For each guess, the code breaker chooses a complete code of four letters.

After a guess, the code breaker gets feedback on how close the guess was. This is done by telling the code breaker:

• How many letters they got exactly correct.
• And how many letters are in the code, but not in the correct position.

If all four letters are correct, the game is over, and the code breaker wins.

Before play, the players agree on the number of rounds that they will play. If the code breaker guesses this number of times without getting the code fully correct, then the code maker wins.

### Details

• The game should first ask the user how many letters are available (up to 26), and how many rounds the game will take.
• Next, the game should ask the code maker to input the code.
• The code breaker is not supposed to be able to see the code that the code maker chooses. This can be difficult since they are playing at the same terminal. Normally, what is entered in the console can be easily read. To avoid this, you can use the following code snippet:

private static String readCode( ) {
Console console = System.console( );
System.out.println("Enter code:");
}

This accepts input without showing what the code maker is writing!
• All input should be checked for errors.
• The game will then consist of turns where the code breaker enters guesses.
• For each guess, the program will report how many are totally or partially correct.
• The game will report a winner when one of the winning conditions has been reached.

### Design Requirements

• You should split the program into different classes, each defined in its own file.
• Each method should have a specific job and not be unduly long.
• All member variables should be private.
• Your code should be consistently indented.

### Groups

• Zach Goodwyn, Jerome Mueller, Russell Ruud
• Pat Galyen, Tyler Hensley, Neil O'Connor
• Annika Lewis, Dan Lustig, Riley Starrs
• Sahar Alkhelaifi, Andrew Ney, Nicholas Randal
• Lizzie Greene, David Heller, Sean Placchetti
• Mike Hudick, Emily Owen, Jack Stanesa
• Douglas Radoye, Harry Rol, Logan Wholey

### Report

Each team member will write a report on the project, individually. This should be from one to two pages long. It should cover the following topics:

• The design of the program.
• An evaluation of the design, what worked well and what didn't.
• How the work was split amongst team members.

### Submitting

When you set your project up on GitHub, you must send me the link to the project page. I will clone your project early in the morning on October 10th.