Challenge 04

**Due: 2025-05-12 at 11:59p

Download Starter Files Submit on Gradescope

Objectives

• Demonstrate your ability to design and write a program on your own
• Demonstrate your ability to design a solution based on interconnected objects
• Demonstrate your ability to manage complexity

Challenges

Challenges are your moment to demonstrate your ability to apply the concepts from the class independently. We may provide a framework that allows us to test your code and a description of the problem to be solved. The design of that solution is left up to you. We will not tell you how many functions to write, their names or what their parameters should be, nor will we dictate any implementation details beyond the requirements placed on what data you wll be given and what form we expect any data to be output. The only requirement is that your submission be entirely your own work.

Requirements

Challenges will only be marked Satisfactory, Incomplete or Unassessable.

To be marked Satisfactory,

• your code must meet the functional requirements
• your code must pass the style tests
• any function you write must have well formed docstrings that describe the purpose of the function, the name and type of each parameter and the return value
• your design should demonstrate good choices with respect to choices of abstraction and implementation (i.e., what to create as a function, how to handle repetition, how to break up conditions, etc…)

There are many ways to demonstrate good choices. At the largest scale, we will looking at how you use abstraction. Your functions should just do one thing, and that thing should make sense as a part of the problem you are solving. Your objects should make sense as separate entities, tied to data and a particular responsibility. If you can’t describe what your function or object does in a simple sentence, it is probably too complex. On a small scale, good choices illustrate your grasp of how your tools work. For example, we might look at unnecessary type conversions (like converting a string literal to a string, e.g., str("already a string")).

For this challenge, there will not be time for our usual revision cycle. In addition, there is not a clear path to using an autograder on your work. We will provide some tests that you are required to pass, but most of the requirements will need to be inspected by eye. As such, you will need to be even more mindful than usual about making sure your (a) understand the requirements and (b) are checking frequently to make sure your code is meeting them. You are encouraged to share your progress with us and get feedback as you work.

The Problem

For this challenge, you are going to use pygame to implement a version of Wordle.

If you are not familiar with Wordle, it is a word guessing game. You have six chances to guess a five letter word. On each guess, the letters in the guess will be colored to indicate if the letter is placed in the correct spot, present in the secret word, but not in the correct spot, or not in the secret word at all.

The Requirements

This challenge is all about managing a lot of interconnected pieces rather than about something with complex processes like the last two challenges. However, we do have a lot of requirements that we will be looking for complete solutions to satisfy, so read through these carefully and get clarification for any you don’t understand. I might even suggest making yourself a checklist so you can check things off as you complete them.

Gameplay requirements

• There is a secret word to guess, and it comes from the provided list of valid five letter words
• The user is allowed six valid guesses
• A valid guess is a five letter word from the word list
• Guesses that are too short should not be accepted as guesses and the player should receive a warning
• Guesses that are not words should not be accepted as guesses and the player should receive a warning
• Correct guesses should be acknowledged and no more input accepted (though the main loop should not exit)
• After six incorrect guesses, no more input should be accepted (though the main loop should not exit) and the player should be informed of the actual word
• Submitted guesses must be colored to reflect three different situations:
  • the letter is in the same place in the secret word
  • the letter appears in the secret word but not in this location
  • the letter does not appear in the secret word at all
• Duplicate letters should be handled correctly for both guesses and secret words (e.g., “sleet”)
  • any letter in the correct position must be colored appropriately
  • letters in the secret word can only be matched once
  • out of position letter will be matched left to right
  As an example, consider the situation where the secret word is “stone” and the guess is “sleet”
  • the “s” will be colored as “in place”
  • the “l” will be colored as “not in word””
  • the first “e” will be colored as “out of position”
  • the second “e” will be colored as “not in word”
  • the “t” will be colored as “out of position”

Interface requirements - Each guess is displayed as a row of five boxes - Each letter box can be one of four colors: the three guess colors and a neutral color for guesses that have not been submitted - Colors must be chosen to be distinct, but the letters should always be easy to read - Guesses can be made by typing on the keyboard - If the user types more than five characters before submitted, only the first five characters are used - Submissions can be made with the Return key - Backspace will delete characters in the current guess (it will not back up through submitted guesses) - All messages to the user should be made on screen not in the shell (i.e., the player should not be expected to read the output of print())

Provided you meet the above requirements, you can make your Wordle clone look however you like. The “classic” colors are:

• “in place” - green
• “out of position” - yellow
• “not in word” - dark grey
• neutral guess - white
• neutral keyboard key - light grey

As long as it is clear what each of these five colors are distinct and obvious in their purpose, you can do whatever you like.

Similarly, you are not bound to the same layout or the appearance of the keyboard. Feel free to be creative.

Hints, Tips and technical details

Design first - then code The most important piece of advice I have is that you should start with paper, tablet, or white board before you write any code. Draw a picture of the interface. You should also list out the classes you are going to write. Start by thinking about the responsibility each has - perhaps identifying which interface element they provide. Then work out what properties they should have, what methods, and how they will work together with the other classes. You don’t need a perfect plan when you start coding (things will change when you start implementing anyway), but the most forward planning you do, the easier this will be.

Finish Lab 9 We designed the lab to give you some of the tools you need to succeed at this. make sure that you have finished the lab (and understand it) before attempting this. Pay particular attention to

• how fonts as handled
• how text is “drawn”
• how clicking on tiles is handled

You are likely to have more than one font (if only to support different sizes). I strongly advice following the approach in the lab where the font is stored in a dictionary with a key that describes what its intended use is.

Text input There are a couple of different events that listen to the keyboard

• pygame.KEYUP - a key was released
• pygame.KEYDOWN - a key was depressed
• pygame.TEXTINPUT - a key was typed

For the first two event types, the key itself is available with event.key. There are number of variables we can use to tell if the key was a special key like backspace (pygame.locals.K_BACKSPACE) or return (pygame.locals.K_RETURN). You can find the full list of supported keys in the documentation.

If you use pygame.TEXTINPUT instead (recommended for non-special characters), then the text can be read from the event with event.text.

Don’t forget the basics With the introduction of pygame and objects, there are a lot of new things to think about here. However, don’t get blinded by the new things. Under the hood, it is going to be the lists, dictionaries, and loops doing the bulk of the heavy lifting. Don’t neglect them.

Have fun with this This will be the longest and most complicated thing you will have built all semester if you chose to take it on. It is also the most rewarding.

Submission

The only file that you need to submit is challenge04.py (and any other files you may have written as part of your solution). You do not need to submit the word list.