Did I Complete My 30 Day Game Making Challenge?

The challenge was to make a minimum viable product for a small puzzle game about magnets. Not a prototype. Not a loose collection of mechanics. A functioning game with the core pieces that make it feel like a game, compressed into a very small shape.

The target was strict: 30 individual development days, five complete levels, and enough structure around the mechanics that the result could be played, judged, and handed to other people for feedback. That was the point of the exercise. A prototype can test whether one mechanic works. An MVP tests whether that mechanic still works when it has to sit inside a larger game structure.

Before opening the project, the plan seemed sensible. Five days for the character and magnet. Five days for the first level. Fifteen days for levels two through five, under the assumption that each level would get faster as the tools and patterns improved. The final five days would cover meta elements like a pause screen, saving and loading, polish, and bug fixing.

It looked like a decent production plan. It also missed something important.

The first job was to give the game graphics. The prototype had been a plain white rectangle jumping around blue blocks, which was useful for proving mechanics but bad for making the project feel alive. Pixel art became the obvious direction because it was fast to produce and had worked well on an earlier small project.

In a few hours, the game had a boxy orange robot, a magnet with a slightly unsettling face, key interaction pieces like an electromagnet and button, background decorations, and floor tiles. That immediately changed the emotional feel of the project. The mechanic was no longer floating in abstraction. It belonged to a character and a world.

The next step was rebuilding the character in a cleaner project. Some prototype code could be reused, but the MVP needed more deliberate systems. Animation was the first reminder that graphics create extra work. A full run cycle for a small robot would take time, so the design cheated: the robot lost its legs and gained a wheel. With dynamic poses and particle effects, the shortcut became part of the character's charm.

The magnet came next. The first instinct was to build a custom magnetism system rather than rely on an existing point-effector setup. That attempt partly worked, but it created bugs and awkward edge cases. The better decision was to cut losses, keep the useful bits, and use the code for a smaller purpose: making the magnet subtly tilt toward nearby magnetic sources.

By day five, the game had red, blue, and neutral magnet states, a way to switch between them, and a system for picking up and throwing the magnet. The pixel art caused another animation problem: how should the character hold the magnet with tiny arms? The answer was another cheat. The robot's arms became floating hands connected by line-rendered limbs and a springy hinge joint. It was not realistic, but it looked lively.

The first week ended with a character and magnet moving around an empty environment, and the game already had more personality than the prototype ever did.

The first real level was meant to introduce the concept of the magnet through simple scenarios and gradually harder challenges. The most useful tool for that work was not a software feature. It was a whiteboard.

The process was simple: draw one small scenario, photograph it, erase it, draw another, and repeat. One sketch might be a magnet pulling down a weight to open a pulley door. Another might introduce a crusher, an electromagnet, or a tiny platforming problem. Once enough sketches existed, they could be arranged on the computer into a rough difficulty curve, then redrawn as a complete level plan and rebuilt in the editor.

That first level brought in the tilemap, the first proper mechanics, and a few production realities. A weight-and-pulley system worked. A crusher could destroy the character. An electromagnet could create a clear mechanical obstacle. A complicated enemy built around a finite state machine, however, was far too much for the project. It was replaced by a much simpler enemy that moved left and right and could be defeated by landing on it.

Polish then started to creep in. Two-dimensional lighting gave the scene more depth. Rule tiles made it much faster to paint the level because the editor could choose the correct floor tile automatically. A camera system helped the view move smoothly with the player, then transition into wider framed shots for puzzle rooms. Checkpoints prevented deaths from sending the player all the way back to the beginning, and a respawn pipe brought the magnet back if it was thrown somewhere impossible.

The first level was not perfect, but it was playable. More importantly, it turned the idea from a mechanic into a level with rules, pacing, hazards, checkpoints, camera behavior, and failure recovery.

During the next sprint, a single puzzle idea changed the shape of the project. The exact solution is not important here. What mattered was the process: sketch the idea, rebuild it in the editor, discover all the ways it could be cheated or broken, then iterate until the puzzle actually worked.

That puzzle was exciting because it used a classic puzzle-design pattern. It lured the player into making an assumption, then revealed an impossible catch that forced a more lateral answer. It was a single-screen puzzle chamber with multiple moving parts, and it was far more satisfying to design than a long continuous level.

It also generated new mechanics. A laser beam could be blocked with the magnet, which led to new laser puzzles. A plug-and-socket system could transfer power from one block to another, which created another family of puzzles. Those puzzles led to more mechanics, and the design finally started to produce ideas from inside the game rather than from a blank page.

But this revealed a structural problem. The first level had been one long scene with every element loaded at once. Trying to build the second level the same way became unwieldy. The editor hierarchy became messy. Too much was sitting in memory. Rearranging rooms was painful. If the fourth puzzle turned out to be easier than the second, moving it earlier would mean shifting a large chunk of the level by hand.

The better plan was to stop thinking of each level as one big continuous scene. Each level could become a chain of smaller scenes connected by doors: puzzle chambers, short teaching rooms, and lighter platforming spaces in between. That meant more work, but it matched the kind of game that was emerging. The fun was in compact puzzle chambers, not sprawling stages.

