Programming Exercise: Hangman

This exercise is intended for you to practice creating active objects, with many small methods, in order to see how design affects your understanding of the code and how hard or easy it is to add new features to a program. It will not be explicitly graded but, instead, serve as a starting point for us to see your coding strengths and weaknesses (and how well you follow directions). Thus, you will get the most out of this assignment by putting in a good faith effort.

Submission

You will be provided a GIT repository, hangman_NETID, hosted in the course's Gitlab group to work on this project. All submissions for this course will be based on only the version of your files in the provided Gitlab repository by 3:07am ET in the morning on the day after that given on the course Calendar (so it is effectively a few extra hours grace time past midnight).

As your submission for this project, use GIT to add, commit, and push the following to your hangman_NETID repository:

• src folder: project code
• data folder: possible word lists from which to choose a secret word
• top-level (no separate folder): project README

Your code is expected to follow the course coding conventions and be reasonably commented (full Javadoc comments are encouraged but not required yet).

Specifications

Individually, build on the lab exercise to make a single Hangman game class that can be used with multiple player objects in order to support playing games between three versions of two opponents: interactive, simple, and clever.

• Interactive Guesser: gets a letter when the user presses a key
• Simple Guesser: chooses a letter in order of its frequency of appearing in English text
• Clever Guesser: chooses a letter that appears in the most possible remaining words that are consistent with the results of previous guesses
   
• Interactive Secret Keeper: prompts the user to input the secret word and does not change it during the game
• Simple Secret Keeper: chooses the secret word randomly from the possible words and does not change it during the game
• Clever Secret Keeper: chooses a new secret word after each guess such that the most words consistent with the results of previous guesses remain as possible choices

The Interactive and Simple versions of each player are implemented in the code given at the start of lab and included in your project repository so that code just needs to be refactored in the appropriate classes. You will need to implement the Clever version of each player (here are more details about the expected algorithm are given in the HOWTO from a previous CompSci 101 assignment).

Additionally, update the OpenJFX display of the game only to draw the traditional gallows and hanged person, instead of just the number of guesses counting down. This is an interesting problem to solve generally (a different form of design) because the drawing should work for any number of allowed guesses (perhaps up to a max of 26)! This is typically done by adding more detail to the hanged person (such as face parts, fingers, and toes) as more guesses are allowed. There are three levels to try for this part depending on your experience, interest, and time (it will not affect your grade):

• Support only one fixed number of guesses: simply draw each piece in order for a missed guess
• Support a fixed set of guess numbers (such Easy, Medium, Hard): allow for some dynamic choice when drawing (i.e., two arms at once or each separate)
• Support any guess number between 1-26 (or whatever reasonable range you choose): dynamically choose how much to draw based on how many guesses are left (i.e., the whole person at once, half the body then the other half, fingers or toes as needed, etc.)

Note, for whatever level you try, you are expected to check the number of guesses given as a parameter to your constructor, print an error message to the console (or pop up a OpenJFX Dialog Box), and then set it to a reasonable value.

We strongly suggest you refactor the code, creating more methods and classes, before attempting to implement any of the three new features (clever players and displayed gallows).

Design Notes

For this exercise, you are not expected to be able to change the players in a game dynamically (i.e., using buttons in the GUI). Instead you will change your code and recompile the program between each run of the game to change which players are competing — but we want to make what needs to be changed as small and as easy as possible for anyone to figure out what is needed (in contrast to the process of digging through the code you went through at the beginning of the lab exercise).

Thus your design goal should be to have your game class constructor take two player objects as parameters, in addition to any other parameters it needs, which will be saved as instance variables. Then the game will call on their methods to do the specific lines you have identified as being that player's responsibility. Again, there are three levels you can aim for in implementing this design:

• Make two player classes: one guesser and one secret keeper, that takes a parameter (int, String, or Enumerated type) to its constructor that is used conditionally in its methods to choose which code to run (including none when some player's response is to do nothing, such as changing the secret word)
• Make six player classes: one for each different kind of player, where each class does only what that kind of player needs to do (meaning all classes will be small, but some may be extremely small since they may have method(s) that do nothing). Note, in this version, the type of the constructor parameter and instance variable used in the game class will need to be changed when the kind of player competing is changed.
• Make eight classes: one for each kind of player and the guesser or secret keeper superclass they extends. This is not an expected solution, since we will be going over inheritance next week, but feel free to try it if you already know how.

Note, for whatever level you try, the main() method should need to be changed to pass the proper object when constructing your single game object (right now it constructs one of two possible game classes).

Your design focus is to make

• the code as readable as possible
• adding a new kind of player as clear as possible
• to change as little code as possible in the program when setting the kinds of players that compete when playing a game