Most game devs secretly believe they’ll nail a mechanic in the frist try.

Reality is not that kind.

When I studied game development at DigiPen, one of my instructors was Rich Rowan, the game designer behind the digital version of UNO. In his very first lecture to game designers, he hammered one point: you will do this far more times than you think.

Rich told us it took him around 200 iterations just to get the “card gravity” feeling right in UNO.

Not 2.
Not 20.
About two hundred separate tweaks until the way cards fell, slid, and landed finally felt correct.

I’ve heard that same story from him multiple times over the years. It’s not a cute anecdote. It’s a warning label for game design:

“You’re going to do this a lot before it feels good.”

And that’s before we talk about everything else in your game.

How 100 Days Turns Into 10 Years

Let’s be generous and say you only need 40 serious iterations to get your core mechanic from “meh” to “actually good.”

That’s already far less than Rich’s 200 passes on UNO’s card gravity.

Now look at what happens when you change nothing except the speed of your loop.

Scenario A: One iteration every 3 months

• 40 iterations × 3 months
• = 120 months
• ≈ 10 years just to improve one core piece from okay-ish to solid.

That’s what happens when every iteration means:

• Big code changes
• New art and content
• Long internal debates
• Then maybe one real playtest

Scenario B: 2–3 iterations per week

Say you average 2.5 iterations per week:

• 40 iterations x 2.5 per week
• ≈ 16 weeks
• ≈ 100–120 days for the same 40 attempts.

Same designer.
Same idea.
Same number of tries.

The only difference is how fast you loop and how small each change is.

The more at‑bats you take, the less you’re relying on guessing correctly once. It’s not about being a genius; it’s about buying more chances to be wrong quickly.

The Hidden Tower of Assumptions

Iteration speed is only half the story. The other half is assumptions.

When most teams start a game, they’re already standing on an invisible stack of assumptions:

• “Players will understand this resource system.”
• “This movement model will feel intuitive.”
• “These enemy behaviors will be readable.”
• “This UI layout will be obvious.”

Then they add more layers on top:

• New systems on top of untested systems
• Extra UI on top of unclear flows
• More enemies on top of shaky core movement

By the time they finally do a real playtest, they see a wall of problems:

• “People are lost on the first screen.”
• “Nobody uses half the abilities.”
• “Everyone ignores the cool system we spent two months on.”
• “Difficulty feels random.”

What they’re actually seeing is not 50 independent bugs.
They’re seeing the cost of their original, untested assumptions.

Because everything is tangled together, it’s almost impossible to see where the real rot started. When you build over sand, every problem looks the same: “The game feels off.”

Shrink the Slice, Kill Assumptions Early

The way out is simple, but not easy:

Stop trying to fix the whole tower. Start with one brick.

Pick one tiny part of the game and make that your universe for a while:

• Just the jump arc
• Just the basic card play loop
• Just the first 10 seconds of input and feedback
• Just one enemy vs one player in one room

Then:

1. Write down your assumptions.
   “Players will try to move first.”
   “They’ll see this as a safe space to experiment.”
   “They will read this icon as ‘attack’.”

2. Build the smallest thing that can prove you wrong.
   Grey boxes, placeholder art, hacked controls. Ship something ugly but testable.

3. Playtest that slice until it’s boring.
   Not visually boring. Design boring: so many iterations that nothing in that slice surprises you.

4. Only then stack the next layer on top.
   Once those assumptions are retired (confirmed or replaced), you’ve poured concrete. Now it’s much safer to add more.

If you want a concrete way to start doing this, that’s exactly why I built the Game Dev Starter Kit: to walk you through picking a tiny slice, building a fast prototype, and getting it into players’ hands without spending months guessing.

Why AAA Keeps Making “The Same Game” (And Why That’s Good For You)

Here’s the uncomfortable truth.

Big studios are often spending tens or hundreds of millions on a title. They have to play things relatively safe:

• They lean on proven control schemes.
• They reuse camera models and movement feel.
• They stick to HUD patterns players already recognize.
• They bring forward enemy archetypes that they know work.

From the outside, it looks like “the same game again and again.”
On the inside, it’s this:

