Feedback can stall a finish

A small magnet puzzle went dark for six months after its maker showed it to other developers and came home with a stack of notes. The silence looked like rest. It was a queue. Every note was a different game, and none of them could be built while all of them were being considered. Feedback had replaced the finish.

The thing that finishes a game is a decision about which note to ignore. You play the version you have, you change one thing the play made obvious, and you decline the rest until that version exists. A pile of good advice is how a short project becomes a permanent prototype. The advice can be right and still be fatal if you take it all before you have shipped something a stranger can finish.

A magnet puzzle game went dark for half a year after its designer showed it to other developers and came home with an enormous pile of feedback. The silence was a symptom, not the cause.

It was also not unusual here. On paper the game had been in development for roughly two years. Count only the months where real work happened and the figure drops to about nine. Something had to give if the game was ever going to reach an ending.

Scheduling took some of the blame. The game was always competing with other production work, and every long absence made the return trip harder. So the first fix was obvious: rearrange the calendar and give game development a sustained stretch of attention.

That repaired the surface and left the real fault untouched. Even in the active months, the work had the shape of aimless noodling — try a thing, add a bit, and quietly hope the pile turns into a finished game on its own.

The underlying problem was that no plan existed. Nowhere was there a complete list of the tasks and actions that would carry the game to completion; most of the project lived as a loose cluster of ideas in the designer's head.

In the earliest stretch of a project, that is a reasonable way to work. A game still hunting for its own shape can be smothered by planning, and a thick design document has a way of making experiments feel forbidden before anyone has found the fun.

The calculation flips once the prototype runs and the core is understood. The question stops being "what is this game?" and becomes "how does this game get finished?"

Answering the second takes an artifact you can point at . A whiteboard, a notebook, a design document, a task board. Anything recording what belongs in the game, what does not, and which steps stand between here and the finish line.

The plan started at the top, with the major objectives standing between the prototype and a released game: name the thing, build every level, write the story, put up a store page, and so on down the list.

Each of those objectives then earned a plan of its own. Level design showed why that second pass mattered. Until then the entire level plan amounted to "make a bunch of levels," which is a wish rather than a plan.

Better questions were far more specific. How many levels does the game want? How many worlds do they divide into? Where does each major mechanic get introduced? How large can the game be and still have a real chance of shipping?

The answer was deliberately modest: 50 levels spread across five worlds, 10 to a world. A level here is one single-screen puzzle chamber that takes two or three minutes to solve, so 50 of them was never going to be a huge game. It was going to be a finishable one.

Scope is what converts "make levels" into a list of jobs with names. Three of the five worlds were each built around a different kind of magnet, and that decision alone generated most of the assignments.

World one opened with large magnetic blocks. World two centered on a simple magnet the player could pick up, carry, and throw around the room. World three brought in a magnet that flipped between two forms as its polarity changed.

Every magnet needed introductory levels teaching its basic abilities, and every supporting mechanic needed a small arc of its own. A moving drill bit, a block on wheels, one-way platforms. Laser beams, timed reset switches, scissor gates, and the rest of the puzzle pantry.

A single mechanic might get three slots: one level that teaches it, one puzzle that demands it, and a third that hardens the idea, subverts it, or pairs it with something else from the puzzle matrix. With those slots written down, most of the game had shape. Each level now arrived with a purpose attached instead of a blank room and a vague instruction to be clever.

Level design got dramatically quicker once the plan existed, because the brief for each level shrank to something answerable. Not "make something interesting," but "introduce this mechanic," "test this interaction," or "combine these two ideas."

The pace shifted with the clarity. Good days yielded four or five levels. Inside roughly a month the project held about 40 final levels, sitting on top of a much taller stack of drafts that were never going to ship.

The drafts were not waste. They were how the designer learned what each mechanic could stretch to, which combinations confused people, and which ideas deserved promotion into real chambers. You only find that out by building the level and playing it.

None of this makes the work easy. A plan does not do the hard part for you. It points the hard part in a direction.

A plan that never changes is not being read. This one was revised whenever the game revealed something the plan had gotten wrong.