Then the schedule started to fall apart. Development stopped for other work. It resumed briefly, then stopped again. One small tutorial for the laser mechanic was added, then another deadline interrupted the project. A month passed. Work resumed for a day, then stopped for the holidays. Another day of level design happened. Another day produced little more than button prompt screens.

That rhythm did not work. Every interruption drained momentum. Returning to the project after a long break meant remembering how the systems worked, what was half-finished, which bugs were known, and why certain tools had to be set up in exactly the right way.

The bigger problem was that the game's internal tools were messy. Code had quick fixes, last-minute patches, and fragile dependencies. Level design should have been getting faster, but even simple rooms were tedious because the systems were not robust enough. The project was no longer blocked by a lack of ideas. It was blocked by the cost of turning those ideas into playable content.

After 20 development days, the thought of doing 10 more felt impossible. That was a hard realization, but it also clarified what the MVP had already achieved. It broke the analysis paralysis. It forced decisions. It revealed that the best part of the game was making single-screen puzzle chambers. It also showed exactly what the future game would need: reliable, intuitive level-making tools that could turn puzzle ideas into content without so much friction.

The original five-level target was too much. The useful move was to cut scope hard and finish something playable.

The recovery plan was simple: stop chasing the original version and make the smallest complete version that could still give useful feedback. The scope dropped from roughly 35 scenes to about 14. That was a much more manageable target.

The remaining days became a sprint to fill gaps, connect the playable structure, and turn the project into something that could be handed to other people. Audio finally arrived on day 22, and it immediately made the game feel more complete. Even a simple button sound made interactions clearer and more satisfying. The lesson was obvious: sound should have been added much earlier.

Day 23 was a crawl across the finish line: polish, obvious bug fixes, and a scrappy pause menu that could reset puzzles or quit the game. At that point, the MVP was messy, buggy, and fragile, but it was playable. The temptation was to call it done and release it for feedback.

That would have been the original plan: finish the MVP, then ask the wider audience what they thought. But the first small playtest changed that plan immediately.

The first trusted playtest did not go well. The player got confused, found broken situations, disliked the number of buttons, struggled with the jump, and thought parts of the game were tedious. That was not fun to hear, but it was useful because it separated two kinds of feedback.

The point of the MVP was to learn about the game as a whole and the puzzles in particular. If players were getting stuck on bugs, control annoyances, unclear button prompts, and rough edges, they would not be able to give useful feedback on the deeper design. They would only report the mess directly in front of them.

So the plan changed. A couple of days were added to fix those annoyances before releasing the demo more widely. Day 24 went into problems found by the first playtest. Day 25 went into a better magnetism system, now that the implementation skill had improved enough to make it worthwhile.

Then another trusted playtester found bugs that had never appeared before, including ways to throw switches offscreen and break puzzles. Day 26 went into those fixes. Day 27 added saving and loading so players would not lose progress, plus a better pause screen that did not make quitting too easy by accident.

Then another playtester found ways to cheat puzzle solutions, so day 28 went into closing those holes. A child then broke the game in ways only a child can, which became day 29. Day 30 became the final round of polish, finish, compile, and upload.

In the end, the 30 days were used after all. The missing piece in the original plan was not content. It was playtesting.

The important discovery was not simply that playtesting is useful. That was already obvious. The real lesson was that playtesting should have been part of the 30-day plan from the beginning.

There is a difference between releasing an MVP for broad feedback and first handing it to a small group of trusted people. The small group reveals the problems that would pollute broader feedback: broken interactions, confusing prompts, assumptions the designer never made, cheats that bypass puzzles, and bugs caused by unusual player behavior.

Fixing those problems before a larger release makes the next round of feedback more valuable. Instead of spending every response on crashes and obvious annoyances, players can talk about the game itself: the puzzles, pacing, controls, structure, and whether the central idea is worth pursuing.

A small MVP still needs enough stability for feedback to be meaningful. That does not mean it needs to be polished like a finished game. It means the roughness should not block players from seeing what the experiment is trying to test.

The MVP was a good idea, even though the plan around it was flawed. It forced real decisions. It pushed the project beyond isolated mechanics. It created a playable demo that other people could react to. It showed which parts of development were fun, which parts were slow, and which tools would need to be rebuilt before the game could grow.

Three lessons came out of it. First, a short MVP sprint needs focus. It is hard to disappear for weeks, work on other things, and expect the same motivation and context to still be there when you return.

Second, the schedule needs explicit playtesting time. At least several days should be reserved for giving the game to a few people, watching where they struggle, and fixing the problems that would otherwise overwhelm the feedback.

Third, the MVP does not need huge amounts of content. The goal is not to generate a full game's worth of material. It is to see how the central mechanic feels inside a fuller structure. Is this the right direction? Does the game work when it has levels, menus, failure states, progression, audio, and real players? Is it fun enough to keep developing?

That is the difference between a prototype and an MVP. A prototype asks whether a mechanic has potential. An MVP asks whether that mechanic can survive contact with a game.