◈ FeReLab
Lab Notes · Puzzle design

Why simple puzzle games are so hard to design.

Anyone can explain a block puzzle in one sentence. Getting someone to place just one more piece is a different problem entirely.

An independent FeReLab design note · Game feel, decision-making and honest iteration

Imagine a board of empty squares and three shapes waiting at the bottom. You drag a shape into the grid. It fits. A line clears. That sounds like a complete game.

Now imagine the same sequence with a half-second delay, a piece that lands two cells away from your finger, and a tiny animation that barely acknowledges the clear. The rules are identical. The experience isn't.

The difficulty of a simple puzzle is that there is nowhere for its weak moments to hide. When there are only a few actions, every one of them has to feel intentional.

1. Understanding the move should be easier than choosing the move

A strong puzzle can make you think hard about where to place a piece. It should not make you think hard about whether the game understood your finger.

That distinction matters most on a phone. The board is small, a finger hides part of it, and the player is moving rather than carefully positioning a mouse cursor. A preview shadow, a reliable snap position and a readable invalid placement all reduce friction without reducing challenge.

When the rules are clear, difficulty feels like a property of the puzzle. When the controls are unclear, difficulty feels like a property of the interface.

2. A satisfying action needs a visible consequence

Good feedback is not the same as loud feedback. A giant explosion after every tap gets tiring. No response at all makes the action feel weightless.

A puzzle often needs a short, readable chain: the shape settles into the grid; the completed row becomes unmistakable; the board changes; the next decision becomes visible. Sound and motion should support that chain, not compete with it.

One useful design exercise is to turn all sound off. If a player cannot tell what happened, the animation probably needs more information, not more particles.

3. The best choice is not always the obvious choice

A puzzle becomes interesting when two reasonable moves pull the player in different directions. One move may score immediately. Another may preserve enough room for the next piece.

But there is a trap here: adding obstacles, timers and special tiles does not automatically produce depth. Sometimes it only hides a dull decision beneath more rules.

The goal is not to make a simple action complicated. It is to make a simple action matter.

A useful test: after a player makes a move, can they explain what they traded away? Space for points? Safety for opportunity? Short-term certainty for a better future position? If every move feels equivalent, the puzzle may be missing a meaningful trade-off.

4. Losing should teach something without delivering a lecture

Failure has two jobs. It ends the current attempt, and it suggests a better approach to the next one. A restart button alone handles the first job.

Consider the moment just before the board fills. Can the player see the poor decision that created the problem? Could a clearer preview have prevented an accidental mistake? Was the loss caused by a choice, or by information the game withheld?

Not every game needs an undo button. But every game benefits from a fair relationship between what the player knows and what the game demands.

5. “One more round” is a design result, not a feature

It is tempting to solve replayability with rewards, streaks, coins or more levels. Those systems can help, but first the basic loop must survive without them.

The smallest useful question is this: after one completed attempt, does the player already have an idea for what to try differently? If so, the game has created its own reason to restart. If not, another progress bar may only postpone boredom.

That is why a simple block puzzle can take far longer to tune than to implement. Writing the placement rule is one task. Making each placement readable, responsive and consequential is the ongoing work.

A five-minute design check

If you're prototyping a small puzzle, try this before adding another mechanic:

  1. Explain the objective in one sentence. If it needs a paragraph, look for rules that can disappear.
  2. Make five moves without sound. Can you still read every placement, clear and consequence?
  3. Deliberately try a bad move. Is it rejected clearly, or does the game seem broken?
  4. Lose once. Can you identify a decision you'd change next time?
  5. Restart immediately. Does that next decision feel interesting without a reward screen?

None of these questions guarantees a hit. They're a way to find the dull or frustrating seconds that hide inside otherwise promising mechanics.

Where Blocksmith fits

Blocksmith is FeReLab's free browser block puzzle. It offers an immediate place to think about these trade-offs: placing pieces on a board is straightforward, but preserving space and deciding when to complete a line is the interesting part.

We care about the moment a piece lands as much as the moment a line disappears. If those two moments feel trustworthy, the rest of the puzzle has a chance to be fun. If they don't, more content won't rescue the core loop.

Lab Notes is an editorial design journal, not a claim of measured player behavior. We'll separate design hypotheses from real performance data as FeReLab grows.