Why is it so hard to make game design decisions? (Developing 3)

The original idea was a game where the player character was magnetic. After prototyping, a more interesting idea appeared: the character is not magnetic, but can pick up and throw giant horseshoe magnets.

That change improved the core interaction. It also seemed to change the game's genre.

The first plan was very much a platformer. The inspirations were games like Mario, Super Meat Boy, Celeste, and N++: speedrunning, mid-air maneuvers, button combinations, precision input, and fluid movement.

But once the character and magnet became separate objects, the game started drifting away from that fantasy. When the player has to babysit a magnet, progress slows down. You stop, go back, pick it up, and carry it forward. Then you do that again.

One fix would be an instant recall power, like the cap in Super Mario Odyssey or the axe in God of War. But in a 2D magnet game, that creates problems. It may look strange, and players may wonder why the magnet ignores magnetic fields or metal surfaces on its way back.

The separated character and magnet create a different kind of possibility. They turn the game into a set of spatial problems.

Maybe the player places the magnet in one spot, moves the character somewhere else, uses the magnet's abilities from a distance, then combines both objects to solve the room. That feels less like pure platforming and more like puzzle design.

That is exciting, but also intimidating. Puzzles are hard to make. Platformers can often reuse setups with small twists, and some can even be procedurally generated. Puzzle games usually need handcrafted, unique challenges, because once the player knows the solution, the puzzle loses much of its power.

For a new designer, that is a lot to take on. Still, the only useful next step was to try.

Early sketches included conveyor belts, pistons, spinning saw blades, and other familiar level elements. But those sketches quickly revealed a bigger issue: the player had too many abilities.

The character could pick up the magnet, throw it, change its polarity, and recall it. That is a lot of verbs for a puzzle game.

Puzzles often work by placing the player inside constraints. The designer builds walls, then asks the player to think carefully about how to get around them. But if the player has too many powerful tools, those walls stop holding.

The recall ability was especially dangerous. It was satisfying, like the upgraded gravity gun at the end of Half-Life 2, but it was so powerful that it could invalidate many puzzles if given too early.

There was also a learning problem. Starting the player with every ability at once would make the game harder to understand. A better structure might be closer to Portal: introduce one ability, let the player learn it, then add the next one later.

The old prototype had been built to platformer specifications: zoomed-out camera, fast movement, and more organic level design. A puzzle version needed different assumptions.

The camera moved in. The character slowed down. The jump became smaller. Organic layouts gave way to a clean grid built with tile maps. Each level became a single screen so the player could see all the pieces at once.

That decision was partly about taste. Single-screen puzzle games make the whole problem readable. It was also practical: the levels were being drawn on grid paper, and a static camera meant there was no need to build a camera-follow system yet.

One important addition was a trajectory arc that showed where the magnet would go when thrown. It did not account for magnetic fields yet, but it made the basic throw much clearer, and clarity matters when a game is asking players to reason about physics and positioning.

With the fundamentals in place, the next step was building puzzle elements: a magnetic block that moves left and right, a button that changes its position, a tractor beam that pulls the magnet upward, a weight-and-pulley setup for doors and platforms, and a one-way platform.

That one-way platform created a small but revealing design problem. The player can pass through it, but the magnet cannot. That is useful for puzzles. But what happens if the player is holding the magnet while passing through?

There is no automatic right answer. The designer has to decide the outcome. Should the platform block the player? Should the magnet be ripped from the player's hands? In this case, ripping the magnet away felt like the cleanest solution.

Game development is full of these tiny, unforeseen interactions. Sometimes the interaction naturally creates an interesting systemic result. Often it just creates a glitch, and the designer has to define what the rule should be.

After several small single-room puzzles were built, they seemed close to demo shape. The practical work began: pause menu, mouse controls for players without controllers, title screen, scene management between levels, bug cleanup, and code tidying.

But preparing to show the game to other people created a problem. The levels did not feel good enough. They were small, claustrophobic, and not especially interesting. Worse, they felt far away from the original dream of speed, precision, and fluidity.

That anxiety led to a late-night experiment: what would the game look like if it leaned back toward platforming?