One such lesson: stacking too many opening levels with no magnet in them felt off. The magnet is the entire premise, and withholding it is like spending 10 levels of Portal without the portal gun.

The fix was to bring magnet play forward, partway into the first world. That exposed a second problem. The throwable magnet originally slated to go first was asking for too much at once — picking up, putting down, riding magnetic fields, and aiming throws through a trajectory system.

So the order changed. A heavier, simpler magnet took the opening slot. It could not be thrown and it drifted slowly through magnetic fields, which made it a gentler teacher for the game's stranger ideas. The complicated throwable magnet was pushed further down the campaign.

Players moved the plan too. Through the level-design sprint, batches of levels went out to friends, family members, puzzle designers, and other players, and what came back fed straight into the schedule.

A single remark from a tester could suggest a puzzle nobody had thought of. Elsewhere a world outgrew its 10-level allowance, which meant the other worlds had to grow with it or the structure would tip out of balance.

Growth like that can run away from a project. The difference here was that the plan made every addition visible immediately, so good discoveries could be absorbed without the scope quietly sprawling.

Changing a plan because the game taught you something and wandering in the dark with no plan at all can look similar from outside. They are not the same activity.

The value of writing it down shows up the moment you stop working. The sprint did not finish the game — levels were still missing, playtesting was ongoing, and an entire final world had yet to be built.

But it had put a serious dent in the work, and the next steps were legible. Stepping away no longer meant coming back to fog. The plan held the thread while the designer was gone.

There is a second, quieter benefit. Burn out on one kind of work, such as the cerebral grind of level design, and the plan can hand you a different useful task that runs on another part of the brain.

Here, knowing how many worlds there were and what each one looked like made it possible to start background art, capture screenshots, and cut animated images for marketing. All of it moved the project forward, just on a different kind of energy.

Naming was its own line item on the plan, and it had been deferred for a long time. The game had run on a placeholder title for more than two years. It needed a real one: clever, memorable, and immediately readable as a puzzle game about magnets.

The bad names came first, in volume. Automated suggestions did not rescue the situation either. The winner came from a friend — Mind Over Magnet.

It was catchy and specific enough to stick, and once it stuck the game needed a logo. That work began with the words themselves, pushing fonts, colors, and layouts around until something held. The magnet obviously belonged in there, and swapping the letter "a" for a magnet gave the mark a strong focal point.

Feedback sharpened it one more turn: let the letters around the magnetic "a" look as though they are being pulled toward it. One small change, and the logo started explaining the game.

With a name, a logo, screenshots, animated images, and an honest sense of scope, the project finally had enough material to stand up a Steam store page.

The usual advice is to publish that page as early as you can, so wishlists have time to accumulate. This one went up late. Late still beat never.

The page was also more work than uploading a build. It wanted a Steamworks account, business information, a fee, proof the developer was legitimate, descriptions, tags, minimum system requirements, screenshots, capsule art, banner art, and a release date, even one kept private.

What went live was not elaborate, and there was no trailer yet. It was live, though, and that was the point. An indefinite personal prototype had become a project with a public commitment attached to it.

That single month outproduced every stretch that came before it, and the plan is the reason. But the timing of the plan matters as much as its existence.

Plan too early and you strip the project of the freedom it needs to stumble into its best ideas. Plan too late and development spreads across years of disconnected experiments that never converge.

The window sits between the two: after the prototype has told you what the game is, and before production starts drifting. You know you are in that window when playing your own build stops raising questions about what the game is and starts raising questions about what is left to build.

From there a plan does four things. It gives each session a purpose. It supplies motivation, because the path is visible. It fixes scope, because it names what is in and what is out. Above all, it converts the wish to finish a game into an ordered list of actions a person can complete.

In the Flockbay app, play what you have and write one change. Approve a brief for that change only. If you are collecting notes instead of playing, you are in the six-month queue. The queue ends when a version exists that you are willing to call done, even if it is small.

An AI puzzle maker and a logic puzzle template are enough for a magnet puzzle. Finish the board you have.