ELDROW — The Wordle Solver

Here: https://wordle-eldrow.herokuapp.com/

While enjoying playing Wordle for a couple days, I wanted some dictionary lookup tools that could help me when I’m stuck. I thought about building a Wordle Solver but didn’t expect it actually happens until yesterday.

This blog briefly documents how I built a Wordle Solver less than 1 day. See code at https://github.com/heronyang/eldrow.

Design Goals

The solver should work (of curse) and should be built fast (otherwise I will lose interest and stop investing).

Process

As I was unsure how much time to invest into this solver, I implemented it incrementally — so I can still takeaway something if I stopped in the middle.

Step 1 — The Solver Brain

Interface
I started to code the main logic of solving a Wordle with a bad interface that only programmers can use it.

Language
I picked Dart as I can reuse it later if want to continue to build a Flutter app. Writing Dart takes much more time as I am new to Dart, but this is the additional cost I am willing to pay.

Algorithm
The main solving algorithm was straightforward — it looks up all valid words, applies the game rules to remove illegal words, and prints out the legal words. I didn’t spend time to optimize the algorithm as it’s O(N*M) where N~=100K and M=5 which is pretty easy for today’s devices.

Step 2 — The App (Flutter) Interface

As I found out the solver works fine, I want to make it accessible on my phone so I can use it when I’m out playing Wordle.

User Interface (UI)

In this step, I focus on building the UI for the solver and doesn’t care about the solver brain at all. The UI should be designed with the user in mind, not the solver — so I designed it to look similar to today’s Wordle game for people easy to fill in letters.

Users need to put the green and yellow letters in the correct column as the column means its position in the word, but grey letters can be out-of-order.

Bridging UI and Brain
Once we have the UI and solver brain (a solver with Dart interface), we can bridge them together. That is, within the callback function of clicking on the submit button, we prepare the parameters for the solver brain, calls the solver brain to solve, and parse the result back to the UI.

Here’s an example of how ELDROW solves a real Wordle Game:

Use the information from the first two rows to fill-in the solver. Pick one word from the answer list to solve the game.

Deploy
Finally, I built the code into a web app and deploy it onto Heroku. The commands are:

See the deployed app at https://wordle-eldrow.herokuapp.com.

Step 3 — Continuous Update

Okay, I actually haven’t done this step yet — this is a future step I will continue if its benefit outweighs the cost.

This step includes:

• Sort the answer words with their popularity. (Show common words on top.)
• Maintain an issue list which contains user feedbacks, bugs, wanted features, etc.
• Consider fancy add-on features — e.g. the solver reads a screenshot instead of you typing in the letters.
• etc.

Summary

The MVC concept affects the flow of how I built ELDROW (although this term didn’t actually appear in my mind). I started with the model (M) so I can still have a solver with poor interface to use if I gave up in the middle. Then, I focus on the view (V) where I only think about the user. Lastly, I added the controller (C) to connect the model and the view.

Building an app quickly is fun and fulfilling :)

Follow me on Facebook.