CS 124, Spring 2017
Labs 13 and 14: Hangman Continued
For the final two labs of the semester, you should continue working on the Hangman game that was begun in Lab 12. The due date for Hangman.java has been changed the last day of class. It is due by 3:00 PM on Monday, May 1.
(Lab 11 is due at 3:00 PM on the last day of classes, Monday, May 1. You might want to use part of the lab time this week to get some help on your Sprite game, but hopefully you will spend most of the time on Hangman.)
Lab 13: Game Logic
Ideally, you should already have the GUI for your program pretty muchh ready to go. The next part of the project is to implement the game logic. That is, you should make it possible for the user to play the game. You should have a working game by the start of Lab 14.
We briefly discussed in class some of the global data that you will need to implement the game. In addition to the buttons, this includes at least the word that the user is trying to guess, the letters that the user has guessed so far, the number of incorrect guesses that the user has made, and a boolean variable to record whether or not the game is over. Remember that global data are stored in instance variables. The values of the variables change in response to events, and they can be used by paintComponent to decide what to draw. You should carefully analyze what has to happen in your event handler and what the paintComponent() method needs to display at any given time both during a game and when a game is over.
You will also need a source of words for the game. If you have not already done so, you can copy the folder named words from /classes/cs124/words into the src folder in your project. This package and how to use it were already discussed in Lab 12
Lab 14: Polish
For the final lab of the semester on April 27, you will hopefully have a working game by the time you arrive at the lab. You can use the last lab to add polish and maybe some additional features to your program.
The program that you turn in for this project should be well-documented, and it should carefully follow all the other rules of good programming style. The code should be well-organized and efficient. Define subroutines where appropriate to avoid having long segments of code in one method.
A correct but minimalistic game will not receive full credit. The game should look nice, and it should be fun to play. It should keep the user informed about exactly what is going on.
Think about adding some extra features. I've mentioned providing the user with a choice of several different word lists to choose from. You might implement levels of difficulty by varying the number of incorrect guesses that are allowed. You could think about adding Midi sound effects (using ideas from Lab 8). Maybe even some animation (Section 6.5.1).