A tractor beam and one-way platform were combined into a more kinetic setup. The player could ride the beam upward, release the magnet before it hit the platform, launch out the top, recall the magnet, move into another magnetic field, and repeat the pattern to climb.

That was fun. Iterating on it produced a fast chain of actions: ride the beam, let go, recall, throw the magnet at a weight, open a door, thread through a tight space, press a button, ride a block, jump, recall the magnet into hand, sail into another beam, and land at the exit.

The platforming experiment felt much closer to the original fantasy. But it had a serious problem: it required advanced knowledge of almost every mechanic, and it depended on the recall ability that probably needed to arrive late in the game.

One possible plan was to treat that platforming level as the finale. The earlier levels could teach each mechanic and button press, gradually unlocking the tools needed to master the final route.

That sounded workable until another first-mechanic level began turning itself into a puzzle. The goal was to teach the tractor beam. The player starts with a magnet stuck to a beam, presses a button to drop it, grabs it, turns the beam back on, and rides upward.

But without polarity switching or recall, the magnet gets stuck. Adding a second button felt inelegant. Adding a moving cover created a new possibility: slip through while the cover moves. Suddenly the level had become a clever puzzle about exploiting a slow block.

Now there were two strong directions: a fast platforming level and a thoughtful puzzle level. They could not both define the game.

Games can mix genres. Persona 5 can be a life simulator and a JRPG. But the magnet game was drifting between two sharply different experiences.

One audience might come for puzzles and be put off by harsh platforming demands. Another might come to speedrun fluid movement levels and be slowed down by puzzle rooms. Making one set optional would probably just dodge the real decision.

The hard question became simple: what genre is this game going to be?

This is where "kill your darlings" matters. Sometimes a designer must remove something they like, even something they worked hard on, because its existence hurts the larger work.

The platforming material was the darling. It matched the original idea, it was fun to play, and it felt easier to imagine making lots of levels for it. But the game itself kept pulling toward puzzles. The best version of the game seemed to be a puzzle game, whether that was the original intention or not.

Accepting the puzzle direction felt better after proving that a good puzzle could actually be made. It also revealed that the definition of "puzzle game" had been too narrow.

A puzzle game does not have to be a sequence of tight, single-screen, grid-based rooms. Puzzle-platformers such as Limbo use long continuous worlds. Portal requires movement and spatial execution as part of solving its chambers.

That means some platforming can remain. The game can have enemies, longer connected levels, and action-like sections, as long as those elements support the puzzles rather than compete with them.

The dominant genre matters because it determines which ideas are allowed to lead and which ideas must stay secondary.

The genre debate was only one symptom of a bigger issue. The same indecision appeared everywhere.

What if the magnet was attached to the player by a rope? What if the game was more physics-based, with the magnet attaching to objects and toppling them over? What if there were enemies or boss fights? What if objects came to the magnet instead of the magnet going to objects? What if the trajectory arc reacted to magnetic fields? What if the game was a platformer? What if it was a puzzle game?

That can look like scope creep, where a small game idea grows with more mechanics and content until it can never be finished. But this was slightly different.

Scope creep extends the development path endlessly. Analysis paralysis prevents movement down any path at all. The designer makes small tentative steps in many directions, but never commits far enough to leave the start line.

The fear is that committing to one idea will close off other ideas that might be more exciting. But without commitment, the game will never be finished. It may never truly start.

The useful advice came from another designer who had worked on a magnet-focused level in a co-op platformer. The suggestion was to adopt a game-jam mindset, even without a real jam deadline.

When time is limited, the question changes. It is no longer "what could this mechanic become if I explored every possibility?" It becomes "if I had to finish this quickly, what are the core things this game needs?"

Maybe the minimum version is just carrying a magnet, dropping it, and switching polarity. Maybe it is five levels that use those mechanics in interesting ways. The point is to define a minimum viable product: a small version that can actually be finished, played, and judged.

An arbitrary deadline is useful because it forces movement. It blocks endless wandering through possible futures and makes the designer pick a route through the present.

The new target became thirty development days to make five levels using the basic mechanics. Not thirty calendar days in a row, but thirty actual workdays. The question is no longer what the whole game could be someday. It is how much real game can be made inside that box.