Start from one idea
Good puzzles are usually built around a single insight. Maybe the trick is that a counter can live on the stack, or that a loop can be formed by two arrows facing each other. Decide what you want the solver to discover and write that down for yourself. Everything else in the puzzle exists to support that moment.
A puzzle that tries to test five things at once tends to feel like homework. If you have five ideas, you probably have five puzzles.
Write a precise statement
The most common flaw in amateur puzzles is ambiguity. The author knows what they mean, so the gaps do not show. A solver then spends an hour on an interpretation the author never intended.
A clear statement answers these questions:
- What is the input? Its format, its range, and whether it can be empty.
- What is the output? The exact format, including spacing, line endings and what to do when there is nothing to print.
- What environment is assumed? Which language or interpreter, and any settings that matter, such as how the grid wraps at its edges or how end-of-input is reported.
- What is allowed? Any limits on size, features or running time.
- What counts as done? A concrete condition, not a feeling.
Read the statement as if you were an uncooperative literal-minded reader. Wherever you can imagine a reasonable second reading, tighten the wording.
Give examples, but not everything
Include at least one worked example with input and the expected output. A single example often clears up formatting questions faster than a paragraph of text. A second example that shows an edge case, such as the smallest legal input, is even better.
Avoid giving so many examples that the solver can reverse-engineer the answer without understanding the idea. Examples should clarify the rules, not replace them. Also keep a few cases unpublished for your own checking.
Make the answer checkable
A puzzle is only fair if you can tell whether a submission is right. Think about how you will check before you finalize the puzzle.
- Deterministic output is easiest. If the same input always gives the same output, you can compare against a known-good answer. Puzzles that use randomness need a looser check, such as verifying a property of the result rather than its exact text.
- Prefer properties when answers are not unique. If several different outputs are acceptable, say so, and describe a rule that distinguishes valid from invalid ones. A checker that tests the rule is better than one that compares to a single sample.
- Cover edge cases. Use small inputs, boundary values and any case where an off-by-one error might hide.
- Write a reference solution. If you cannot solve your own puzzle, you cannot be sure it has an answer. The reference also serves as a baseline for any size or speed limits you set.
For interpreted programs in grid languages, checking by hand is possible for tiny puzzles, but a simple script that runs the solution and compares output saves a lot of effort. If you want to build your own runner, the topic of testing an interpreter with small programs has useful habits that carry over.
Choose constraints on purpose
Constraints give a puzzle its character, but each should have a reason. A size limit pushes the solver toward compact tricks. A ban on a particular instruction forces a creative workaround. If a constraint is there only to make the puzzle harder, solvers can usually tell, and it feels arbitrary.
When you add a limit, test whether your own reference solution passes it with some room to spare. Setting the limit at exactly your best result can frustrate people if a small difference in how characters are counted tips them over. Counting rules are worth stating explicitly, and they interact with scoring rules if the puzzle is competitive.
Calibrate difficulty
It is hard to judge difficulty from the author’s chair, because you already know the answer. A few practical aids:
- Give the puzzle to someone who has not seen it, and watch where they get stuck, without helping.
- Aim for a clear path in: a first step that most solvers can take, even if the finish takes thought.
- Consider offering a hint ladder. A small nudge first, then a larger one, lets people choose how much to reveal.
- Offer easier variants. A simple version of the same problem lets beginners start and gives experienced solvers a warm-up.
Remember that difficulty depends on the language. A task that is routine in a conventional language can be a real challenge on a tape or a grid, as with many Befunge algorithms.
Avoid common traps
- Hidden assumptions. If your solution depends on the interpreter initializing memory to zero, say so.
- Accidental trivial solutions. Check whether printing a hard-coded answer passes your tests. If it does, add more varied inputs.
- Unintended loopholes. Solvers are inventive. If a rule can be read in a way that makes the puzzle trivial, someone will find it. Decide whether that is acceptable and, if not, close it.
- Needless obscurity. A puzzle can be hard without being confusing. Difficulty should come from the idea, not from guessing what you meant.
Test, revise, then share
Before publishing, run through a short routine: solve it yourself from scratch, have one or two other people attempt it, fix any ambiguity they report, and check every example by actually running it. Many puzzle authors discover that their sample output contains a typo only after someone else points it out.
Once it is public, be ready to clarify and, if needed, correct the statement openly. Treat solutions as a source of feedback: seeing the approaches people take often shows you aspects of your own puzzle you never considered, and reading solutions can inspire the next one.