Milestone #1: See Owlspace for due date.
Milestone #2: See Owlspace 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.
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.
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 underlining data model should consist of the following linear recursive structures.
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 .How To Lose When You Don't Know How...
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 GUI should have the following features:
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's job is to
As in the view, anonymous inner classes will be used to instantiate the 3 interface adapters.
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:
JavaResources site on www.exciton.cs.rice.edu
The project is broken up into two milestones. Each milestone is to be submitted electronically. The complete milestone set should contain the following:
Milestone #1: due see Owlspace. (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.
The functionality requirement for this milestone is the "Checklist" at the bottom of the bodyparts package web page.
Milestone #2: due see Owlspace. (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.
The functionality requirement for this milestone is the "Checklist" at the bottom of the view and controller packages web page.