Comp 212 Project 1
Hangman

Milestone #1: See Schedule page for due date.

Milestone #2: See Schedule page for due date

This programming project is designed to make use of linear recursive structures.   It also serves as an example of how to write Graphical User Interface (GUI) programs using the Model-View-Controller (MVC) pattern.

Hangman

You are to write a Java GUI application that allows you to play the game of "Hangman." In case you've forgotten, that's the game where there's a hidden word or phase and the player attempts to guess it one letter (character) at a time.  Every correct guess results in that letter being exposed and every incorrect guess results in a body materializing part by part on a gallows. The game is won when all the letters of the answer have been guessed before a complete body is drawn hanging on the gallows.

Click here to run a demo of the Hangman project!

You are required to implement the program in accordance with the following design specifications.

Design Details

At the highest level, the total Hangman game design uses a Model-View-Controller design pattern to decouple the internal workings of the game from the GUI. We will be giving you the system design but that will not be a future trend.

First, go read about the MVC pattern here.

The Model

The underlining data model should consist of the following linear recursive structures.

1. An abstract IWord interface (see the wordlist package.) to represent the input word.  An IWord can be empty or non-empty. When it is empty it contains nothing. When it is non-empty, it contains a character and another substructure IWord called its rest. A non-empty IWord can be hidden or visible. When it is hidden, its String representation is "-" followed by the String representation of its rest. When it is visible, its String representation is the String representation of the character itself followed by the String representation of its rest..  IWord should have enough intelligence to interact with the rest of the system as described below.
   
   
   
2. An IBody can be empty or non-empty. When it is empty it contains nothing. When it is not empty, it contains another substructure IBody called rest.  An IBody can change state from invisible to visible.  IBody should have enough intelligence to interact with the rest of the system as described below.
   
   

The above data models are encapsulated into a single class that represents the operational model of the Hangman game, called (duh) HangmanGame. This class can initialize the game, allow guesses of characters, show what characters in the answer have been correctly guessed, draw onto a supplied graphics surface the body parts associated with incorrect guesses, and finally to indicate whether the game has been won or lost.

Nothing in the model should contain any explicit references to the GUI and vice versa. Instead, communication from the model to the view uses the interface IGameAdapter .

When the noose is drawn, the game is over. But the problem is that the noose is a body part and has no idea how to actually end the game. Hence, the inclusion of the ILoseAdapter (See the bodyparts package ). This command is called when the noose is drawn and is used to signal the rest of the system that the game has ended. But the question is who is signaled? Does the view get notified directly or are there some "housekeeping chores" that need to be performed before the view is notified? Who would do these "clean-up" tasks and does the view already have a means of being notified that the game has ended?

The View

The GUI should have the following features:

1. A GUI component to display the answer as a series of dashes ("-") and letters (if they have been correctly guessed).
   
   
2. A GUI component for the program to draw the various parts of a body.
   
   
3. A GUI component for you to enter a character as a guess and obtain a response from the program.  If your guess does not match any character in the original word, one part of the body will be drawn.  If there is a match, the character will fill the appropriate dashes (displayed in item 1).  The games ends when there is no more body parts to draw, in which case you lose, or when all the dashes are replaced by the actual characters in the word, in which case you win. It is the job of the model to figure out if a guess is correct or not and to provide the proper String and graphical representations of the current state of the game. All the view needs to do is to translate the user's keystrokes and mouse clicks into the correct calls to the model and to perform any commands issued by the model.
   
   
4. A GUI component to indicate if the game has been won or lost. Optionally, the view can indicate winning or losing by playing an audio clip.
   
   
5. A GUI component for you to reset the game and start over.

As the model object is unaware of the GUI (view), so the view object should not know anything about the model that it is displaying.  All communication from the view to the model is through 2 interfaces: IPaintAdapter and IGameControlAdapter.

Anonymous inner classes will be used extensively to connect the view (HangmanGUI) to its GUI components (buttons, text fields, labels, etc.);

The Controller

The controller's job is to

1. instantiate the view.
2. instantiate the model
3. instantiate the 3 interfaces needed for the model and view to communicate.
4. install the 3 objects implementing those 3 interfaces into the model and view, thus establishing the ability to communicate between them.
5. ensure that the system starts up properly.

As in the view, anonymous inner classes will be used to instantiate the 3 interface adapters.

Information/Resources

The full documentation for the project can be found here.

You will use a number of design patterns in this project. Here are links for more information about them:

• Adapter
• Command
• Composite
• Model-View-Controller
• State
• Visitor

JavaResources site on www.exciton.cs.rice.edu

Submission

The project is broken up into two milestones.  Each milestone is to be submitted electronically.  The complete milestone set should contain the following:

• An ASCII README file to indicate what you have and/or have not done, and to point out specific details that you feel we need to know when grading your work. 
  • This README file alone is worth 5 points.
  • Pledge of Honor: add your pledge of honor to the README file.
• UML diagrams of all your class designs with full documentation.
• All the Java source code necessary to compile and execute your test code.

Milestone #1: due see schedule page. (50% of project grade)- Implementation of IWord and IBody, their subclasses and their supporting classes.  Write your own client to test your system. The test client need not be a GUI application. You are free to reuse/modify the code we provide you, implement your own design using your own classes, as long as you adhere to the general program requirements. 

Relevant links:

• Lab 06
• The wordlist package. -- Follow the develop-then-test-then-develop-some-more directions carefully! Do not skip the testing sections! Write an absolute minimum amount before testing it!
• The bodyparts package -- Same sorts of directions as for the wordlist package.

The functionality requirement for this milestone is the "Checklist" at the bottom of the bodyparts package web page.

Milestone #2: due see schedule page. (50% of project grade)- Implementation of a GUI view to control the model. .  You will be given the controller code and are free to implement your own design using your own classes, as long as you adhere to the general program requirements. The controller code should connect the model to the view andl result in a fully functional game.

Relevant links:

• The view and controller packages.
• Adding sounds to your game.
• Lab 07

The functionality requirement for this milestone is the "Checklist" at the bottom of the view and controller packages web page.