Introduction

This article explains how the Wordle Game sample was built and what you can learn by digging into it. To access this sample, use the Marketplace tab of the Experiences panel in Composer. You can also download it from the Intuiface Marketplace.

At the time of this writing, WORDLE is an extremely popular word guessing game. The original is hosted by the New York Times and can be played for free.

The rules are simple. You have six attempts to guess a five-letter word. With each guess, you are informed which letters are in the solution and in the correct location, which letters are in the solution but in the wrong location, and which letters are not in the solution at all. For example:

• The letter "E" is in the solution and should stay where it is.
• The letter "N" is in the solution but located someplace else in the word.
• The letters "C", "A", and "S" are not in the word.

Choosing a solution to be guessed

A Random From List interface asset contains a list of five-letter words. With each new game, a word from the "Possible values" list is selected randomly.

Feel free to change the list of words for the "Possible values" property. Of course, you need to ensure each word is exactly five letters long.

Determining letter status for each guess

For this experience, we used the WORDLE solver Web API called wordler, free to use and documented on GitHub. Given a solution (the word to guess) and a guess, the wordler API returns the status of each letter as a set of read-only properties.

The complete process in the "Wordle Game" sample is as follows:

• A guess is typed in then submitted through a press of the green "Submit guess" button.
  
• Pressing that button increases the Attempts Counter by 1 and sends the guess to the Wordler Interface Asset.
  
• The Wordler IA determines the status of each letter in the guess vs. the actual solution. When completed, the Request Completed trigger is conditionally activated based on the value of the Attempts Counter.
  
  Specifically, this trigger simulates a tap on one of six buttons, conditionally choosing a button based on the current number of guess attempts. (The first guess is represented by the first row and the first button. The second guess is represented by the second row and the second button. And so on.) When any of these six buttons is pressed, the colors of each box in the associated guess row are set to reflect the results returned by the wordler API.
  
• The Request Completed trigger also conditionally calls one of two Check Success buttons. The first button is called for guesses one through five, the second button is called for the guess six, the last guess.
  
  Each of these two buttons checks to see if the solution has been guessed correctly. (It does so by walking through the status of each letter in the guess.) If so, the "You Win" layer is displayed. If not, the "You Lose" layer is displayed. The "Last Chance" button exists because "You Lose" should be displayed if the most recent guess is the sixth and last guess.

Notes

• You can view the request URL and syntax for the wordler Web API by right-clicking the Wordler Interface Asset in Composer's Interface Asset's panel and selecting the "Edit in API Explorer" option.
  
• Why use buttons with simulated taps rather than just calling a set of triggers and actions? By associating triggers and actions with a button, it is far easier to manage and test unique configurations, particularly if you have multiple configurations that are quite similar but not identical - such as coloring the boxes in each of six different rows. Having six buttons, each with 8 possible triggers, is far easier to manage than having a single button with 48 possible triggers.
• Guesses are neither checked for spelling nor for the likelihood to be considered obscene.