Milkbag Games Devlog

Game dev things from Owen Goss and Matt Rix

[milkbaggames]

Sidewords: Making a Good Puzzle

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.

Owen

[milkbaggames]

Sidewords Visual Development

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.

Owen

[milkbaggames]

Doodling some futuristic interior spaces.

[milkbaggames]

Photobomb: A #7dfps and #procjam Game

Matt and I decided to take a break from working on FUTUREGRIND last week and do a game for either #7dfps or #procjam. The idea we ended up with fit both, so we figured, "why not both?" The game we made is called Photobomb and you can grab a downloadable build for Windows or Mac and play it.

I wanted to take a few minutes and write up some of the motivation behind the game. If you haven't played the game yet, this post will contain some spoilers. So if you want to play it unspoiled, go get it and play it now, then come back. I'll wait here.

Done? Good. Let's talk about Photobomb.

The day before #7dfps and #procjam started Matt and I starting talking about ideas for games we could make. We didn't have any ideas for #7dfps, but we had a bunch for #procjam, so we decided to concentrate on that. We came back to an idea we had explored a bit before we started working on FUTUREGRIND.

The idea was based around the "trial by social media" that we've been seeing a lot more recently. I first started thinking about this idea after the Boston Marathon bombing in 2013. In the aftermath of the bombing, reddit users started scouring social media looking for photos posted leading up to, and following, the bombing. Police had announced details of a backpack they thought had contained the bomb, so redditors began identifying people they thought were suspicious. A huge campaign unfolded over hours and huge amounts of social media evidence was collected. The problem was, they weren't able to identify the correct suspects. Not only that, but they flagged a bunch of innocent people as potential suspects.

With other recent high-profile events, like the Ottawa shooting, or the Jian Ghomeshi scandal, we've seen more of this desire for not only quick answers, but for instantaneous justice. We see people making up their minds about events based on what they see and read on social media, well before any kind of actual investigation or trial has taken place.

So we thought to ourselves: can we make a game about that? At first the problem seemed too big to make a short game about. We knew we wanted you to have to try to solve a crime using social media photos. But it wasn't until Matt suggested that we limit the suspects and assign them colours that things started to click. So we ended up with our game mechanic where you, as the player, have a "schematic" view of the event that allows you to scrub back and forth in time, but where no one is identifiable. You have a list of photos posted on a social media that have suspects and important locations tagged in colour. You then have to move to the location at which the photo was taken, at the correct time, and "retake" the photo to paint the colours in the photo into the scene. From that point, any suspects that are painted remain painted forward and backwards in time. Using the various photos, you can try to identify suspects and the various locations they travelled to try to determine which one planted the bomb at which bench.

However, one of the things we wanted to communicate with this game is that social media doesn't paint the whole picture. We deliberatly don't add rules to the random generation of the scene and photos to make sure the game is always solvable. It ends up being that it's *usually* solvable, but there are times you'll play that you just don't have enough information. This is intentional. The game forces you to pass judement on a suspect anyway, because this is what we want in these situations. We want answers. We want someone to blame, and whether or not that's the right person starts to take on a lower priority.

All of this happens in a very limited amount of real time to try to recreate the desire for immediately justice, regardless of consequences.

In the end, the game forces you as the player to pass judgement and identify one of the suspects as guilty, even if you have no idea who it is. The game rewards you for this, even if you are wrong.

In the end, we wanted to try to make a game that was fun to play, but that also commented on the worrying trend toward mob justice on the internet. The game takes it to a future where this is the only form of justice to see what that might look like.

If you haven't played the game, go grab Photobomb and let us know what you think!

Owen