In my previous puzzle games (Mathventure and Subarashï) I explained the game rules up front. So the players are aware how the puzzles work before diving in. In Mathventure the puzzle is often figuring out which route to take that results in you getting the value necessary to win the level, while Subarashï's puzzles are about deciding what to blow up and in which order. It's similar to Sudoku: once you figure out how to solve a Sudoku, you can use your existing knowledge of it to solve every other Sudoku. A 5* Sudoku is just a 1* Sudoku made harder, you can still apply the same rules to solve it.
But recently games there have been some puzzle games that, instead of introducing new mechanics of the game, build puzzles around the player realizing new game dynamics. That might need some explanation: in puzzle game X, you have block type A. The first puzzles are about block type A, then block type B is introduced, there are some puzzles about B, and then there are some puzzles about how A and B work together. Game X introduces new mechanics during the game to keep it interesting. Now take Game Y where mechanic A is introduced in the first level and every level after that teaches a new way to interact with A. You will need A to be somewhat deep to keep it interesting (the deeper it is, the more puzzles you can make). Game Y also doesn't need any instructions, because part of the puzzle is figuring out how it all works.
For my game Tahira's Tower, I'm basically porting Sokoban to a 3D environment. There have already been some Sokoban 3D games, but this one actually adds depth, gravity, and climbable objects, so the gameplay is 3D, not just the graphics. I'm changing puzzle design to a dynamic based one, in particular focusing on the rules regarding the added third dimension. I've already played with the Sokoban concept before in Picross Pushers when I combined the Picross/Nonogram mechanics with Sokoban ones.
Making up puzzles for it is surprisingly difficult. To quote this RPS article, making a puzzle game is very much like a puzzle itself. First thing I did is figuring out how all mechanics work together to create the various dynamics, put those in a single list. That's basically all puzzles I could make without padding it. This means you should make a few prototype puzzles to figure out what dynamic rules pop up in your game.
Then, I converted the list of mechanics and dynamics into the list of puzzles. There are the puzzles introducing the mechanics at the very beginning of the game, and the rest is about exploring the dynamics. Important is that you list which knowledge the player must have to pass the puzzle, because if the player doesn't when he starts the puzzle, he must learn so while solving it. This list went through multiple iterations, so it's by no means definitive and can be resorted if needed.
Then you go and make puzzles, and probably find more or better ideas to make puzzles while doing so. If you get something entirely different than from what you had the intention to make, it shows that your mechanic is deep enough to support various kinds of puzzles. See how deep the rabbit hole goes, so to speak! Important is that each puzzle learns the player something meaningful about how the game works, make each and every puzzle have a clear purpose.
For example: each chapter in Braid starts with 'The Pit', a single screen room where there's a pit between you and the exit, with the key to the exit positioned at the bottom of the well. The trick is that the puzzle's re-occurrences are slightly different each time. So by presenting the player with a challenge similar to one previously faced, but where the previous solution is no longer valid, it forces the player to think outside of the box and come up with something new. Note that Braid teaches the player new mechanics with this puzzle, but I'm planning a 'Staircase' series of puzzles that teaches new dynamics in a similar fashion.
The problem with games where the player keeps learning things over the course of the entire game, that if they solve a puzzle without (consciously or subconsciously) understanding it, they might miss knowledge to solve a puzzle later on. In order to test properly for this, you'll need all projected puzzles to be in your game, which could take a while. Also never teach the player something by 'forcing' him to do it (locking him into a single move, for example), let the player try to figure it out for himself.
So, the takeaway:
Three subtypes of puzzle games:
- Single mechanic-based: Enter A, A hard, A harder, A hardest (the same thing made more difficult). Examples: Sudoku, Picross/Nonogram, Sokoban
- Multiple mechanic-based: Enter A, Enter B, A+B, A+B Harder (challenge comes finding out how the new mechanics work with the old ones). Example: Sokobond, English Country Tune.
- Dynamic-based: Enter A, A Dynamic 1, A Dynamic 2, A Dynamic 3, etc. (Use existing mechanics in new, unexpected ways every puzzle). Example: Stephen's Sausage Roll, Tahira's Tower!
How I plan and build the puzzles in Tahira's Tower:
- List all mechanics & find all dynamics created by them
- Create a puzzle list: teach all mechanics first, then the dynamics. You have about as many puzzles as you have mechanics, dynamics, and other cool puzzle ideas. Iterations on this list are totally allowed.
- Create the puzzles on the list. I iterate on the individual puzzles while making them, and often I find new interesting dynamics to build puzzles around.