Wednesday, October 21st — 11:59pm
This project is designed to give you some hands on experience with…
- Using Xcode & Interface Builder
- Declaring and wiring outlets and actions
- Testing applications in the iPhone Simulator
- Creating a settings bundle
- Using the preferences (defaults) system
- Using action sheets to display actions
For this assignment you will be writing a Hangman app for the iPhone. Your application needn’t look identical to the one shown in the description, but must it contain the following elements…
- Buttons for letters of the alphabet
- A button to start a new game
- A label where the word being guessed is shown (with underscores for the unguessed letters)
- A label that tells the user if they won or lost when a game ends
- An image that shows the hangman
Additionally, your application must also include a settings bundle that allows the user to adjust following information…
- A multi-value specifier that allows the user to select a word difficulty of Easy, Medium, or Hard
- A multi-value specifier that allows the user to select the number of guesses. Your app must support values of 3 and 6, but you
are welcome to support others as well
Main App Behavior
When your app initially loads it should look similar to the screen shown below. When the app is launched, it automatically starts a new game. A word has been chosen at random from the appropriate word list (as defined in the settings bundle) and has been masked with underscores. Your app (and settings bundle) should default to 6 guesses and the Medium difficulty list.
When the user presses a button, it should be immediately disabled and the button’s appearance should be changed in some way to let the user know that letter has already been chosen (mostly transparent in my implementation). If that letter occurs in the word, then all instance of that letter are revealed in the masked word. Below we see the result of pressing the “R” button.
If the user presses a button and the letter doesn’t appear in the word, the hangman image should be updated with the next image in the series. Again, the button is disabled and the appearance is changed so the user knows it has already been selected. Below we see the result of pressing the “D” button.
As shown below, if the user guesses all of the letters of the word before reaching the maximum number of wrong guesses they should be presented with some text that states that they won. Upon starting a new game, this message should be cleared.
If the user reaches the maximum number of wrong guesses before guessing all of the letters, they should be presented with some text that states that they lost (again, this text should be cleared when starting a new game). Additionally, the user should be shown the word.
If the game is over (i.e. the user has either won or lost) and they press the new game button, a new word should be selected and the UI should return to the new game state like when we initially launched the app.
However, if the user presses the new game button before the game is over (i.e. the user has not won or lost, but can still guess), then they should be presented with an action sheet that asks them to confirm starting a new game. If the user cancels they should be returned to their game – only if they accept should a new game be started. This confirmation is show below.
Settings Bundle Behavior
When your app is selected in the Settings app, it should look similar to the image shown below. The user should be presented with options for selecting the word difficulty and number of guesses.
If the user selects the number of guesses, they should be presented with a screen that allows them to specify the number of guesses. Again, your app must support values of 3 and 6, but you are welcome to extend that if you like.
If the user selects the word difficulty, they should be presented with a screen that allows them to select between Easy, Medium and Hard as shown below.
Below are the images I created for my Hangman implementation. You are welcome to save and use these or come up with your own.
Regardless of the number of wrong guesses, you should always be sure to present the user with an empty hangman image when starting and a full one if they use all their wrong guesses. In my implementation, I simply skipped some images in-between.
I’ve provided both plain-text and plist versions of an Easy, Medium and Hard word set. Feel free to use these, modify them, etc. You’re also welcome to store your data in another format (SQLite database, via Core Data, etc.).
Whatever you choose, just be sure that your game contains a large number of words and that you bundle the necessary resources.
The word lists below were derived from the wordlist.sf.net project’s 12Dicts Package. Specifically, I used the 2of12.txt list with this rip-words.pl Perl script I wrote to extract and format the output.
The first thing I’d probably do is to print out images of the main screen and start to think about about and identify…
- Where do you need (and not need) outlets?
- What instance variables you will need?
- What action methods (and which of the 3 forms) do you need?
- What interactions call which action methods?
Next, I’d probably recommend building the app and getting things up and running using a single hard-coded word. Then add in the ability to randomly load a word from some source. I’d probably create the settings bundle next and have that save out the preferences. Lastly, I’d probably tie the preferences specified data into the app.
Some final hints…
- You have several options for random numbers on the iPhone OS — these include:
drand48()family. Some are self-seeding, others need to be explicitly seeded (consult the documentation).
- Instances of
UIViewhave a property called
subviewsthat return all sub views. This combined with introspection may be useful in programmatically getting a handle on a bunch of elements.
- The word lists I provided are all lowercase, but everywhere in my app letters are displayed in uppercase. It is probably wise to choose either uppercase or lowercase letters and be sure to convert to it when doing compares, etc.
The following items are provided as thoughts as to how you might extend or improve the project beyond the basic requirements. You are not required to implement any of these.
- Create additional word lists (i.e. programming languages, state names, etc.) and add them as options
- Try out alternate color combinations — just don’t make my eyes bleed
- Feel free to play with the layout and style of elements — just be sure that things are neatly aligned and that there is at least some justifiable method to your madness
- Add more or different images to the app if you think it will improve the look and feel of the application
- I’m open to using alternate input/display mechanisms — just send me an email to tell me what you’re thinking and I’ll let you know if it is acceptable
Your projects will be graded on the following criteria:
- Correctness of application
- Appearance of application
- Adherence to Objective-C and iPhone coding conventions
- Neatly formatted and indented code
- Well documented header files
- Absence of significant performance issues
- Absence of memory leaks
Like the previous assignment, you are required to submit a zip file of your project directory. Be sure to manually remove the build directory before zipping things up.
To submit the assignment, open up a terminal, navigate to your zip file then issue the command:
submit cs491i assignment5 Assignment5.zip
If developing on your own Mac, you’ll need to transfer the file into your GL account (via SCP), then SSH into GL and issue the submit command.