Phrase Puzzler
In this assignment, you’ll be writing a Phrase Puzzler game. To see how the game is played, please watch the demo below.
The video demonstrates playing the one-player version of the game, but your code will eventually also have a two-player human vs. human version and also a human vs. computer version.
This assignment is meant to give you practice working with strings, functions, and if statements.
Starter code
For this assignment, we are giving you some files, including some Python starter code files. See the Downloads section below for instructions on how to get the files.
There are two starter code files: puzzler.py, which contains the main program, and puzzler_functions.py. You’ll need to add the functions described below to the puzzler_functions.py file. Do not modify the file puzzler.py. The puzzler.py main program depends on functions you will write, so this program won’t run properly until you’ve implemented the functions.
We are also providing two files that contain puzzle phrases: puzzles_small.txt and puzzles.txt. The puzzles used in the Phrase Puzzler game will never involve uppercase characters.
Constants
Constants are special variables whose values do not change once assigned. A different naming convention (uppercase pothole) is used for constants, so that programmers know to not change their values. For example, in the Phrase Puzzler starter code, the constant VOWEL_PRICE is assigned the value 1 at the beginning of the module and the value of VOWEL_PRICE should never change. When writing your code, if you need to refer to the price of a vowel, you should use VOWEL_PRICE, rather than 1. The same goes for the other constant values.
Using constants simplifies code modifications and improves readability. If we later decide to use a different vowel price, we would only have to change the price in one place (the VOWEL_PRICE assignment statement), rather than throughout the program.
Some notes about the Phrase Puzzler program
- Two strings are used to represent information about a Phrase Puzzler puzzle:
- the puzzle string, which is made up of alphabetic and non-alphabetic characters (e.g., spaces, punctuation and digits). An example puzzle string: ‘e-mail inbox’.
- the view string, which is the current view of the puzzle as seen by the players. In the view string, the alphabetic characters are either displayed or hidden (using a caret (^) by default) depending on whether they have been revealed or not. Non-alphabetic characters (spaces, punctuation and digits) are always displayed. For example, at the beginning of the game, the view string for the puzzle above would be (with a caret to represent a hidden character): ‘^-^^^^ ^^^^^’.
As the game progresses and players guess letters to be revealed, the view is updated. Continuing with the example above, if the player guesses “m”, the view becomes ‘^-m^^^ ^^^^^’ and then if “i” is guessed, it becomes ‘^-m^i^ i^^^^’.
- When a player guesses a consonant, each occurrence of that consonant in the puzzle earns a certain number points for that player.
- Players have to pay to guess a vowel. The cost does not depend on the number of occurrences of the vowel.
- When a player solves the puzzle, bonus points are added to their score for each occurrence of a consonant that is still HIDDEN.
- The puzzler_functions module contains several constants:
- DATA_FILE: the name of the file that contains the puzzles for the game
- CONSONANT_POINTS: the number of points for each occurrence of a hidden consonant in the view when that consonant is revealed.
- VOWEL_PRICE: the cost (in points) of guessing a vowel. This number of points is deducted once from that player’s score regardless of whether there are 0, 1, or more occurrences of the vowel in the puzzle.
- CONSONANT_BONUS: the bonus (in points) for each occurrence of a hidden consonant in the view when the puzzle is correctly solved. This number of bonus points, multiplied by the remaining number of hidden consonants, is added to the score of the player who solved the puzzle.
- PLAYER_ONE, PLAYER_TWO: the players
- CONSONANT, VOWEL, SOLVE, QUIT: the moves a player can make
When you run puzzler.py, one of three game types (a one-player, a two-player human vs. human version, or a two-player human vs. computer version) is played. Before you can play each of the three game types, you’ll need to implement the following functions:
- one-player: is_win, game_over, bonus_letter, update_letter_view, and calculate_score.
- two-player (human vs. human and human vs. computer): the functions listed above plus next_player.
See the table below for a description of these functions.
Files to Download
Please download the Assignment 1 Files and extract the zip archive. The following paragraphs explain the files you have been given.
Starter code: puzzler_functions.py
This file contains some constants, and a complete docstring (but not body!) for the first function you are to write. You will update this file to include the complete functions that you write. When you have written all of the functions, you may try playing the game with more challenging puzzles by changing the constant DATA_FILE to ‘puzzles.txt’!
Starter code: puzzler.py
This file contains the main program and when it is run, the functions that you wrote and put in the puzzler_functions.py file will be called. Do not make any changes to the puzzler.py file.
Data: puzzles_small.txt and puzzles.txt
These files contain Phrase Puzzler puzzles.
Checker: checker.py
We have provided a checker program that you should use to test your code. See below for more information about checker.py
What to do
In the starter code file puzzler_functions.py, complete the following function definitions. Use the function design recipe that we have been learning in class, and write complete docstrings for each function.
We have included the type contracts in the table; please read through the starter code to understand how they will be used.
No Input or Output!
Your puzzler_functions.py file should contain the starter code, plus the function definitions specified above. puzzler_functions.py must not include any calls to the print and input functions. Do not add any import statements. Also, do not include any function calls outside of the function definitions.
How should you test whether your code works?
You should test each function individually by writing code to verify your functions in the Python shell. For example, after defining function is_win, you might call it from the shell (e.g., is_win(‘e-mail inbox’, ^-m^il i^^^^’)) to check whether it returns the right value (False). One call usually isn’t enough to thoroughly test the function - for example, we should also test is_win in cases where it should return True.
Once you’ve checked each function individually, play the game using the puzzler.py starter code to see whether it works as expected. If not, go back to testing the functions individually.
CSC108 A1 Checker
We are providing a checker module (checker.py) that tests two things:
- whether your functions have the correct parameter and return types, and
- whether your code follows the Python and CSC108 style guidelines.
To run the checker, open checker.py and run it. Note: the checker file should be in the same directory as your puzzler_functions.py, as provided in the starter code zip file. You can find a demo of the checker being run in the Week 3 Prepare exercises on PCRS.
If the checker passes:
- Your function parameters and return types match the assignment specification. This does not mean that your code works correctly in all situations. We will run additional tests on your code once you hand it in, so be sure to thoroughly test your code yourself before submitting.
- Your code follows the style guidelines.
If the checker fails, carefully read the message provided:
- It may have failed because one or more of your parameter or return types does not match the assignment specification, or because a function is misnamed. Read the error message to identify the problematic function, review the function specification in the handout, and fix your code.
- It may have failed because your code did not follow the style guidelines. Review the error description(s) and fix the code style. Please see the PyTA documentation for more information about errors.
Make sure the checker passes before submitting.