Progression Without a Treadmill

Progression Without a Treadmill

April 27, 2026 Off By Tobias Lindqvist

I spent three months of my life building a “dynamic scaling system” for my first solo project, convinced that complexity was the same thing as depth. I thought I was being clever, but all I actually did was create a mathematical treadmill that made every player feel like they were running through waist-deep mud. Most tutorials on how to design progression will tell you to focus on math, curves, and dopamine loops, but they completely ignore the psychological cost of the journey. They treat players like spreadsheets to be optimized rather than people who are making a conscious choice to spend their limited time in your world.

I’m not here to give you a lecture on exponential growth formulas or how to balance an XP curve to ensure long-term retention. Instead, I want to talk about the choices you are forcing your players to make every time they click a button. I’m going to show you how to look past the numbers to see what your systems are actually saying to your community, and how to avoid the mistake of accidentally building a job instead of a game.

Table of Contents

Rewriting Your Experience Point Curves to Stop Misleading Players

Rewriting Your Experience Point Curves to Stop Misleading Players

Most devs treat experience point curves like a math problem to be solved, but they’re actually a psychological contract. When you flatten that curve too much, you aren’t just making the game “accessible”; you’re telling the player that their time has zero value. If the jump from level 10 to 11 feels identical to the jump from 40 to 41, you’ve effectively killed the sense of momentum. You’ve turned a journey into a treadmill. You aren’t designing a sense of growth; you’re designing a chore.

The mistake I see most often is a curve that fails to account for the friction of the gameplay loop mechanics. If your XP requirements skyrocket but the actual activities required to earn them stay the same, you haven’t increased the challenge—you’ve just increased the boredom. You’re competing with the player’s desire to actually play the game versus their desire to watch a progress bar move. To fix this, your experience point curves need to be synchronized with the complexity of the tasks. If the grind gets harder, the rewards—whether they are gear, new abilities, or just a change in scenery—need to feel like they were earned, not just tolerated.

Skill Tree Architecture Building Choices Not Just Checklist Tasks

Skill Tree Architecture Building Choices Not Just Checklist Tasks

The biggest mistake I see in modern RPGs is treating a skill tree like a glorified grocery list. You unlock Point A, which unlocks Point B, which eventually lets you hit harder. That isn’t a choice; that’s a chore. When your skill tree architecture is just a linear path of mandatory upgrades, you aren’t actually giving the player agency—you’re just handing them a long, interactive receipt. You’re telling them, “To play this game correctly, you must follow this exact sequence of buttons.”

If you want real player engagement, you have to stop designing for completion and start designing for consequence. A good tree should force a player to decide what they are willing to lose. If I invest heavily into a high-mobility build, I shouldn’t just be “faster”; I should be fundamentally incapable of playing a tank role. Real choice happens in the tension between two different playstyles. When a player looks at a node and thinks, “If I take this, I can’t do that,” you’ve actually succeeded. You’ve moved past simple reward systems in game design and started building a character identity.

The Hidden Syntax of the Level-Up: 5 Rules for Not Lying to Your Players

  • Stop treating gear as a stat stick and start treating it as a key; if a new sword only increases damage by 2% but doesn’t change how the player interacts with a mob, you aren’t rewarding them, you’re just asking them to do more math.
  • Watch your “dead zones” like a hawk; if there is a stretch of progression where the player is just clicking the same button to fill a bar because the next milestone is too far away, you haven’t built a loop, you’ve built a chore that competes directly with their desire to actually play the game.
  • Design your prestige systems to be meaningful, not just cosmetic; if the “endgame” is just a different colored skin on the same old mechanics, you’re telling the player that their time has a ceiling, and they’ll start looking for a game that actually respects their investment.
  • Avoid the “illusion of choice” trap in your talent trees; if every player eventually funnels into the same single build because it’s the only one that mathematically works, your skill tree isn’t a playground, it’s a narrow hallway disguised as a map.
  • Respect the player’s attention economy by making sure every milestone offers a new way to play; if the reward for ten hours of grinding is just a slightly higher number on a tooltip, you’re competing with every other dopamine hit in their life, and you’re probably going to lose.

The Final Sentence

Designing progression: The Final Sentence.

At the end of the day, designing progression isn’t about balancing a spreadsheet or making sure the math stays airtight; it’s about being honest with your players. If your XP curve is a lie that promises a power spike but delivers a slog, they’ll feel it. If your skill tree is just a glorified shopping list of passive buffs, they’ll realize they aren’t actually playing a character, they’re just filling out a form. You have to remember that every time a player clicks a button to upgrade a stat, they are making a silent contract with you. They are saying, “I am willing to invest my time here because you promised me something meaningful.” If your systems are just noise, they’ll stop reading your sentences and start looking for the exit.

I know how easy it is to get lost in the weeds of numbers, especially when you’re building something solo and every single variable feels like a life-or-death decision. But try to step back from the code and look at the human cost of your mechanics. Don’t just build a loop that keeps them busy; build a loop that makes them feel like they are actually going somewhere. A great progression system shouldn’t just make a player stronger—it should make them feel like they’ve earned the right to be. Stop designing for retention, and start designing for agency. That’s the difference between a game that people play because they have to, and a game they play because they can’t imagine being anywhere else.

Frequently Asked Questions

How do I know when I've accidentally turned a meaningful choice into a mandatory chore that players are just clicking through to reach the next tier?

You know you’ve messed up when your players stop talking about the impact of a choice and start talking about the cost of it. If the community discourse shifts from “I chose this build because it changes how I play” to “I have to click this node just to unlock the actual fun,” you haven’t designed a choice; you’ve designed a toll booth. When the mechanic starts competing with the core gameplay loop for attention, you’ve lost.

At what point does a progression curve stop feeling like a rewarding climb and start feeling like a tax on the player's time?

It’s the moment the math stops serving the fantasy and starts serving the spreadsheet. A curve feels like a climb when every new level grants a tool that changes how you play. It becomes a tax the second the reward is just “more of the same, but slower.” If I’m grinding ten hours for a 2% stat increase just to keep up with a gear treadmill, the game isn’t challenging me—it’s just billing me in hours.

If I'm building a small-scale game, how do I balance giving players enough depth to care about their build without needing a massive, complex economy to support it?

Stop trying to build a marketplace to solve a math problem. If you don’t have the bandwidth for a complex economy, focus on “meaningful friction.” Instead of a thousand different currencies, give players a single, finite resource that forces a hard choice. If they spend it on a powerful perk, they can’t spend it on utility. Depth doesn’t come from the number of items in a shop; it comes from the weight of the trade-offs you force them to make.

About Tobias Lindqvist

Every system in a game is a sentence about what the designer wants you to do. Grind is a sentence. So is a queue timer, a loot table, a guild bank permission screen. I write about what those sentences actually say, and why so many of them say something the designer did not intend. I build a game alone, badly and slowly, which means I have made most of these mistakes myself and can tell you what they cost.