They’re building on top of a giant, expensive book of lessons they’ve already paid for.

Thousands of assumptions have already been tested, logged, and folded into their pipelines. They’re not starting from scratch every time, because starting from scratch at AAA budget is Russian roulette with a fully loaded gun.

As an indie, you’re in the opposite position:

• You don’t have that book of internal knowledge yet.
• You do have the luxury to try weirder ideas that would be too risky for AAA.
• Your real advantage isn’t money. It’s your ability to move faster on smaller, weirder bets.

But that doesn’t remove the need for 40–200 iterations.
It just means you can do those iterations on:

• Smaller prototypes
• Stranger mechanics
• Bolder mixes of genres

…without burning half a billion dollars to find out you were wrong.

Your job is to use that freedom responsibly: high creativity, high iteration speed, low ego around your assumptions.

The Game Dev Starter Kit is built to help with exactly that early stage: turning ideas into small, testable prototypes and getting your first honest playtests so you’re not just layering more assumptions.

How To Actually Speed Up Your Loop

Here’s a practical way to turn this into a habit, not just a nice idea:

1. Define one design question per week.
   “Does this jump arc feel responsive?”
   “Can players understand the basic turn order without a tutorial?”
   “Is this enemy readable at a glance?”

2. Limit yourself to one mechanic or one situation.
   Don’t test five systems at once. You won’t know what actually changed the result.

3. Commit to 2–3 playtest-driven iterations per week.
   That might mean:

   • Two internal tests and one external friend test, or
   • Two friend tests and one quick online session.

4. Measure what players do, not just what they say.
   Where do they hesitate?
   Where do they spam buttons?
   Where do they ask “what do I do now?”

5. Write down one lesson per iteration.
   Store it. That’s how you build your version of AAA’s “book of knowledge.”

Conclusion: The Real Question

Most people ask:

“Do I have what it takes to make a great game?”

That’s the wrong question.

A better one is:

Am I willing to shrink my iterations so I can afford to do the 40–200 tries it actually takes?

Because whether your game gets “pretty good” in 100 days or 10 years has a lot less to do with talent…
and a lot more to do with how fast you’re willing to test your assumptions, be wrong, and try again.

If you’re early and still figuring out your core loop, start small: grab the Game Dev Starter Kit, run your first tiny prototype, and get a few honest playtests under your belt. It’s the free way to start building your own “book of lessons” instead of stacking more guesses.

If you already have something built and want deeper help making it intuitive and engaging for real players, the Game Design Offer is my starting point: four focused Concept to Demo sessions where we zoom in on your core loop, kill shaky assumptions, and design a faster iteration rhythm so your next 40 changes actually move you toward “good,” not just “different.”

FAQ about Game Iterations

How many iterations does a typical mechanic really need?
There’s no magic number, but “dozens” is normal and “hundreds” isn’t rare. The point of the UNO story isn’t that 200 is special, it’s that 3–5 tries is almost never enough for something to feel great.

How small should one iteration be?
Small enough that you can test it in a day or two. One variable, one situation: just the jump arc, just the basic card play, just one enemy in one room. If you’re changing three systems at once, it’s not an iteration, it’s a new game.

What if I don’t have access to real players yet?
Start with anyone who isn’t you or your team: friends, other students, local devs. The goal is fresh eyes. As you learn more about your target player, you can tighten who you test with, but you don’t need a 1,000‑person survey to learn that your jump feels bad.

How do I know when to move on from one slice?
When each change produces smaller and smaller differences, and your testers mostly breeze through that slice without confusion. If feedback shifts from “this feels wrong” to “this feels fine, what’s next?”, you’re ready to stack another layer on top.

I see tons of problems in playtests. Where do I even start?
Start at the foundation: first 10–30 seconds of control, feedback, and clarity. Fix what players touch first (movement, camera, basic actions) before you touch progression, metagame, or content. Otherwise you’re decorating a house with a broken floor.

How do I keep track of all these lessons?
Keep a simple “Design Log”: date, what you changed, what you tested, what happened, and one takeaway. Over time, that becomes your personal version of AAA’s internal knowledge base instead of repeating the same mistakes on every new project.