The One Thing You Need to Finish Your Game

After showing a magnet puzzle game to other developers and collecting a huge amount of feedback, the project went quiet for six months.

That was not the first long pause. The game had technically been in development for about two years, but only around nine months of that time had been active work. If the game was ever going to be finished, something had to change.

Part of the problem was scheduling. The project had to compete with other production work, and switching away from the game for too long made it harder and harder to return. The obvious fix was to change the schedule and put more sustained focus into game development for a while.

But that only solved the surface problem. Even during active development, the work often felt like aimless noodling: trying things, adding bits, hoping the project would eventually turn into a finished game by itself.

The deeper problem was the lack of a concrete plan. There was no complete list of tasks and actions needed to bring the game to completion. Most of the project existed as a cluster of ideas in the designer's head.

Early in development, that can be useful. When a game is still searching for its shape, too much planning can become a trap. A heavy design document can make experimentation feel illegal before the project has even found what makes it fun.

But once the prototype is working, and the core of the game is understood, the problem changes. The task is no longer "discover the game." It becomes "finish the game."

At that point, the project needs something concrete: a whiteboard, a notebook, a design document, a task board, or any other artifact that says what belongs in the game, what does not belong in the game, and which steps will get it to the finish line.

The first step was a high-level overview of the major objectives needed to finish the project: naming the game, building all the levels, writing the story, making a store page, and so on.

Then each major objective received its own more specific plan. Level design was the clearest example. Up to that point, the plan had effectively been "make a bunch of levels," which is not really a plan at all.

The useful questions were much more specific. How many levels should the game have? How many worlds should they be split across? When should each major mechanic be introduced? How big can the game be while still having a realistic chance of shipping?

The answer was conservative by design: 50 levels across five worlds, with 10 levels per world. In this game, a level is a single-screen puzzle chamber that can be solved in two or three minutes, so 50 levels would not make an enormous game. It would make a finishable game.

The first three worlds each revolved around a different kind of magnet. The first world began with big magnetic blocks. The second focused on a simple magnet that could be carried and thrown around the room. The third introduced a magnet that could switch between two different forms as its polarity changed.

Each magnet needed several introductory levels to teach the player its basic abilities. Then each supporting mechanic needed its own small arc: a moving drill bit, a block on wheels, one-way platforms, laser beams, timed reset switches, scissor gates, and other puzzle ingredients.

A mechanic could get one level that teaches it, one proper puzzle that asks the player to use it, and a third level that either makes the idea harder, subverts it, or pairs it with another mechanic from the puzzle matrix.

Once those pieces were placed on the plan, much of the game suddenly had shape. The work was still large, but it had become a set of assignments. Each level had a purpose instead of starting from a blank room and a vague demand to be clever.

The plan made level design dramatically easier. A level was no longer "make something interesting." It was "introduce this mechanic," "test this interaction," or "combine these two ideas."

That clarity changed the pace of work. Some days produced four or five levels. Within about a month, the project had roughly 40 final levels, plus a much larger pile of discarded drafts that would never ship.

The drafts still mattered. They were part of learning what each mechanic could do, what was too confusing, and which ideas were strong enough to become real chambers.

A plan does not remove the hard work. It gives the hard work a direction.

The plan did not stay frozen. It changed as the project revealed better answers.

For example, it felt strange to have too many early levels with no magnet at all. The magnet is the point of the game, so delaying it too long would be like playing Portal for 10 levels before receiving the portal gun.

The solution was to introduce magnet play partway through the first world. The original first throwable magnet also turned out to ask too much at once: picking up, putting down, riding magnetic fields, and aiming throws with a trajectory system.

So the plan shifted. A heavier, simpler magnet became the first magnet instead. Because it could not be thrown and moved more slowly through magnetic fields, it taught the game's unusual ideas more gently. The more complicated throwable magnet moved later into the campaign.

Playtesting also affected the plan. During the level-design sprint, batches of levels were given to friends, family members, puzzle designers, and other players for feedback.

Sometimes a tester's observation suggested a new puzzle. Sometimes a world grew beyond its original 10-level target, which meant other worlds needed more levels too if the overall structure was going to stay balanced.

That kind of expansion can get out of hand, but the plan made it visible early. The project could absorb good discoveries without drifting into endless scope creep.

There is a major difference between altering a plan because the game has taught you something and wandering in the dark without any plan at all.

The level-design sprint did not finish the entire game. There were still more levels to make, more playtesting to do, and an entire final world left to build.

But the work had made a big dent, and more importantly, the next steps were clear. Taking a break no longer meant returning to fog. The plan preserved the thread.

That is one underrated benefit of planning. When a developer burns out on one kind of work, such as cerebral level design, the plan can point to a different useful task that exercises another part of the brain.

In this case, knowing the number and theme of the worlds made it possible to start on background art, create screenshots, and make animated images for marketing. Those tasks still moved the project forward, just with a different kind of energy.

Another major task on the plan was naming the game. For more than two years, it had been using a placeholder title. That could not last forever. The game needed a name that was clever, memorable, and instantly communicated the idea of a puzzle game about magnets.

Many bad names came first. Even automated suggestions were not much help. The best name came from a friend: Mind Over Magnet.

The name was catchy and specific, so it stuck. Then it needed a logo. The design started with the words themselves, experimenting with fonts, colors, and layouts. The magnet naturally belonged in the logo, and replacing the letter "a" with a magnet created a strong focal point.

Feedback improved it further: the surrounding letters could appear to be attracted toward the magnetic "a." That small idea made the logo communicate the concept more clearly.

With a name, logo, screenshots, animated images, and a clearer sense of the game's scope, the project finally had the ingredients for a Steam store page.

Conventional wisdom says to create a store page as early as possible so the game can start gathering wishlists. This one arrived late, but late was still better than never.

Making a Steam page was more involved than simply uploading a build. It required a Steamworks account, business information, a fee, proof of legitimacy, descriptions, tags, minimum system requirements, screenshots, capsule art, banner art, and a release date, even if that date was not shown publicly.

The first version of the page was not elaborate. It did not have a trailer yet. But it was live, and that mattered. It turned the project from an indefinite personal prototype into something with a public commitment behind it.

That month of development achieved more than any previous stretch, largely because the project finally had a plan.

The timing matters. Plan too early and the project may lose the freedom it needs to find its best ideas. Plan too late and development can sprawl far longer than necessary.

The useful moment comes after the prototype has revealed what the game is and before production drifts into years of disconnected experiments.

A plan gives every development session purpose. It creates motivation because the work has a visible path. It defines the game's scope because it says what belongs and what does not. And, most importantly, it turns the wish to finish a game into a sequence of actions that can actually be completed.