How I Make Puzzles for My Indie Magnet Game

After more than a year of building an indie puzzle adventure about magnets, the next goal was actual content: puzzle chambers that might survive into the final game.

Up to that point, most levels had been test rooms and prototype stages. They were useful for proving mechanics, but they were also fragile. Change the code too much, and the old rooms would be thrown away.

The January 2023 challenge was to make 30 individual puzzle chambers. Not prototype rooms. Not tests. Actual puzzles that could begin forming the shape of the finished game.

That sounded straightforward until the work began. Sitting in front of Unity with a blank room and the goal "make puzzles" quickly revealed a problem: it is very hard to come up with good puzzle ideas on demand.

A few good puzzles had already appeared during development, but they felt like flukes: happy accidents that emerged while testing mechanics. Making that happen 30 times in a row was a different challenge.

Early progress was slow. A few levels came together, but the process felt tedious and draining. Motivation dropped quickly because each session began with an ambiguous creative demand: make something interesting.

That made level design feel very different from programming a mechanic. When building a mechanic, there was always a concrete goal: make a block the robot can push left and right, make a door work, make a switch behave correctly.

With that goal in place, it was easy to focus for hours. The task had a clear direction. But level design began with a vague instruction and no obvious path forward.

The work needed more structure. The goal could not simply be "make a good puzzle." It needed a method for discovering puzzle ideas.

A useful answer came from puzzle designer Patrick Traynor, creator of Patrick's Parabox, who has written about ways to generate puzzle ideas. One technique stood out: systematically combining mechanics.

The first step was to take screenshots of every mechanic in the magnet game: magnets, the drill bit, one-way platforms, the electromagnet, lasers, and so on.

Those mechanics went across the top of a table. The same mechanics went down the side, with duplicate pairings removed. The result was a matrix where every cell represented the intersection of two mechanics.

A cell might combine the electromagnet and the drill. Another might combine the laser and a moving block. Each pairing became a prompt rather than a finished answer.

That prompt was enough to start. Instead of facing a blank room and an abstract demand, the work began with two concrete ingredients to explore.

For each matrix cell, the two mechanics went into an empty Unity room with a few other basics: the character, a magnet, buttons, floor tiles, and whatever else was needed to test interactions.

Then the process became play. Move pieces around. Experiment. Watch what the systems do. Look for interesting consequences of the two mechanics interacting.

With the electromagnet and the drill, one realization appeared: if the drill bit sits over the electromagnetic beam, the little magnet gets stuck. Retract the drill, and the magnet escapes at different speeds depending on which side of the drill bit it is on.

That small realization can become the solution to a puzzle. The player needs to discover that the magnet should be trapped beneath the drill bit, away from the tip, so there is enough time to reach a location before the magnet escapes and causes two doors to switch places.

The level is then built backwards from that insight. The designer knows the one thing the player must understand, and the rest of the room can be shaped to make that realization necessary.

The matrix did not magically turn every pairing into a good puzzle. Some combinations produced nothing useful. Some still took a long time to explore. Puzzle design remained difficult.

But the method made the work much easier because it supplied a starting point. It gave the designer a suggestion, a jumping-off point, and a concrete reason to open the editor.

That changed motivation. The job was no longer "invent something clever from nothing." It became "put these two mechanics together and see what interesting consequence appears."

That difference matters. Creativity often improves when the problem has boundaries. A blank page can be paralyzing, while a small constraint can focus attention enough for ideas to appear.

Puzzle design also became easier through repetition. Making many puzzles in a short period started to build a practical sense of what works.

One useful lesson was the number of actions available to the player at any moment. If a puzzle gives too many options, it can feel confusing and overwhelming. The player does not know where to start or which part of the room matters.

If there are too few options, the opposite problem appears. The player may simply do the obvious thing repeatedly until the puzzle solves itself, without ever understanding the intended idea.

