Code Puzzles: What (Not) To Do?

Question

Here's a code. Can you crack it?

fw8904730983kf89023ncweamnfiope20tmi9b6m89ny327nery895mbi9tm0ei09x2e1m3y8n2

Good luck!

When a puzzle looks like this… AUGH.

I believe that the main purpose of this site, apart from entertainment and sharpening our puzzle-solving skills, is learning what makes a good puzzle. This site is a great place for aspiring puzzle creators to practice on a wide audience of tireless testsolvers and get constant feedback.

Coded message puzzles can be fun, but with many of them (like the fake example above), I get the feeling that the designer doesn’t care about making a good puzzle. In particular, they probably did not think about how a solver would approach their puzzle.

What am I supposed to do? Throw spaghetti at the wall until it comes up English? This is not enjoyable. There is no starting point. There are no clues, or not enough.

A variation: some recent puzzles (example, example, example(?), example) have followed the following pattern:

• Post a code that’s so hard that nobody can solve it.
• Wait a day and post a hint.
• Repeat until somebody finally solves it.

I don’t think this fixes anything. Before any hints appear, the puzzle is way too hard. At some point along the line, the puzzle becomes possible. Indeed, it may become a really fun puzzle at this point. But if that's the case, why not at least try to figure out when the puzzle becomes fun, and then post that?

On to my question(s): what are some examples of code puzzles that are enjoyable to solve? (Cough cough, shameless plug, like this one) What should aspiring code designers do, and what should they avoid? As a solver, what do you want to see when you open up a new code puzzle?

The idea is to make this a meta post that we can link to whenever someone posts a probably-low-quality code puzzle.

Answer 1

An article on this topic that I've found very useful is this one.

A brief summary:

• Puzzles should be compelling. Provide something that hooks the solver, and makes them want to solve the puzzle.
• Avoid red herrings that cause people to spend significant time going down the wrong path without getting closer to a solution.
• If the puzzle requires an intuitive leap, it's better if that leap is not too difficult. A puzzle with an easier "intuitive leap" and a hard "processing" section is better than the opposite.
• A puzzle should provide some indication of progress. If there are multiple steps, it should be obvious when one step has been correctly completed. A multi-step puzzle with no feedback along the way can be nearly impossible.
• A puzzle should consume all the information provided. There should not be extraneous information that doesn't help find a solution; it will make the solver feel like something has been missed.
  • A puzzle that reuses information (information is interpreted in two different ways to provide two different steps to solving the puzzle) is especially clever.
• A clever tool can be recursion. If the first step of the puzzle leaves you with a certain amount of information, re-applying that step can be the way to get the final solution.
• A theme helps hold the puzzle together and makes it more compelling to the solver. Sometimes tying all elements of the puzzle into one common theme can be difficult, but the more you can do it, the more interesting it is to the solver.

Answer 2

What should aspiring code designers do, and what should they avoid?

This is the question I'll be answering. It's an incomplete answer, but it wasn't an easy question.

Do provide enough clues to hint at how the text is ciphered

If you're thinking "Oh I'll just post and if nobody gets it I'll add more clues," then please add enough clues from the get-go. Your puzzle is probably harder than you think it is — after all, you know the solution.

Now, by clues I don't just mean something explicit like "Hint 1: The first letter is P". It could be anything, even something as subtle as a change in font to hint at Morse code by lining up the dots of ij with the crosses of ft, or a grid of width 26 to hint that each column mapped to a letter. Even a gentle nudge in the right general direction is better than having to search at random.

If you use a well-known cipher, think about how obvious it is to work out which one you've used. Using Morse code as-is might be okay because the dots and dashes act as implicit clues. However, there are too many ciphers which just output a string of letters, so if you use any of them clues are a must.

If you've invented your own cipher, then you'll definitely want to put in clues.

Don't leave arbitrary decisions from constructing the cipher unclued

Rather than explaining this one, let's have an example.

Say you've got a new spin on Braille, where dots 1 to 6 are represented by 6-letter words with letters A-M meaning the dot is present and N-Z meaning the dot is not. For example, monkey clues o because o in Braille has dots in positions 1, 4 and 5, and the letters from monkey which are in the first half of the alphabet are in positions 1, 4 and 5 (namely mke).

This seems like an okay cipher idea — but why did you choose A-M to denote a dot being present and N-Z otherwise? Why not have it the other way around, with N-Z denoting the dot being present? Or A-J? Or even vowels versus consonants? Even if I told you the cipher was Braille, there would be a lot of things to try.

Think about the decisions you made when constructing the puzzle. If you any of them were arbitrary, then clue.

^{For instance, in our Braille example we have some freedom in the words we choose, so we could do something like hiding a message in the first letter of each word.}

Answer 3

Do something novel

Cliché is boring. We've all seen loads of Morse code, Caesar cipher, Braille, binary ASCII, and so on. These are so well-known, they are effectively encodings rather than codes. They're a good start for getting into ciphers, but we're here to push forward the envelope of puzzling, not to rehash tired classics. A cipher solved by going down a laundry list of well-known codes is tedious and unrewarding. A good code requires a creative insight to crack.

There's lots of room to invent novel ways to encode things. Even within the limited format of substituting letters individually, they plenty of exciting new possibilities. (examples: 1, 2). You might say, "But those aren't ciphers!", and indeed they aren't tagged as such. But they encode letters in a way to analogous to Braille or Morse code, except the encoding is logical rather than conventional. The solver can determine it without having seen it before.

This isn't to say that you should completely avoid classics like Morse code. They can be the basis for a good cipher. But they should be ingredients rather than the whole dish. Use them as part of a larger structure or invent a new twist that makes solvers approach it differently. For example, solving this variant of the substitution cipher took a new type of analysis that extended the usual technique of frequency analysis.

Some cautions though about using a classic code, even if you follow the above advice. Regarding variants, "Morse code with dot as X and dash as Y" is not an interesting one, and it's been overdone. The twist should actually use a cipher in a new way. Also, making a small tweak to a code just risks feeling arbitrary, different for the sake of being different. That is, unless the change is well-clued and make intuitive sense.

Also, concatenating multiple well-known encodings, done one after the other, doesn't make a good code. The solver still goes down the laundry list, but with a larger search space. And if the first step of decoding gibberish is another layer of gibberish ciphertext without any indication that you've made progress, the solver may well be discouraged from the correct path.

Finally, incorporating a cipher as part of a larger puzzle doesn't mean making it a disconnected step. For example, "take the answer to this riddle and use that as the key for the following cipher" means that the decoding (with key) is just rote work after you solve the riddle. Or, if the cipher can be broken without the key, solvers can just ignore the riddle. It's unlikely for the two parts to form a cohesive unit, where a solver can combine partial progress in the riddle and cipher to get a full solution.

Answer 4

Here's another perspective, short and sweet:

A jumble of text like that, with no clues as to how it can be decoded, is like a wall.
If there is a wealth of reward on the other side, i.e. further puzzles or even tie–ins with something not pertaining to a puzzle, then it might motivate people to throw effort at discovering the keyword or whatever.
However, it acts as a filter for those who have computers configured for that purpose; it doesn't really benefit those who simply take pleasure from the challenge so much as those who have assets that enable them to obtain more.
Furthermore, I think that most of the users here don't like this site to be a component of larger games off–site. So, unless the reward is an ability to proceed with the remainder of the puzzle as posted, it probably shouldn't be done here.