What actually goes into designing a digital puzzle game

What a "mechanic" actually is

A mechanic is a rule a player can act on, repeatedly, and learn to predict. Not a theme, not an animation, not a piece of art — a rule. "Tiles slide until they hit something" is a mechanic. "Ancient temple" is a setting. Puzzle design confuses these two constantly, because setting is easy to talk about in a pitch and a mechanic only becomes real once someone is actually pressing buttons against it.

The test we come back to is simple: can a player, after a few tries, explain the rule back to us in one sentence? If they can't, the mechanic isn't finished — it's still a collection of behaviors that happen to be in the build.

The design loop: idea, prototype, playtest, cut

Puzzle mechanics don't get designed at a desk; they get discovered by building the smallest possible version of an idea and immediately putting it in front of someone who didn't design it. The loop is short on purpose: idea, rough prototype, playtest, cut or keep. Skipping the "cut" step is the single most common way a promising mechanic turns into a confusing one — every idea feels clear to the person who invented it.

What makes this loop work is treating a playtester's confusion as data, not as a problem with the playtester. If three people in a row solve a puzzle by accident, or get stuck at the same step for the same reason, that's the mechanic talking, not bad luck.

Where most puzzle designs go wrong

Three failure modes show up again and again. First, mechanics that need an explanation longer than the mechanic itself — if a rule needs a paragraph of tutorial text, the rule is doing too much. Second, "solved by accident" puzzles, where a player reaches the right answer without understanding why, which feels hollow even when it feels like a win. Third, difficulty added by hiding information rather than by demanding better thinking — a puzzle that's hard because the player can't see the board clearly is not the same as a puzzle that's hard because the logic is genuinely deep.

All three failures share a root cause: designing for how the mechanic looks in a design document instead of how it plays in someone else's hands.

How this shows up in Solobit's own process

Solobit Games is built solo, with an internal AI-assisted workflow that speeds up coding, iteration, and testing — but the loop above stays human-led end to end. AI tools help get a rough prototype built faster; they don't decide whether a mechanic is fair, clear, or worth keeping. That judgment call is still made by playing the thing and watching someone else play it.

What we keep, what we cut

A mechanic earns a place in the first Solobit Games title only if it passes the one-sentence test above, survives a playtester solving it without hints, and still feels good on the tenth attempt, not just the first clever one. Mechanics that only work as a surprise get cut — a puzzle game has to hold up on replay, not just on first impression. The first title is still in development, so none of this describes a finished feature list; it describes the filter every mechanic has to pass through before it's allowed to stay.