# Code Puzzles: What (Not) To Do?

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.

• To me, I don't really care about semi-hard puzzles. I actually think the first example is fairly fun to solve. However, when you need to brute-force it at many times the universe, it gets boring. Dec 21 '14 at 0:09
• puzzling.stackexchange.com/questions/5965/… Dec 21 '14 at 0:37
• I think that this answer the question: puzzling.stackexchange.com/a/5884/5044 Should I copy-and-paste it here making the needed adaptations for specifically encoded-messages (if any)? Dec 21 '14 at 0:54
• @Victor Nice examples and great writeup. I think that unless there are large changes for specifically encoded-messages, it makes more sense to link that answer and then add the code-specific advice. Dec 21 '14 at 0:59
• I've begun to wonder if one simple thing defines what makes a puzzle good: all of the information needed to create a logically-deducible solution is in the puzzle itself.
– user20
Dec 21 '14 at 1:11
• @Emrakul That would guarantee a solvable puzzle that would be hard to consider "bad". Then there's the puzzles which give the solver "aha!" moments ("intuitive leaps")... Dec 21 '14 at 1:27
• @Sp3000 Yeah, but even in those puzzles, you can logically deduce how they got to that point. The puzzle still has everything I'd need to solve it, even if I can't personally figure out how it fits together.
– user20
Dec 21 '14 at 1:37
• @Sp3000, one problem I have is that it's very hard to judge the difficulty of those "intuitive leaps".
– A E
Dec 22 '14 at 12:13
• I'm not entirely sure why this is on meta rather than main. The core question ("What makes a good cipher question?") is on-topic for the original scope of the site, and although there's been a lot of discussion about widening the scope I don't think anyone has proposed eliminating the original scope. Dec 24 '14 at 10:34
• Do you still have a question about my puzzle? Aug 15 '16 at 20:24
• What does 'not enough clues' objectively mean? Should anyone guess the code from the first glance? Is it bad to make people work for it, i.e. writing down the examples and looking for patterns, etc.? Sep 22 '16 at 12:36
• I make a comment here as it is relevant to the discussion that sometimes it happens that seemingly complete utter nonsense gets heavily upvoted for no particular reason, see puzzling.stackexchange.com/questions/45926/…. I guess this is a heard thing, and has nothing to do with the quality of the puzzle. Nov 22 '16 at 0:58

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.
• What a fantastic article and a great summary! I'd suggest also including it as an answer to this question on main.
– xnor
Jun 24 '15 at 22:52
• @xnor: I've done so. Thanks for the kudos and the suggestion!
– GentlePurpleRain Mod
Jun 25 '15 at 2:39

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.

## 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.

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.