I currently have a game concept similar to the mobile app Alphabetty where you are given a grid of letters and are tasked with spelling words. When you use a letter in a word, it disappears and new letters fall in from the top to replace the used ones.

I have been playing around with ways of making the new letter spawning more "interesting" so that players can get more complex words. I tried making it so each letter spawns based on how common it is, kind of like scrabble but didn't get great results. I have also tried representing each grid tile as a Boggle die which re-rolls each time its used, which was better but far from perfect.

The main issues are:

  • Vowels and consonants often end up grouped together, creating unusable areas on the board. This also goes for letters of the same type (i.e. 3 s letters side by side)
  • With Boggle dice it's very hard to spell words like "Blizzard" as only 1 or 2 dice have rare letters such as z, v, and k etc
  • For the sake of a game mode, I need to be able to seed the grid with words of my choosing slowly (i.e. as new letters fall in) so that players have the ability to spell these special words if they are particularly careful

Are there any solutions, theories or discussions out there that could help?


  • 2
    \$\begingroup\$ Creating a crossword puzzle is already np complete, this is basically a harder version. \$\endgroup\$ – Bálint Feb 15 '18 at 8:28
  • \$\begingroup\$ For reference, this sounds very much like PopCap's Bookworm as well (including the "special words" game mode). \$\endgroup\$ – Quentin Feb 15 '18 at 12:40
  • \$\begingroup\$ Bookworm was one of the games I took inspiration from! Any ideas if they published or talked about how they created their grids, especially for the special words game mode? \$\endgroup\$ – Will Bagley Feb 16 '18 at 8:58

As mentioned in the comments, these sorts of problems are computationally difficult. First, there's no easy evaluation rule for finding legal words - for each potential string, you have to search through your dictionary of legal words. Choosing a good data structure can help (i.e. hash map, trie, etc), but it's still an unavoidable expense. The bigger problem is there are many potential permutations in terms of possible words to check on the board & possible new words that will result after a given move or play.

Some of these problems can be mitigated with design choices & game mechanics, but keep in mind that the game you are presently imagining might not be possible - you may need to make some compromises between your ideal and reality.

Here's a technique I've recommended in the past from Jesse Schell's Art of Game Design (which he in turn credits to game designer Rob Daviau):

List out all of the assumptions you're making & consider ways to invalidate them. Here are some examples based on what you've described (or left out) about the game so far. Your description leads me to assume:

  • The letters can get stuck in certain locations. What if:
    • The player could swap letters, either on the board or from some sort of managed resource?
    • There was a way to destroy unwanted tiles? SpellTower does this with adjacent moves; you could do the same or add your own version.
    • There were rule based changes to the game board? For instance:
      • If a tile was static for too long it could change, either automatically or at the players request.
      • If you had three of anything in a row, the player could change or swap one of them out for another letter.
  • The player can only spell 'correct' words. What if:

    • Your dictionary included common typos, but maybe scored them lower the real words?
    • The player could submit incorrect words, but was penalized for errors?
    • The game could analyze the board, detect moves that would result in 'garbage' words (a run of 5 consonants, etc) and incentivize the player to 'take out the trash'?
  • Tiles only fill in from one direction. What if:

    • The player could alter the gravity?
    • The special word seeding could by-pass the gravity mechanism to get the letters where they are easy to use?

Some of these will undoubtedly be complete nonsense. That's okay. Each bad idea indicate that the corresponding base assumption (which it failed to invalidate) is probably a good game design choice. And some of the time you'll encounter a really interesting twist that you wouldn't have considered. Statitisitcally, very few desicions are likely to be awesome - the more options you sift through, the more likely you are to find one.

Note: it can be difficult to realize your own assumptions about your own work. If you have a prototype, consider letting person A watch person B play the prototype & then ask A what they perceive to be the ground rules of the game.

Another approach is to watch someone play the game & when it fails out (can't spell a target word) ask them what they wish they could do. While it's possible they will have "the perfect answer", it's also unlikely. Often, players want things that break the fun (and design). Instead, focus on why they are making the request and challenge yourself to find ways to address that without removing the fun. Some of these solutions may alter the design - that's part of iterating.

  • 2
    \$\begingroup\$ P.S. Very minor crit: with tries, it doesn't really take that much searching. \$\endgroup\$ – Engineer Feb 15 '18 at 17:37
  • \$\begingroup\$ @ArcaneEngineer Yes, that's an apt observation; I've edited my answer to reflect that, but if you believe it still doesn't reflect what contributes to the computational difficulty feel free to comment or edit accordingly. \$\endgroup\$ – Pikalek Feb 15 '18 at 23:03
  • \$\begingroup\$ Amazingly in-depth response, so thanks! I see that the ideal solution is not possible and so coming up with a good compromise is the next step. I really like your suggested concept of designing around limitations so I guess I'll need to sit down and think about how I can mitigate undesirable scenarios. Not all is lost! \$\endgroup\$ – Will Bagley Feb 16 '18 at 9:07

One small tweak I'd be interested in experimenting with is joint probabilities.

The probability of a Q appearing in any given spot in a word is very very low. But the probability of a Q appearing given that the letter after it is a U is substantially higher. Certain letters "like" being together.

With a little pre-processing on a corpus of words, you can build a table of how often a particular letter appears with particular collections of other letters adjacent to it.

Then, when you're about to drop a new letter into a space, check which other letters it will land next to. Choose the letter from the probability distribution associated with those adjacent letters. (Ensure you always have some chance of any letter, just so it doesn't get locked into rigid patterns)

This will tend to reduce clusters of letters that are hard to use together (like dropping a new consonant into a gap that's already surrounded by other consonants, or likewise with vowels), at least in new drops. It's especially strong when dropping contiguous chunks of new letters at once, especially if you work from the most-constrained letter inward, taking into account your choices of each dropped letter to inform the next drop.

This trick doesn't do much to help with clusters that are formed by eliminating letters between them. For those situations, the mechanics that Pikalek describes will help the most.

  • \$\begingroup\$ Great addition! I think ultimately I'm going to have to find a mix of different ideas. Making the board have better letter groups, as you suggested, paired with designing a few game mechanics that fix unavoidable bad letter groups popping up. It looks like each suggestion coming together will produce a better and better outcome. Hopefully it doesn't get too complex. \$\endgroup\$ – Will Bagley Feb 16 '18 at 9:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.