However, over the course of several days, I was able to develop only 20 puzzles by hand. Trying all the various combinations is clearly a task better suited to computers than humans. Such a grid has 16 slots, each of which can contain one of 26 letters–so there are 26¹⁶ total permutations to check. That’s about 43,000,000,000,000,000,000,000–which could take a very long time, even for a computer. One key to speeding things up is to ignore permutations that don’t contain words.

First I tried using the default dictionary file on my computer (/usr/share/dict/words on Mac OSX), which contains around 4000 4-letter words. I could test all of the permutations of words, placing them a word in each row of the 4×4 grid and then testing the letters in the grid columns to see if they are dictionary words. This reduces the problem to 4000⁴ (~26 trillion), which could still take a very, very long time.

Such a program isn’t very smart, though. Let’s say it checked this grid:

After discovering that BBBB isn’t in the dictionary, in would proceed by replacing BANK with BANS and failing on the same non-word, BBBB. In fact, as soon as it inserts BATS after BABY, it should check and discover than no dictionary word begins with BB, and skip to CABS, then DABS, then EACH–where it finally finds a valid word prefix, BE. We “pruned” B, C, and D. The dictionary file has about 700 words that begin with B, C, or D–so the pruning just eliminated 700 x 4000 x 4000, or 11 billion permutations.

Following this strategy, I created a program in Java to test various permutations but bypass permutations that lead to invalid word prefixes. It looked like it was running properly, but would probably take several days to complete. Additionally, many of the words in the dictionary were uncommon and were creating grids unfriendly for a casual puzzle game (like ACYL).

I was using the Eclipse IDE for this project, and I noticed that most of the unusual words in my list were underlined in red. Eclipse didn’t recognize them as words! Eclipse must have its own dictionary. It took me a while to find it, but eventually I:

1. Grabbed the Eclipse dictionary from http://dev.eclipse.org/viewsvn/index.cgi/org.eclipse.jdt.ui/dictionaries/en_US.dictionary?view=co
2. Reduced it to the 4-letter entries
   cat en_US.dictionary | grep '^[a-zA-Z]\{4\}$' > 4letters.dictionary
3. Sorted it alphabetically (ignoring case)
   sort -f -u 4letters.dictionary -o sorted4.dictionary

The new file contained 1788 words–a smaller list with more recognizable words. This time, my program ran to completion in 5295 seconds (about an hour and a half) and found 498,672 4×4 grids where all the words, across and down, were in the dictionary file! Nearly half a million grids, when I was stuck after coming up with 20 by hand!

Many of the grids contained the same word more than once, though, e.g.:

That’s not a very interesting puzzle, so I added a check to exclude grids that contained the same word more than once. The updated program ran in 4734 seconds (~1 hour and 19 minutes) and found 192,476 grids.

I had an idea to speed things up further. What if, after checking the BA combinations (as in the example above), it skipped straight to EA? That’s when I had an idea to build the dictionary as a tree–my version is technically a graph, because it has an imaginary root. Each node contained a value (a word or word prefix) and pointers to a sibling or a child. For example, this is a visual representation of the graph containing ABLE, ACHE, ACHY, BAKE, BAND, and BANE:

While traversing this tree, if the grid fails at a certain letter, it moves on to the next sibling. If it passes–that is, all rows and columns are either words or valid word prefixes, it moves on to the child. (This is basically Depth-First Search.) This version of the program found the same number of grids–192,476–but in only 497 seconds (8 minutes and change)!

The running time is still problematic, though. If I think of a good 4-letter addition, such as a name (“FRED”) or a phrase (as-is becomes “ASIS”), I don’t want to sit around for 8 minutes waiting to generate all the puzzles again. I could address this by testing only grids that contain the new additions, which should run in a blink.

Also, the successful grids include isomorphic grids. For example,

This isn’t really a tremendous problem, though–a player is unlikely to run into 2 isomorphic puzzles during casual game play.

Now the trick is to come up with clues for all the puzzles, and find a way to let users play on Facebook (where apparently all the casual gaming takes place anymore). For now, though, I’m content to have found a clever way to reduce the running time from 80 minutes to 8 minutes.

I shouldn’t pat myself on the back too much, though–I’m sure someone else has already found a way to do the same in mere seconds.

