#sidewords

Sidewords

An enjoyable word puzzle game where you have to create words within a grid using the two key words along the X & Y axis.  Difficult in that you need to not only pick words from the available letters but also have to select them in the grid so words don't overlap.  One of those "easy to learn, hard to master" things.  A bunch of levels of growing size and difficulty means this could keep you busy for a while.

Since releasing Sidewords we’ve had a lot of people ask if the puzzles are handmade or procedurally generated. The answer is: sort of both. I thought it might be fun to talk about how we actually make puzzles for Sidewords and how we built some tools to help us find good puzzles.

A few weeks ago I posted a thread on twitter about how we actually generate and find solutions for puzzles in Sidewords. If you’re into computer science stuff, it’ll provide you with a bit of context for what I’m about to talk about next.

https://twitter.com/OwenGoss/status/897157730431107072

The important take-aways from that thread that are relevant here are:

we have a solver that, given a puzzle, finds all possible solutions to a puzzle (if solutions exist)

it’s now fast enough we can generate puzzles on a mobile device

So... let’s work backwards from what we need. A puzzle is made up of two words, and the solution uses those words to fill in a space. When we first started working on the puzzle generator all it did was pick two random words from our word list and then see if it could find a single solution for it. If it did, it would log the words and the solution to a file. Great, we’re done, right? No, we’re only just getting started.

There are many problems with this approach to generating puzzles, but the biggest problems are:

it generates puzzles with really obscure words

it generates solutions with really obscure words

These are big problems that prevent the game from being at all fun.

The tool that we use to generate puzzles evolved over the course of the project, but this is what it looks like in its current state:

Let’s talk about how we get to here...

One of the first things we did was license a word frequency dataset. It contains a list of the 100k most common English words sorted by frequency. It also contains a whole bunch of other useful data about each word. So now we have two word lists in the game:

the list of all words that are valid for the player to enter

the list of 100k most common English words

When the puzzle generator is run, it loads both these word lists and it generates a large data structure that contains all the words in the game, combined with frequency data. Using this, we can quickly check if any given word the player enters is valid, but we can also quickly check a given word’s frequency index. In this way we can ask “is the word CAT in the top 10,000 most common words?”

Next we define a bunch of different “chunks” to the frequency data: top 1k words, top 5k words, etc. These are the different “dict” indices used in the tool. Dict 2 represents the top 15k most common English words, for example. You can see in the tool screenshot above that we can specify different dicts to use both for picking the words at the sides of the puzzle, but also which words can be used to solve the puzzle. In this way we can make sure the solutions only use common words, and never use obscure words that only champion Scrabble players would know.

Ok, now we’re getting somewhere. Now we can generate puzzles that use good words and have reasonable solutions. Now we’re done, right? No.

In the game, we offer hints to the player if they get stuck on a puzzle. The player can reveal words, one at a time, from the “best” solution that the solver found for the puzzle. But how do you pick a best solution?

I mentioned above that our solvers finds all possible solutions (using a word list subset) for a given puzzle. This is important. If we stop when we find a single solution, we might find a bad one. So we find them all, then run some analysis on them to find the lowest-frequency (least common) word in each solution. We deem the “best” solution to be the one with best lowest-frequency word. This means that if one solution’s least common word has frequency index 379 and another has index 12,978, the first solution is better, because the words it uses are more common. Cool. That gave puzzles in the early part of the project that looked like this:

What you’re seeing are the puzzle words on the left, the best solution’s words in the middle, and a mathematical representation of the solution that tells the game where each word goes on the board. So the plan was to generate lots of puzzles like this and then pick the ones we liked. But we still didn’t have a good idea of what a good puzzle looked like. So we started playing lots and lots of puzzles. And we started keeping track of things we liked about some puzzles and not others. Through a lot of playing and iteration we found that good puzzles generally had a few things in common:

the words at the sides sounded good together

they had a large number of different solutions

they had solutions that used common words

Then we also needed a way to get the generator code to help us determine difficulty. Again, through a lot of playing and iterations we eventually found some guidelines that determined the difficulty of the puzzle:

the size of the puzzle

how obscure the least common word in the best solution is

the frequency with which each pair of letters in the puzzle appears in English words

the number of words that can be made in this puzzle using each letter pair

the number of possible solution using common words

So we implemented analysis code that checks all of these things in the generator. 

The word frequency list we had licensed also had word type information in it. We realized that we could use that to generate puzzles that had words that sounded good together. For example, a puzzle of the form Adjective/Noun or Adverb/Verb is more fun to do that two random adjectives together. So we incorporated that into the generation code too. We put everything together and do a little mathemagics and pop out an overall heuristic score that attempts to encapsulate everything into one value of difficulty.

Now the puzzles look like this:

At that point we could generate thousands of puzzles into files and sort them by heuristic score. From there we would read through the puzzles and pick out ones we liked the sound of, put them in the game, and see how they felt. Then we’d organize them into sets and arrange them by difficulty to try to give a nice ebb and flow to the game.

