MiniGameDev | Simple systems for powerful games.
The Prototype - What I Got Wrong (and How I Fixed It)

The Prototype - What I Got Wrong (and How I Fixed It)

Fri Mar 06 2026

For the past two weeks I’ve been focused on finishing the playable prototype so I can publish it on Itch.

Most of that work wasn’t about building new systems. Instead, it was about pulling the experience together: Shaping the gameplay structure, getting the menus working, and making sure the core systems actually interact with each other.

What surprised me most during this phase is how many assumptions from the original design fell apart once the game was playable. Several mechanics that looked fine on paper behaved very differently once I could actually walk around the world and play real matches.

This article walks through the biggest design problems the prototype exposed and the systems that replaced them.

TL;DR

The prototype exposed several design problems that only appeared once the systems were playable:

Design Problems the Prototype Revealed

Earlier versions of the design were much simpler than what the prototype eventually became.

Originally I was aiming for something similar to Final Fantasy 1 and Pokémon Red / Blue: the player walks around an overworld, random encounters occur, and bosses are scattered throughout the map.

Once the prototype existed though, that plan immediately started breaking down.

Random Encounters Don’t Work Without Leveling

One of the first major design decisions I made for this game was removing leveling and XP.

Without leveling, random encounters lose most of their purpose. In traditional RPGs the grind exists to prepare the player for later battles. Without a progression system, random encounters were just annoying.

The solution was switching to scripted encounters.

Instead of random battles, encounters are placed intentionally in the world and the enemy composition is predefined. Since the combat system is more tactical than a traditional RPG, this approach also gives me far better control over pacing and difficulty.

A Single Resource System Wasn’t Enough

During early development I removed money from the game entirely. I didn’t want to build vendors or deal with consumable card management. At the time the game felt cleaner without it.

But after playing through the prototype several times, something felt off. The game rewards players who plan ahead, but without vendors the only resource the player actually manages is HP.

That creates a false choice:

OR

In practice this isn’t really a decision. Once players understand roughly how much damage enemies deal, they’ll simply walk back to the nearest Inn and guarantee the win.

Adding Money solves this problem. Now players can purchase things like:

This adds another preparation layer and gives players a reason to fight additional enemies if they want extra resources. And it allows the player to push forward into combat even with lower HP because they having more Potion cards to offset the disadvantage.

Power Runes Needed a Simpler Mental Model

The second economy in the game is Power Runes.

These items activate devices like bridges and lifts. Originally I planned to have multiple rune types:

But very quickly this started to feel unnecessarily complicated. Instead, I consolidated everything into a single Power Rune item.

This simplifies the mental model for players while also enabling an interesting side effect. Many devices allow the player to activate them, retrieve the rune, and reuse it somewhere else.

Players who notice this can carry runes forward into later areas and gain small advantages. Players who don’t notice the trick can still solve puzzles normally. And with the added money & vendor systems, players who ignore the puzzles, can still solve them by fighting more enemies, gathering money, and purchasing Power Runes.

It’s a small system, but it rewards observation and gives players multiple paths to the same solution.

The Card Combat Problems

At the end of January I released the first card combat prototype on Itch. The system worked well in isolation. I simulated hundreds of Hero vs Hero matches and tuned decks based on win ratios and average turn counts. My goal was to keep most matchups around a 40 / 60 split.

But once I introduced my first real enemy, the Elven Scout, several design problems became obvious. The combat system technically worked. But it didn’t feel right anymore.

Problem #1: Enhancement Cards Had No Weight

Enhancement cards were always tricky to design.

They shouldn’t behave like attacks, but they also can’t become game‑breaking specials.

In the original prototype they ended up acting closer to specials, which created several issues:

Interestingly, I didn’t notice this during Hero vs Hero testing.

Hero decks originally contained 14 cards, but only 2 - 3 enhancements. Since the battlefield only has three slots, those slots were usually filled with attacks.

Enemy decks immediately exposed the problem. Enemy decks only contain six cards, which meant enhancements appeared much more frequently and the battlefield didn’t fill properly. So the fix was:

Enhancement cards now exist on the battlefield.

They can be targeted, disrupted, and destroyed just like other cards, which makes them part of the tactical layer.

Problem #2: Hero Decks Were Too Complex

Hero decks originally contained 14 unique cards.

This created two problems.

  1. It was simply too many cards for the player to track. Since defeated cards return to the bottom of the deck, players need to be able to predict what might reappear next.
  2. Enemies became harder to read because their decks were also entirely unique.

The new structure is now much simpler:

Shared cards create a common language. When players see a familiar card appear on an enemy field, they immediately understand the threat.

Problem #3: Engine Stall

The final major issue was engine stalls. The combat system is built around creating card engines, combinations of cards that reinforce each other.

For example, a damage engine might look like:

Or a defensive engine:

The problem appeared once enemies were added. Some early enemies intentionally do not target cards because each enemy teaches a different combat lesson.

That created a strange situation where the player could fill the battlefield with cards and have no way to change them. The enemy wasn’t destroying them, the player couldn’t replace them, so combat stalled out.

Card Decay

The solution was a new mechanic: Card Decay.

Two rules were added to the combat system:

  1. Every turn a card remains on the battlefield, it loses 2 HP.
  2. Every time a card executes, it loses 4 HP.

This change solved several problems at once.

Originally I considered adding a Discard Card action so players could manually remove cards. But that created a different problem: complexity.

The action list already looked like this:

Available Actions

Adding discard actions would introduce three additional decisions every turn. Card Decay solved the stall problem without increasing the decision surface.

It also creates additional tension for the player:

OR

Players can’t instantly fix a bad engine anymore. But the system ensures bad engines don’t last forever.

What the Prototype Taught Me

The biggest lesson from this prototype is that systems that look correct in isolation behave very differently once they begin interacting with each other. Many of the problems above only became visible once I could actually walk around the world and play real matches instead of simulations.

Where To Next?

These past two weeks have been some of the most enjoyable development time so far. Seeing the overworld systems and the combat system finally interact turned the prototype into something that actually feels like a real game.

The next step is publishing the prototype. As of March 7th, 2026, I’m finishing a few remaining pieces of functionality before uploading it to Itch.

Once it’s live, I’ll post the link here. After that, development moves into the next phase: Defining the visual identity and art direction of the game.

Up Next: TBD