Good puzzles often sit between those extremes. They give enough freedom for uncertainty, but not so much that the player drowns in possibilities.

Another lesson was the value of a wrong assumption. A puzzle can lure the player into a plausible plan, let that plan fail, and then force a more lateral realization. The wrong path is not wasted if it teaches the player how the room works and directs attention toward the real catch.

The work also became easier as the toolbox grew. Puzzle design often depends on forcing the player to do one specific thing. That means cutting off easier routes that would make the intended solution pointless.

Those constraints usually need mechanics. A laser might block the player but not the magnet. Another beam might block the magnet but not the player. A button might need to be held down to operate. A door might trigger a switch every time the player passes through it.

Each time a new mechanic was created to solve one puzzle problem, it became available for future puzzles. The toolbox grew, and old problems became faster to solve.

Some mechanics were also swapped for versions that combined better with the matrix. A simple lever might be neat, but a spinning fan blade creates more possible interactions. It can push, block, threaten, time, or redirect things in ways that are more fertile for puzzle design.

That is a useful production lesson: mechanics are not only judged by what they do alone. They are judged by how many interesting relationships they can form with the rest of the game.

Level-design tools became another important part of the process. Puzzle design is full of experimentation, iteration, and tiny adjustments, so editing the rooms needed to be as frictionless as possible.

One early tool problem involved wiring buttons to mechanics. It took many clicks to assign the right functions to both the on and off triggers for a button. That might sound small, but repeated hundreds of times, it becomes a tax on experimentation.

Rewriting the tool so the same setup could happen with one click made the design process faster and less annoying. The point was not just comfort. Lower friction changes what the designer is willing to try.

If testing an idea is slow, many ideas never get tested. If the editor makes experimentation easy, puzzle design can stay playful instead of becoming administrative work.

Each finished puzzle went into a "puzzle bible" made as a slide deck. Each slide recorded which mechanics the puzzle used, making it easier to reorder the stages and plan progression.

That progression matters because the player needs to learn mechanics gradually. One puzzle might introduce red blocks, the electromagnet, and touch buttons. The next might add blue blocks. A later puzzle might add the drill bit and the winch.

Seeing the puzzles laid out together made bad jumps obvious. If one level introduces a small number of ideas and the next suddenly adds orange buttons, green buttons, lasers, and moving platforms, the sequence is asking too much too quickly.

Those gaps became useful. Instead of being a problem, each gap was fertile ground for more puzzles. The new goal was clear: make levels that introduce the missing mechanics before the player reaches the harder room.

Once again, structure created momentum. The puzzle bible turned progression problems into specific assignments.

The January goal was 30 levels. The final count was about 26 before work had to stop for other production needs. That missed the exact number, but the progress still changed the project dramatically.

The game no longer felt like an endless prototype. With a large set of real puzzle chambers, improved visuals, and a clearer structure, it started to feel like a proper game.

The emotional shift mattered too. A few weeks earlier, the project felt exhausting enough to delete. After the puzzle sprint, the end finally seemed visible.

There was still a lot to do: more levels, narrative work, cutscenes or story framing, a level select screen, music, polish, bug fixing, and release. That is months of work. But it had become a roadmap rather than fog.

The next step is playtesting. Puzzle designers are especially bad at judging their own work because they already know the answer. They know the intended trick, the correct route, and the reason each object exists.

That makes it hard to judge difficulty or quality from inside the editor. A puzzle that feels obvious to the creator may be impossible for a new player. A puzzle that feels clever may have an accidental shortcut. A room that seems fair may hide the important clue too well.

The levels need to be bundled into a demo and handed to other players. Family and friends can start the process, but broader testing will be needed before the difficulty curve can be trusted.

The useful lesson is that puzzle production needs both generation and validation. The matrix helps create ideas. The toolbox and editor help build them. The puzzle bible helps arrange them. But only playtesting can show whether players actually understand, enjoy, and solve them.