And that’s exactly what we did for all the built-in puzzles. But when we decided to add daily puzzles in v1.1, which are generated on the device, we had to add an extra step.

When we were playing the puzzles ourselves, we could get a feel for how “cohesive” the puzzle felt. Some puzzles had solutions that fit into nicer blocks than others. While some would require solutions that had words split up across the board. These latter puzzles were much more difficult to do. So when we started generating puzzles on device, we needed a way to measure that too.

So now the algorithm does an additional analysis on each solution in the puzzle and it picks the “best” solution as the one that feels the most cohesive. It means that, in general, the puzzles for the dailies have nicer feeling solutions if you make use of the hints.

There’s a lot that goes into making good puzzles for a puzzle game. Obviously I’ve only skimmed the surface of what we did for Sidewords, but I hope that gives you a bit of insight into what we did.

Sidewords is available for iOS, Android, and PC.

Oh hi, we have a new game out called Sidewords! It’s a chill word puzzle game you can play on iOS right now (more platforms coming later this week...)

I stumbled across a PureRef document I’d been maintaining during development of the game, where I’d save new mockups every time we changed the look. It’s got mockups right from the start, all the way up to launch. I thought some other folks might like to see how much the look of a game changes from start to end, even on a small word game project.

Matt and I started working on Sidewords in April, 2017, when Matt first had the idea for the core gameplay mechanic. The very very first version of the game actually looked like this:

This was a very quick prototype I did in Google Sheets to see if what Matt was describing to me over Skype was fun. Spoiler: it was!

So Matt started working on a proper prototype and I started working on some mockups for what the game might look like. The very first mockups were pretty ugly, but were mostly about figuring out what user interface needed to be there and how it would work on a mobile screen.

You can see that it contains most of the elements that ended up in the final game. It’s just really, really ugly.

So I took those initial quick mockups and started doing some reference gathering and from there started working on a new direction. First I tried some more tactile feeling things, and we didn’t like it almost immediately.

In talking with Matt we both agreed that we wanted a more minimal look. The buttons with edges felt too much like real buttons, and that’s not what we wanted. But I kind of liked the shapes and the board and the colours, so I went with that in a new direction.

You can see we were also trying to decide how to handle the words that filled the board. We couldn’t decide whether to fill in big blocks of tiles as single elements (which we did in the end), or individual tiles each having the full word inside. This ended up feeling way too cluttered in the actual game when implemented, so we ended up grouping them up.

Design-wise, by that last mockup we finally felt like we were getting somewhere, but Matt felt really strongly that the game should use lighter colours by default. I had kind of got stuck in the dark theme, but I agreed to try a lighter colour scheme.

At this point that I had to admit that Matt was right (I hate doing that), that the lighter colours worked better and made the game feel more approachable. But, we still felt like there was too much visual clutter with the design. We talked about ditching the rounded corners and trying a more modern, square approach. I also got excited about the colour possibilities with a lighter colour palette.

I got a bit carried away. Matt also wanted to see what a more “spicy” palette might feel like. But eventually we inched our way closer and closer to a colour palette closer to what we’d ship with.

Heyyy, now we’re on to something. But we still weren’t happy with that solid background grey. It felt too washed out, too muddy. It muddled the colours in the foreground too much.

We did some variations with gradients in the background. You can see that we’re mostly refining things at this point. By this point Matt also had the game running, so a lot of the more subtle choices were being made in the game itself and the mockups were mostly being used for colour and font choices. At this point we needed to finalize a font.

Fun fact: none of those are the font we used. The font that is in the game is one called Quicksand, which you’ll see in the next screenshots. By this point we were pretty happy with things, but one of the last major UX challenges we ran into was that people didn’t understand the relationship between the selected letters and the tiles that lit up on the board. So I did some mockups for some different approaches we could use.

These mockups now have our final font in them, and the letters light up yellow to match the yellow lines that extend out of them, and hey, look, better colours (the ones that are actually in the game)! Ultimately we decided on a larger yellow square at intersection points rather than dots, but that was something Matt just did in the game. You can see we also abandoned the checkerboard pattern in the bg of the board at a very late stage. We found during playtesting that it confused some players, and it also added visual clutter. In the end, every tile has a lined background, which I think works the best of anything we tried. In the final game there’s also a subtle, animating background that we never mocked up. Matt just put it in the game one day and we both really liked it.

In the end, I really like where the game ended up visually. It just took some time (and work) to get there.

Sidewords – Milkbag Games

Sidewords Milkbag Games Genre: Games Price: $2.99 Release Date: July 17, 2017 Grab a cup of coffee and relax with Sidewords. Sidewords is part logic puzzle, part word game, all original. No timers. No penalties. No pressure. Just you and a good puzzle. Sharpen your mind with hundreds of puzzles, from small and quick, to large and captivating. There’s even a bonus game included! Choose a color…

Sidewords is out today