When a game has no published mechanics, you end up reverse-engineering it — and the reverse-engineering is more interesting than the solver.
Start by writing down what you observe, not what you assume
My first notes were full of guesses: "the drop rate feels like one in ten". Useless. The version that became a usable guide recorded only what could be repeated:
- Screenshot, board state, and the exact move made.
- The result, including the cases that contradicted the theory.
- The date, because balance patches land quietly.
Twenty recorded boards told me more than two hundred casual plays.
Level rules are usually positional, not random
The hardest part was accepting that some levels are not solved by the obvious move. Once I started logging where pieces were rather than what they were, patterns appeared: certain layouts punish the first move everyone tries.
Write for the player who is stuck, not the one who is curious
A theory page is fun to write and rarely read. The page that gets shared answers one question: "I am on level N and cannot see it." So the guide is organised by level, shows the board, and names the trap in one sentence.
Separate the solver from the explanation
A puzzle solver guide is a tool. The explanation of why a move works is the reason people come back. Keep them on the same page but do not make the tool the whole page.
Notes from documenting a puzzle game from scratch.
Top comments (0)