I recently created a simple word game using Javascript, which presented certain challenges. The game displays 3 random letters to the player, who must then attempt to create a dictionary word in as few moves as possible by shifting the letters up or down in the alphabet.

There were several programming decisions or challenges that came up during the game’s creation, for which I was able to apply some of the things I learned in my recent computer science classes.

The first challenge was how to include the dictionary. The source list I used for 3-letter words (from a Scrabble dictionary) includes 1012 entries. Although I could have developed a server-side solution to check words via AJAX, I wanted the game to be as quick and responsive as possible, and 1012 3-letter words is not all that prohibitive. First, I created an array of all the words; however, that took a lot of extra bytes for all the quotes and commas. In fact, it doubled the space required. I looked at using a prefix scheme (“A” followed by all the two-letter sequences that begin with “A”) to save a few bytes, but the savings was not as great as I had initially anticipated. In the end, I just included the dictionary as a long, unbroken string: since we know that each word is 3 characters, it is easy to access any given word.

The next challenge was how to look up the user’s 3-letter sequence to see if the sequence is in our dictionary. The brute-force approach is to compare it to every word in the dictionary, which would take 1012 comparisons for a sequence that isn’t present. 1012 comparisons isn’t all that bad, but there are certainly more efficient ways, and I was thinking about the implications of expanding to a 4-letter or 5-letter game. Here are some of the look-up options I considered:

• Binary search. Because we are dealing with an alphabetized dictionary, we can start in the middle of the dictionary and immediately eliminate half as possible matches, and then perform the same binary search recursively. Now we need only 10 comparisons for a sequence that isn’t present.
• Hash table. Although we would have to create the hash table at the beginning of the game, this only took 3 comparisons for a sequence that wasn’t present (based on empirical observation).
• Bucket array. I’m not sure what else to call it, but I created a large array (17,576) that could accommodate every conceivable combination of letters. A sequence not in the dictionary remains null, and a sequence in the dictionary gets assigned a 1. This method has larger memory requirements–not extraordinary for 3-letter sequences, but would grow quickly for longer sequences. Now we only need one comparison to determine is a sequence is a dictionary word.

I picked the binary search for its simplicity.

The last major challenge was creating the “fewest moves” algorithm. The game currently tells the user the fewest number of moves it takes to convert the random sequence to a dictionary word. I struggled with this at first, until I realized that the problem is basically just a Breadth-First Search or shortest-path algorithm. I enqueue the initial sequence. For each possible one-move combination, I check it against the dictionary, and enqueue that sequence. (I enqueue an impossible dummy sequence–”###”–to indicate that we need to increment the fewest moves.)

One problem with this is that if it enqueues every one-move combination, it will enqueue many duplicates. Before I checked for duplicates, I found that the fewest moves algorithm often checked more than the 17,576 unique 3-letter sequences. For letter combinations where the nearest dictionary word was 8 or more moves away, Javascript would become unresponsive (or the browser would crash). Since the already-checked sequences were in no particular order, I used the hash table (instead of the binary search) to perform look-ups (although a brute force approach would probably have been sufficient).

Another problem with the fewest-moves algorithm is that my first approach was to use a recursive function. However, Javascript apparently does not always perform well with recursion; Firefox would throw “too much recursion” errors. I changed the function to use a while loop (continue processing while the queue is not empty), which solved that issue.

Although many of these optimizations were not strictly necessary and the brute-force approach would have worked suitably in many cases, I think the optimizations will help the game scale to handle 4-and-5-letter words (although the dictionaries may become too heavy for 5-letter words).

Hunt the Wumpus was originally created in the 1970s, and unfortunately, most of the versions you can find on the web today are easier and less interesting that the original. The original eschewed a square grid for the game board and instead used a “squashed” dodecahedron, where each game space was one of the vertices.

It is also noteworthy for introducing the superbat, a feature of other games (including Zork) that followed Hunt the Wumpus, and for the humorous feedback (e.g. “ZAP–Superbat Snatch! Elsewhereville for you!”) that many of my favorite games adopted.

At any rate, I decided to recreate a version of the easier and less interesting grid-based game in Javascript:
Hunt the Wumpus