Chapter 25: Progression Systems — Experience, Skill Trees, and the Feeling of Getting Stronger

There is a moment, somewhere in the first three hours of a well-designed game, when the player realizes they are better at it than they were when they started. Maybe they dodged an attack they would have taken an hour ago. Maybe they fired off a combo they could not have executed yesterday. Maybe they just unlocked a double jump and the world, suddenly, has become larger. Whatever the trigger, the realization is the same: I have grown. The game registers that growth. The world reflects it back. And the player, who an hour ago was a beginner, now feels — not expert, but underway. Moving. Progressing.

This feeling is the quiet engine of why players keep playing. It is why the free-to-play industry built entire revenue models on the shape of XP curves. It is why Dark Souls, a game with almost no numerical progression, feels as rewarding as Diablo, a game with almost nothing but numerical progression. It is why the Metroidvania genre still works in 2026, forty years after Metroid. Progression — authored, tuned, surfaced to the player — is one of the handful of forces in game design strong enough to carry a game across its rough patches and make tedium feel like investment.

It is also, in my experience, the single system designers most often botch on their first project. They tune XP curves by intuition and ship a game that grinds for ten hours in the middle. They build skill trees that look branching but funnel every player to the same optimal build. They add abilities without thinking about the spaces those abilities will gate, so the level design and the progression system drift apart. They ship "progression" that is really just "bigger numbers" and wonder why playtesters report the game feeling samey despite all the upgrades.

This chapter is about doing it on purpose. We will look at the two fundamental axes of progression (player skill and character power), the mathematics of XP curves, the major skill-tree topologies, the Metroidvania alternative, the horizontal-vs-vertical debate, soft and hard caps, and the chronic AAA problem of power creep. Then we will implement a working progression system in GDScript — XP gain, level-up, ability unlock, and a simple skill tree — that you can drop into your prototype tonight. By the end, you should be able to look at the progression system in any game you play and say: this is the shape they chose, and here is what it costs them. That is the practitioner's view.

Why Progression Matters

Back in Chapter 12 we talked about motivation and reward — the dopamine loops, the Skinner-box dangers, the difference between intrinsic and extrinsic motivators. In Chapter 13 we talked about challenge and mastery — the sensation of becoming skilled at something hard, and the pedagogical arc that gets a player there. Progression systems sit at the intersection. They translate the feeling of getting better (which is mostly psychological, mostly about challenge and mastery) into visible artifacts (level numbers, ability icons, tree nodes lit up) that the player can point to.

That translation matters. Without it, many players cannot perceive their own improvement. The player who beats Dark Souls' first boss after ten attempts has absolutely gotten better at the game — their dodge timing is sharper, their pattern recognition has improved, their patience has thickened. But their character is almost exactly the same as when they started. If FromSoftware had not given them something to show for those ten attempts — a souls reward, a level-up, an item — many of those players would have bounced off. The growth was real; the marker was missing. Markers are what progression systems sell.

Conversely, a progression system without underlying growth is a con. Diablo III's paragon levels at launch were widely criticized because they showered players with numerical increases that did not translate to meaningful new capabilities. The player's character got stronger, the numbers on screen got bigger, but the feel of the game did not change. Numbers without growth is the hollow ring at the bottom of badly-designed RPGs.

The designer's target is the overlap: real growth, visibly marked. That is progression worth the name.

💡 Intuition: Think of progression as the interest rate on the player's time. Every hour they invest, you owe them some perceptible return. Sometimes the return is a new ability (huge interest). Sometimes it is a statistical upgrade (small interest). Sometimes it is a moment of pure challenge overcome (high interest, paid in skill). But if the rate ever drops to zero — an hour of play with nothing to show — the player calculates their position and walks away. Keep the interest rate positive. Vary its compounding. Deliver it on schedule.

Progression also does work beyond motivation. It serves as a pacing instrument: if you want the player to slow down and explore at hour six, you reduce the XP rate; if you want them sprinting toward the climax at hour thirty, you accelerate it. It serves as a difficulty lever: unlocks are gated by level, so you can tune encounter design to match expected player capabilities. It serves as a narrative device: the character who started as a farmer has become a warlord, and the progression system tells that story in mechanics. It serves as a content multiplier: twenty hours of content can feel like forty if progression pulls the player through it at the right rate. The progression system you design does all of these things simultaneously, or fails at all of them.

Two Kinds of Progression: Player Skill vs. Character Power

Every game makes a choice, often unconsciously, about where its progression lives. The two poles are:

Player skill progression. The player, the human holding the controller, becomes better at the game. They learn patterns. They improve reaction time. They develop strategic intuition. The character in the fiction does not necessarily grow stronger; the person playing the character does.

Character power progression. The character in the fiction becomes stronger — more hit points, more damage, more abilities, better gear. The player, the human, does not necessarily improve; they are carried forward by the character's growing capabilities.

No game is purely one or the other. But games have ratios. And the ratio is a fundamental design choice with downstream consequences for everything else — difficulty tuning, content pacing, replay value, the kinds of players the game attracts.

Consider three points on the spectrum.

Celeste sits near the "all player skill" end. Madeline has almost no character progression at all. She gets a small number of moves — climb, dash, jump — in the first thirty seconds and has all of them for the rest of the game. She does not level up. Her dash does not get stronger. The assist-mode toggles aside (which are accessibility, not progression), her mechanical capabilities at hour ten are identical to her mechanical capabilities at minute one. And yet the game feels like a progression story. It feels that way because you, the player, become dramatically more skilled. The chapter that broke you in your first ten attempts becomes muscle memory by your hundredth. That is progression — just not progression the character system is tracking.

Dark Souls sits in the middle. The player's skill growth is massive — dodge timing, stamina management, pattern recognition, weapon matchups. A veteran Dark Souls player is categorically different from a beginner. But the character also grows, just modestly. Levels are earned by spending souls, each level makes the character slightly stronger, and by endgame the character is perhaps three to five times more capable than at the start. This is a huge increase in absolute terms, but it does not dominate the experience. A skilled low-level player can still beat most of the game; an unskilled high-level player cannot. The character-power system is real but deferential — it supports the player's skill growth, does not substitute for it.

Diablo (any entry, but especially Diablo II and Diablo III) sits at the "all character power" end. The player's skill matters somewhat, but the character's power grows exponentially. By endgame, the character does not deal thirty percent more damage than at the start — they deal ten thousand times more damage. Enemies scale to match. The gameplay loop at level 1 and the gameplay loop at level 70 look almost identical in abstract terms (click enemy, enemy dies, loot drops), but the numbers on screen differ by orders of magnitude. The player's experience of growth is the character's numerical ascent. Genre aside, this is a different contract with the player than Celeste offers.

🎮 Case Study: Hollow Knight is one of the most interesting points on this spectrum. Its character progression is modest (a handful of charms, a few new traversal abilities, some health and mana upgrades) but the player-skill curve is enormous. A player who has just started Hollow Knight and a player two dozen hours in are not the same person — the second has learned to read boss tells, to manage spacing, to pogo off spikes, to conserve soul. The Knight is only slightly stronger; the player is transformed. Team Cherry's achievement is holding the character-progression curve low enough that the player-skill curve can be felt, while still providing enough unlock-based progression to serve as pacing.

Which ratio should your game choose? It depends on what you are selling the player.

If your game is pitching mastery — the promise that skilled play will be recognized and rewarded — lean toward player-skill progression. Character growth should be modest enough that it never substitutes for skill. Celeste, Dark Souls, Hollow Knight, Devil May Cry all make this promise and deliver it.

If your game is pitching power fantasy — the promise that the player will become demonstrably, numerically, visibly stronger — lean toward character-power progression. Skill can matter but must not dominate. Diablo, Borderlands, Path of Exile, most MMORPGs make this promise.

If your game is pitching story and identity — the promise that the character will evolve narratively and mechanically in parallel — you want a middle path. Both kinds of progression matter, and they reinforce each other. The Witcher 3, Horizon Zero Dawn, Mass Effect, and most single-player RPGs sit here.

Pick your ratio early. The rest of your progression system follows from it. A game that thinks it is selling mastery but built a Diablo-scale character-power curve will feel unsatisfying to skilled players and grindy to casuals. A game that thinks it is selling power fantasy but minimized character growth will feel thin. Know what you are selling.

XP Curves and the Math of Leveling

If your game has experience points, it has an XP curve: a function that maps level number to XP required to reach it. The shape of that curve is one of the most consequential numerical decisions in your entire game. It determines how often the player levels up, where the grinding valleys lie, and whether endgame progression feels fast, slow, or nonexistent.

Four curve families dominate the genre.

Linear

xp_for_next_level = base * level

Each level costs a constant increment more than the last. Level 1 to 2 costs 100; level 2 to 3 costs 200; level 3 to 4 costs 300; and so on. Total XP to level N is on the order of N².

Pros: Simple to understand. Predictable. Players can estimate time-to-next-level accurately. Early and late progression feel similar.

Cons: Can feel monotonous. No built-in pacing shift across the game. In a game where enemies scale up in XP reward (which most games have), the actual time per level can drift unintentionally — the curve's linearity is defeated by non-linear reward scaling.

Linear works well for shorter games (10-20 hour campaigns) where the level range is small (1-20 or so). It is the default choice if you have no reason to pick another.

Exponential

xp_for_next_level = base * growth^level

Each level costs a multiple (say, 1.5x) of the previous. Level 1 to 2 costs 100; level 2 to 3 costs 150; level 3 to 4 costs 225; level 10 to 11 costs about 5,800. Total XP to level N grows geometrically.

Pros: Late levels feel meaningful and hard-won. Early levels fly by, which is good for onboarding. The curve is naturally asymptotic — pushing to level 99 is an accomplishment.

Cons: Late-game grind can be brutal. If the game is long and the player is underleveled, the gap becomes uncrossable. The classic World of Warcraft 1-60 grind (in Vanilla WoW) used an exponential curve and frequently took 200+ hours — a fact many players came to resent even as they kept grinding.

Exponential is standard for long MMOs, grind-heavy RPGs, and any game where the design team wants late-game progression to carry significant cachet. Use with caution: it is easy for the late curve to become punishment rather than pacing.

Polynomial (typically quadratic or cubic)

xp_for_next_level = base * level^exponent (with exponent usually between 1.5 and 3)

A middle path. Each level costs somewhat more than the last, but not by a constant multiple — the increments themselves grow. Level 1 to 2 costs 100; level 2 to 3 costs 283 (at exponent 1.5); level 10 to 11 costs about 3,300.

Pros: Combines the intuitive pacing of linear with the late-game weight of exponential. Tunable via the exponent — 1.5 for a gentle curve, 2.0 for moderate, 3.0 for steep.

Cons: Harder for players to estimate time-to-next-level. Requires more balancing work because the curve's behavior shifts across the level range.

Polynomial curves are the most common choice in modern RPGs. Final Fantasy series uses variants. Persona 5. Most Bioware games. If you are unsure, start with a polynomial curve at exponent ~1.8 and tune from there.

Logarithmic / Capped

xp_for_next_level = base + ln(level + 1) * multiplier (or some variant that flattens as levels increase)

Rare in pure form. Each level costs only slightly more than the last, and the curve flattens as levels rise. Implies a game where the designer wants most players to reach the level cap.

Pros: Respects player time. Accessible for casual play. Encourages exploration of endgame content rather than endgame grinding.

Cons: Removes the late-game "brag factor" of high levels. Makes level mean less.

This curve is chosen by games that want level to be only one progression axis among several. Horizon Zero Dawn, for example, has a level cap of 60 that most engaged players will hit by the end of the main story, because the real progression is weapon/armor/skill points, not level.

Choosing the Curve

A useful mental exercise: pick your game's target total length in hours (say, 40). Pick your intended level cap (say, 50). Pick your average session length (say, 2 hours). You now have constraints. Each session should produce roughly one level on average through the middle of the game (level 10-40), faster at the start (3-5 levels per session for the first few hours), and slower at the end (a level per two or three sessions as the player approaches cap). Build a curve that produces those paces given your assumed XP-per-hour rewards.

Then playtest. Adjust. The first playtest will reveal that your reward rates are wrong and your curve is miscalibrated. That is normal. Iterate until the pacing feels right to actual humans, not just in your spreadsheet.

⚠️ Pitfall: The "grinding valley" — a stretch of the level range where the XP cost per level is so high and the enemy XP yield so low that players must repeat content for hours to progress. This almost always happens between levels 25-40 in a 1-60 curve, because designers tune the early and late game carefully and under-tune the middle. Vanilla WoW's 30-50 range, pre-TBC, is the canonical example. If you are shipping a leveling game, playtest the middle range obsessively. That is where grinding valleys hide.

Skill Trees

After XP curves, the skill tree is the next major progression apparatus. A skill tree is a branching graph where nodes represent abilities, passive bonuses, or stat increases, and edges represent prerequisites. Players earn skill points (often one per level) and spend them to light up nodes — shaping their character's capabilities over time.

Skill trees come in many topologies, each with different design implications.

The Tree

Literally a tree, in the graph-theoretic sense: a root node, branches, sub-branches, leaves. Players pick a branch to specialize in. Once they invest points in a branch, pulling back is costly or impossible — the tree enforces commitment.

Diablo II's skill trees are the canonical example. Each class had three trees (warrior/mage/rogue flavor), and players picked one to focus on. A Barbarian who invested in Combat Masteries was committed to that playstyle for the rest of the character. This produced strong build identity and clear roleplay choices.

Strengths: Clear specialization. Build identity. Players can explain their build in one sentence.

Weaknesses: Inflexibility. A misclick can lock a player out of a desired build for the rest of the playthrough. Many games that used strict trees eventually added respec options because players found the commitment too punishing.

The Web

A graph with cycles, multiple paths to the same node, and cross-connections between specialization branches. Players can weave through the web, touching multiple specialties.

Path of Exile's passive tree is the largest and most notorious example. With over 1,300 nodes and hundreds of viable build paths, the web pushes player agency to its extreme. A single build decision at character creation (starting position) echoes across hundreds of hours of play.

Strengths: Enormous build diversity. Theorycrafting community engagement. High replay value — each new character can feel different.

Weaknesses: Analysis paralysis. New players are overwhelmed. Trap builds (paths that look viable but collapse at endgame) punish the uninformed. Requires extensive community resources (wikis, planners, guides) for players to make sense of it.

Webs work for games that expect a long-term engaged community. They fail for games with a more casual audience.

The Sphere Grid

Final Fantasy X introduced the sphere grid — a massive interconnected board of stat nodes and ability unlocks, where characters start at different positions and slowly traverse the grid using "sphere levels" earned through combat. Instead of picking branches, characters walk a path, collecting nodes along the way.

Strengths: Unique visual identity. Spatial progression that feels like exploration. Characters differentiate through where on the grid they travel, not what branch they pick.

Weaknesses: Complex to teach. Late-game grid-breaking (where skilled players send any character anywhere on the grid) collapses the intended class distinctions. Rarely used outside its home series because it is hard to tune well.

The Gem Socket / Gear-Based Skills

Path of Exile (again) couples its passive web with a gear-based skill system: skills come from gems socketed into gear. Swap the gem, swap the skill. Final Fantasy VII's Materia system is the genre-defining example — materia orbs containing magic or abilities slot into weapons and armor, and the player can shuffle them freely between characters.

Strengths: Enormous flexibility. Players can experiment at low cost. Encourages creative builds.

Weaknesses: Skills become gear, which means the progression gets entangled with itemization. Loot chase and skill progression merge, which some players love (more to do) and some hate (muddled systems).

The Talent Calculator

World of Warcraft pre-Cataclysm used talent trees where players could respec for a fee and re-allocate points. This turned the tree into a living document — players updated builds as raids changed, as patches tweaked talents, as their own playstyle evolved. The community built "talent calculator" websites where theorycrafters tested builds in advance.

Strengths: Community engagement. Living systems. Forgiveness for experimentation.

Weaknesses: Invites homogenization — if one spec is optimal, everyone respecs to it, and the "diversity" of the tree is illusory. Later WoW expansions moved away from traditional trees for this reason.

Locked vs. Open Trees

Independent of topology, trees can be locked (early decisions cannot be undone, forcing commitment) or open (players can respec cheaply and frequently, enabling experimentation).

Locked trees produce stronger identity but higher friction. Open trees produce lower friction but weaker identity. Most modern games have moved toward open or partially-open trees — the hostility of true-locked trees has fallen out of fashion as audiences have broadened.

A reasonable compromise: one free respec after the tutorial (so early-game confusion can be corrected), then increasingly expensive respecs thereafter, with a full respec available but costly. This respects both the player who made a mistake and the identity-producing function of commitment.

⚠️ Pitfall: The "illusion of choice" skill tree. This is a tree that looks branching but in practice funnels every optimally-playing player into the same path. Usually happens when one branch is mathematically dominant (its nodes give bigger bonuses for the same cost) or when a single node is so critical that everyone must take it regardless of "specialization." The cure is extensive playtesting by multiple archetypes of player, followed by ruthless rebalancing of outlier nodes. Your design intent is diversity; the actual math must support it.

Trap Builds

Related pitfall: the trap build. A combination of tree choices that looks reasonable but is non-viable at endgame. The player, unaware, invests forty hours building toward a character that cannot clear the endgame content.

Trap builds are particularly common in webs and large trees. Path of Exile is notorious for them. The community's response is extensive theorycrafting and build guides, which means the game effectively requires external resources to play well.

If your game has a complex tree, you have two choices: ensure that no build is a trap (through exhaustive balancing), or embrace the trap as part of the challenge (Souls-style "this game is opaque and that is the point"). Either is defensible. Accidental traps — where you did not intend to punish players but did — are not.

Unlock-Based Progression

Some games reject numerical progression almost entirely and build their growth around ability unlocks. The character does not get stronger; they get different. New abilities open new parts of the world, new combat options, new puzzles. This is the Metroidvania model, and it is one of game design's most elegant inventions.

Metroid (1986) established the template. Samus starts with limited capabilities. As she progresses, she gains abilities — the morph ball, missiles, the ice beam, the grappling hook, the screw attack — each of which functions as both a combat option and a spatial key. The morph ball opens narrow passages. Missiles open missile-doors. The grappling hook lets her cross gaps. The world is designed around anticipated abilities: early on, the player sees a passage they cannot reach, and they know that later, when they have the right ability, they will return. The returning is itself the progression.

Castlevania: Symphony of the Night (1997) refined the model for 2D action-adventure, adding RPG layering (XP, stats, gear) on top of the ability-unlock backbone. Metroid Prime (2002) brought it into 3D. Ori and the Blind Forest (2015) and Ori and the Will of the Wisps (2020) are the contemporary gold standard for tight ability pacing.

And then there is Hollow Knight, which is — to my mind — the most perfectly tuned Metroidvania progression system ever shipped. The Knight's ability list is modest (dash, wall jump, double jump, a handful of movement upgrades and a few nail/spell upgrades), but each one unlocks entire regions of the world that were previously teased but inaccessible. The player's mental map of Hallownest expands not gradually but in punctuated bursts — now I can reach there — and the world reveals itself in layers.

The unlock-based model has distinct advantages.

Spatial progression replaces numerical progression. Instead of the character's HP doubling, the world's accessible area doubles. This feels like a bigger change because it is more tangible. The player can point to the new region and say, "I can now go there."

Teaches by environment. When the player gets a new ability, they go test it. Good Metroidvanias are designed so that immediately after receiving a new ability, the player encounters a space that rewards using it — a room that demonstrates the mechanic and inducts them into its use. This is pedagogy without tutorial.

Tight level design coupling. Because the world is gated by abilities, the level designer and the progression designer are the same role, effectively. You cannot design one without the other. This forces discipline — no bolted-on progression, no unused abilities, no dead gates.

Replayable through sequence breaking. Advanced players discover they can skip abilities, reach areas "out of order," and break the designed progression. This is often not a bug but a feature — speedrunners and completionists build a second game out of sequence-breaking the first.

The model has costs too.

Demands meticulous world design. If the level designer has not planted the right gates in the right places, abilities feel pointless and the world feels arbitrary. This is much harder than it looks.

Limits mechanical complexity. An unlock-based game cannot have dozens of abilities — the world would need to be too large to accommodate gates for each. Most Metroidvanias ship with 8-15 unlock-gated abilities, not 50. The mechanical ceiling is lower than in a stats-driven RPG.

Assumes player curiosity. A player who does not explore does not experience the unlock-based model. Games that pair this model with aggressive nudge design (Ori) make it work for broader audiences; games that refuse to nudge (Hollow Knight) require a more self-directed player.

🛠️ Practitioner Tip: The ability-as-key pattern is not limited to Metroidvanias. Zelda: Breath of the Wild uses it for the four Divine Beast abilities. Dark Souls uses it subtly — certain boss-kills unlock areas, certain items grant traversal. Even Celeste's chapter-by-chapter ability additions are a lightweight form of it. If your game has spatial progression at all, consider whether one or more of your abilities should function as a spatial key. The coupling tightens both the world and the ability set.

Horizontal vs. Vertical Progression

This is the dichotomy that shapes modern live-service design more than any other.

Vertical progression means the character becomes numerically stronger. Each tier of gear deals more damage than the last. Each level adds to HP. The progression axis is power, and it only goes up.

Horizontal progression means the character gains options without necessarily gaining power. A new weapon is different, not stronger. A new ability offers a different tactical tool. The progression axis is variety.

Every game uses both, but games weight them differently.

Diablo III at launch was almost purely vertical. Each patch added higher-tier items that deprecated the previous tier. A player who stopped playing for a year came back to find their gear obsolete and the game essentially starting over. Vertical progression is engaging in the short term — numbers go up! — but corrosive in the long term, because everything you earned yesterday is trash today.

Path of Exile layers in substantial horizontal progression. Its skill gem system means a new gem is not "stronger" than an old one; it is different. A player who unlocks a new gem adds it to their toolkit rather than replacing something. Gear has vertical elements (tiers), but the gem system, the passive web, and the crafting system all tilt horizontal. The result is a game where a five-year veteran still has things to learn — because the horizontal space is immense and most of it remains unexplored.

Borderlands is interesting. The guns have different behaviors (horizontal) and different power tiers (vertical). A legendary shotgun from the early game is typically worse than a common shotgun from the late game (vertical wins), but within a tier, the horizontal variation is the selling point — "what weird new gun am I going to find?"

The endgame problem in vertical-dominant games is real. Once the player has maxed level and maxed gear, there is nowhere to go. The only content left is lateral — alternate builds, harder difficulty modes, cosmetics. The designers must invent new vertical progression (paragon levels, seasons, ascensions) to keep players engaged, which devalues the previous progression. It is a treadmill, and players get off it eventually.

The endgame solution horizontal-heavy games use: the target is the game itself, not the character's number. A Path of Exile player who has reached endgame is not done — they are starting a new character to try a new build. The progression continues laterally, into new territory rather than up a taller mountain. This retains players longer, but it requires design investment in lateral variety, which is expensive.

If your game plans a long tail, tilt horizontal. If your game is a forty-hour campaign, vertical is fine and will feel satisfying. Mixing them is the modern standard — mostly vertical within a single playthrough, with horizontal options (different character classes, different playstyles) for replay.

Soft Caps and Hard Caps

At some point, progression has to stop. Or rather, it has to change shape. The player cannot become infinitely strong within a designed game. The designer chooses how progression slows down or stops.

A hard cap is a ceiling: the character cannot progress past it. Level 60 and that's it. Gear ilvl 200 and that's the max. Hard caps are clean and clear, but they can feel abrupt.

A soft cap is a region where progression slows dramatically. Each additional point of strength gives less benefit than the last. Investment past the soft cap is possible but yields diminishing returns. Players can push past it if they want, but the cost-benefit ratio worsens.

Both have their place.

Path of Exile uses soft caps extensively. Resistance caps at 75% by default, but with gear and passives, players can push it higher at enormous opportunity cost. The cap is a design signal: "here is where the sensible return lives; past this, you are paying a premium." Meanwhile, their level system is technically capped at 100, but leveling past about 95 takes hundreds of hours and the actual power increase is minor — effectively a soft cap with a symbolic hard cap.

Borderlands uses hard caps on level and loose soft caps on gear. Level 72 is the cap and there is no pushing past it; gear tiers soft-cap at legendary rarity, but within that tier, random variance creates a long tail of incremental improvement.

Dark Souls uses soft caps on individual stats. Pushing strength past 40 gives much less damage per point than pushing it from 30 to 40. Pushing past 60 gives almost nothing. The math encourages diversification — once strength is at soft cap, invest elsewhere.

Diminishing returns is the mathematical shape of most soft caps. It can be encoded many ways: a logarithmic function, a piecewise function with different slopes in different regions, a hard multiplier change past a threshold. The implementation varies; the design intent is the same. You want the player to feel that further investment is less rewarding, so they diversify or stop.

The alternative to diminishing returns — flat linear scaling to the cap — is almost always a mistake. It creates a single dominant strategy (max one stat before touching others) and destroys build diversity. Almost every modern RPG uses diminishing returns in some form. Use them.

💡 Intuition: A soft cap is a nudge. It whispers to the player: "you can keep pushing here, but there are better places to invest." A hard cap is a wall. It says: "you're done; look elsewhere for more." Use soft caps when you want to encourage diversification within a build. Use hard caps when you want to draw a clear line between "still progressing" and "working on something else." Most games mix them.

Power Creep

Here is a sentence that has launched a thousand balance-patch arguments: the new expansion needs to be bigger than the old expansion.

Of course it does. If the new expansion is not bigger, why would players buy it? New gear must be better than old gear. New levels must be higher than old level cap. New enemies must be tougher than old enemies. The entire commercial logic of expansions and patches assumes an ever-rising ceiling.

This is power creep. It is the gradual inflation of the game's numerical scale across content releases. And it has costs the designers almost always underestimate at the time.

Old content is devalued. The raid that was hard last expansion is trivial now, because everyone is 20 levels higher. The gear you worked to obtain is replaced by a random drop in the starter zone of the new area. WoW has been running this pattern for twenty years; the original raids that defined the game in 2004 are now one-shot solo content. Some players find this freeing ("I can finally solo Onyxia!"); others find it deflating ("my hard-earned gear is garbage").

Balance fractures. New content is balanced around new power levels, so the old content becomes trivially easy. Returning content (re-running an old zone) feels pointless. The game loses lateral depth as verticality expands.

New players are overwhelmed. A newcomer must either experience all the old content at devalued difficulty (which teaches the wrong lessons) or skip it entirely (which loses story and systems context). Onboarding gets harder with each release.

The creep accelerates. Once the team has committed to "bigger is better," each release must outdo the last. The numbers spiral. WoW had to introduce "item level squish" patches — deliberately cutting all stats by a factor — to keep the numerical scale manageable. Destiny 2 went through a similar squish.

Several genres have developed structural responses to power creep.

Standard rotation (TCGs). Hearthstone introduced a "Standard" format where only the newest expansions are legal. Older sets rotate out of the competitive ladder. This contains the creep to a two-year window. Players who want old cards can play the "Wild" format, but competitive Standard stays fresh and balanced. Magic: The Gathering has used this pattern since 1995 — the Standard format cycles through the most recent sets, while older sets live in separate formats (Modern, Legacy, Vintage) with their own metas.

Seasons / leagues. Diablo III's seasons, Path of Exile's leagues, Destiny 2's seasons. Every three to four months, a fresh progression cycle starts. Characters from the previous season carry forward (usually) but the chase items reset. This preserves the satisfaction of progression without requiring an infinite vertical scale.

Prestige / reset systems. The character voluntarily resets their progression in exchange for a permanent bonus. Call of Duty's original prestige, Diablo II's ladder resets, Path of Exile's ascendancy. Progression becomes cyclic rather than purely vertical.

Horizontal-heavy design. If progression is mostly horizontal, power creep is less of an issue. New content adds new options, not higher numbers. Path of Exile's expansions tend more horizontal than WoW's. Not by accident.

If you are shipping a live-service game that will receive content updates, you must decide your power creep policy on day one. Pick one of the structural responses above, or accept that you will creep and plan for periodic squishes. The policy is as consequential as the initial progression design.

Designing Your Game's Progression — A Practical Process

Let us turn from analysis to practice. Here is the process I use when designing a progression system from scratch. It has six steps.

Step 1. State what you are selling. Before any math, answer the question: what promise does this progression make to the player? "You will become a stealth master." "Your character will transform from a child to a general." "You will unlock the whole map through ingenuity." If you cannot write this promise in one sentence, you do not yet know what you are building.

Step 2. Pick your skill-vs-power ratio. On a scale from pure Celeste to pure Diablo, where does your game sit? A rough quantification: what percentage of the player's felt progression comes from their own skill growth versus the character's mechanical growth? 70/30 skill-heavy, 50/50 mixed, 30/70 power-heavy, 10/90 power-dominated? Pick a point and write it down.

Step 3. Identify the progression axes. Most games have three to five. Level (XP), ability unlocks, gear, crafting skills, reputation, consumables, cosmetics. For each axis, decide whether it will be vertical, horizontal, or mixed. For each axis, estimate how long the progression tail should be.

Step 4. Draft the XP curve. If you have an XP system, pick a curve family and initial parameters. Back-compute your session-to-level ratio. Walk through the game chapter by chapter and estimate where the player will be at each milestone. Adjust if the curve produces absurd results ("player is still level 3 when they hit the mid-game boss"; "player is overleveled by chapter 4").

Step 5. Lay out the ability/skill unlocks. List every ability the player will unlock, and note when (which chapter, which level, which story beat). For each unlock, name what it does in the fiction, what it does mechanically, and what content it gates. If an unlock has no gated content, question whether it belongs.

Step 6. Playtest. Your first draft will be wrong. The curve will have a grinding valley. One ability will feel worthless. Another will trivialize content. Playtest mercilessly, adjust, and playtest again. Expect the progression system to be the single most-iterated system in your game. That is normal. It is also why shipping a game without playtesting is shipping a game whose progression is broken.

Worked example — a hypothetical stealth-adventure game:

Promise: "You will transform from a cornered runaway into a master infiltrator." Ratio: 40/60 skill/power (moderate power progression; player skill grows but gear and abilities do most of the lifting narratively). Axes: Level (vertical, XP-driven, cap 30); ability tree (horizontal — stealth vs. combat vs. mobility branches, 20 nodes each); gear (mixed — tiers go up vertically, but individual pieces have horizontal perks). Curve: Polynomial, exponent 1.7. Level 1-10 in the first five hours; 10-20 in the next fifteen; 20-30 in the final ten. Unlocks: Lockpicking at level 4 (gates the heist missions); silent takedown at level 8 (gates the infiltration finales); wall climbing at level 15 (opens the rooftop district); disguise at level 20 (gates the final palace mission). Playtest: TBD.

That is a draft in about fifteen minutes, and it is something a team can react to. The draft will not survive contact with playtesters, but it gives a frame that playtest data can reshape. Start here.

GDScript Implementation

Here is a working progression system for Godot 4.x. We will build three scripts: ProgressionSystem.gd (XP, levels, ability unlock dictionary), SkillTree.gd (node graph, prerequisite check, point allocation), and a small AbilityUnlock.gd that surfaces the unlocks to gameplay systems.

ProgressionSystem.gd

# ProgressionSystem.gd
# Tracks player XP, level, skill points, and ability unlocks.
# Attach as an Autoload singleton so gameplay code can query it globally.
extends Node

signal xp_gained(amount: int, total: int)
signal leveled_up(new_level: int, skill_points_awarded: int)
signal ability_unlocked(ability_id: String)

# Polynomial curve: xp_for_next = base * level^exponent
@export var xp_base: float = 100.0
@export var xp_exponent: float = 1.7
@export var max_level: int = 30
@export var skill_points_per_level: int = 1

var current_xp: int = 0
var current_level: int = 1
var skill_points: int = 0
var unlocked_abilities: Dictionary = {}  # String -> bool

func gain_xp(amount: int) -> void:
    current_xp += amount
    xp_gained.emit(amount, current_xp)
    while current_level < max_level and current_xp >= _xp_for_level(current_level + 1):
        _level_up()

func _xp_for_level(level: int) -> int:
    return int(xp_base * pow(float(level - 1), xp_exponent))

func _level_up() -> void:
    current_level += 1
    skill_points += skill_points_per_level
    leveled_up.emit(current_level, skill_points_per_level)

func unlock_ability(ability_id: String) -> void:
    if not unlocked_abilities.has(ability_id):
        unlocked_abilities[ability_id] = true
        ability_unlocked.emit(ability_id)

func has_ability(ability_id: String) -> bool:
    return unlocked_abilities.get(ability_id, false)

func spend_skill_points(cost: int) -> bool:
    if skill_points >= cost:
        skill_points -= cost
        return true
    return false

Forty lines of GDScript. The progression system exposes three signals (xp_gained, leveled_up, ability_unlocked) that UI and gameplay systems can hook into. The _xp_for_level function encodes the curve — swap that one function to change curve families (logarithmic, exponential, etc.) without touching the rest of the system. The while loop in gain_xp handles the edge case of gaining enough XP for multiple level-ups at once (e.g., from a big quest reward).

Usage in gameplay code:

# EnemyDeath.gd — awarding XP on enemy defeat
extends Node

@export var xp_reward: int = 50

func _on_enemy_died() -> void:
    ProgressionSystem.gain_xp(xp_reward)

Or to check whether the player has unlocked an ability before allowing an action:

# Player.gd — gating the double jump behind an unlock
func _physics_process(delta: float) -> void:
    if Input.is_action_just_pressed("jump"):
        if is_on_floor():
            _jump()
        elif _can_double_jump and ProgressionSystem.has_ability("double_jump"):
            _jump()
            _can_double_jump = false

SkillTree.gd

# SkillTree.gd
# Models a graph of skill nodes with prerequisites and point costs.
# Nodes are registered via add_node; the tree validates allocation requests.
extends Resource

class_name SkillTree

class SkillNode:
    var id: String
    var display_name: String
    var cost: int
    var prerequisites: Array[String]  # ids of nodes that must be allocated first
    var effect: Callable  # invoked when the node is allocated
    var allocated: bool = false

    func _init(p_id: String, p_name: String, p_cost: int, p_prereqs: Array[String], p_effect: Callable) -> void:
        id = p_id
        display_name = p_name
        cost = p_cost
        prerequisites = p_prereqs
        effect = p_effect

var nodes: Dictionary = {}  # id -> SkillNode

signal node_allocated(node_id: String)

func add_node(node: SkillNode) -> void:
    nodes[node.id] = node

func can_allocate(node_id: String) -> bool:
    if not nodes.has(node_id):
        return false
    var node: SkillNode = nodes[node_id]
    if node.allocated:
        return false
    for prereq_id in node.prerequisites:
        if not nodes.has(prereq_id) or not nodes[prereq_id].allocated:
            return false
    return ProgressionSystem.skill_points >= node.cost

func allocate(node_id: String) -> bool:
    if not can_allocate(node_id):
        return false
    var node: SkillNode = nodes[node_id]
    if not ProgressionSystem.spend_skill_points(node.cost):
        return false
    node.allocated = true
    if node.effect.is_valid():
        node.effect.call()
    node_allocated.emit(node_id)
    return true

Fifty lines, most of it data plumbing. The interesting bit is the can_allocate method — a node is allocatable if it exists, isn't already taken, all its prerequisites are allocated, and the player has enough skill points. The effect Callable lets each node fire arbitrary gameplay code when allocated (boost a stat, unlock an ability, register a passive).

Building the tree, somewhere in initialization code:

# Initializing the skill tree with a few starter nodes
var tree := SkillTree.new()

tree.add_node(SkillTree.SkillNode.new(
    "dash_cooldown_1",
    "Quick Recovery",
    1,
    [],
    func(): Player.dash_cooldown *= 0.9
))

tree.add_node(SkillTree.SkillNode.new(
    "dash_cooldown_2",
    "Swift Recovery",
    2,
    ["dash_cooldown_1"],
    func(): Player.dash_cooldown *= 0.85
))

tree.add_node(SkillTree.SkillNode.new(
    "wall_climb",
    "Gecko's Grip",
    3,
    ["dash_cooldown_1"],
    func(): ProgressionSystem.unlock_ability("wall_climb")
))

Each node declares its id, display name, cost in skill points, prerequisites, and an effect. The tree is now a fully-functional graph that validates prerequisites and point costs automatically.

AbilityUnlock.gd

# AbilityUnlock.gd
# A pickup that grants an ability when the player touches it.
# Use for Metroidvania-style spatial progression (ability-as-key).
extends Area2D

@export var ability_id: String = "double_jump"
@export var display_message: String = "Double Jump acquired!"

func _ready() -> void:
    body_entered.connect(_on_body_entered)

func _on_body_entered(body: Node2D) -> void:
    if body.is_in_group("player") and not ProgressionSystem.has_ability(ability_id):
        ProgressionSystem.unlock_ability(ability_id)
        _show_message()
        queue_free()

func _show_message() -> void:
    # Hook into your existing UI system — this is intentionally thin
    print(display_message)
    # In production: fire a signal to a HUD that displays the pickup

Twenty lines. Drop one in your world for each ability pickup, set the ability_id exported variable, and the Metroidvania spatial progression works automatically. Combined with the has_ability gating in the Player controller, you have a complete unlock-based progression system.

There is one more piece worth mentioning — saving and loading the progression state. For a real game, you want the ProgressionSystem to serialize its state to disk so the player's progress persists across sessions. Godot's var_to_bytes and FileAccess APIs make this straightforward; the pattern is to dump current_xp, current_level, skill_points, and unlocked_abilities into a dictionary and write it to a user:// file on save. I leave this as an exercise, because every game's save system has project-specific concerns and one-size-fits-all save code is usually wrong.

Project Checkpoint

The prototype now has enough scaffolding to carry a real progression system. Time to add one.

📐 Project Checkpoint: Add an ability-unlock system to your 2D action-adventure prototype. Ship three unlockable abilities: dash (acquired in the starting area, gates a narrow passage), double jump (acquired mid-game, gates a vertical shaft), and wall climb (acquired late, gates a rooftop region). Each ability should be a pickup (AbilityUnlock.gd) placed in the world. The Player script must check ProgressionSystem.has_ability() before allowing the gated action. Design at least one gate per ability — a place in the world the player physically cannot cross without the ability. Playtest. Watch a fresh player discover each ability. Does the gate tease correctly? Does the ability feel meaningful when acquired? Does the player go back to previously-inaccessible areas to use it? Iterate based on what you see.

Your progression system is now the backbone of your game's pacing. In later chapters we will add combat power (Chapter 26), balance the numbers against the combat and enemy design (Chapter 32), and address the ethical considerations of progression systems — especially around grinding and monetization — in Chapter 33. For now, you have the plumbing. Build it out.

Common Pitfalls

A short taxonomy of the progression mistakes I see most often from new designers.

Forced grinding. The XP curve demands more XP per level than the intended content can provide at the expected pace. The player must repeat areas to progress. Symptoms: playtesters report the middle of the game as boring, drop-off around hour 10, complaints that enemies give too little XP. Cure: adjust the curve, increase mid-game XP rewards, or add optional side content that provides enough XP to maintain pace without mandatory repetition. The classic 1990s JRPG shipped with this flaw; Final Fantasy games have spent thirty years recalibrating it.

Illusion of choice. The skill tree looks branching but every optimal player takes the same path. Symptoms: community guides all recommend the same build; playtest variety is nonexistent; theorycrafters converge on one spec within a week. Cure: ensure each branch has a genuine strength. Tune until at least two or three builds are competitively viable. Accept that perfect balance is impossible; approximate it.

Balance breakdown post-cap. The game is beautifully tuned for levels 1 through cap, and then collapses at endgame when players min-max and break the intended difficulty. Symptoms: endgame content is either trivial or requires specific exploit builds; the community considers "real" play to begin at max level. Cure: design endgame content around max-level characters from the start. Do not let endgame be "whatever happens after the main story." Endgame is its own game and needs its own tuning pass.

"Tree" with no real branching. The skill tree is actually a single line with minor branch-offs, or every build ends up touching every major node because skill points are too plentiful. Symptoms: the tree looks complex but has no meaningful specialization; every character is similar. Cure: restrict skill points or increase tree size so no single character can realistically take everything. Commitment cannot exist without scarcity.

Ability overload. The character unlocks so many abilities that the player forgets what they have. Symptoms: playtesters complete the game using 30% of their kit; unused abilities are reported as "I guess I forgot about that one." Cure: fewer abilities, more distinct. If the character has fifty abilities, consolidate to twenty. Each ability should have a clear use-case the player will meet regularly. Unused capabilities are worse than absent capabilities — they confuse without contributing.

Progression that outpaces content. The player hits max level in the middle of the main story and has nothing left to earn for the second half. Symptoms: late-game motivation evaporates; players drop off at the exact point the designer wanted them most engaged. Cure: calibrate the XP curve to the content arc, not to an arbitrary level cap. The cap should coincide with the end of primary content (or the start of endgame content), not the middle.

⚠️ Pitfall: The "numbers for numbers' sake" trap. You add a level system because RPGs have level systems. You add a skill tree because open-world games have skill trees. But your game's core promise — the thing you are actually selling the player — may not need numerical progression at all. Celeste does not need XP. Journey does not need a skill tree. Outer Wilds absolutely does not need character levels. If the progression system does not serve the promise of your game, cut it. The best progression system is the one that matches what the player is actually after, not the one conventional wisdom says you should ship.

Summary

Progression is the engineered sensation of getting stronger. It can live in the player's skill, the character's power, or (usually) a ratio between the two. XP curves shape pacing; skill trees shape identity; unlock-based progression shapes the world. Soft caps and hard caps manage the ceiling. Power creep threatens the long-term health of live-service games and demands structural response.

You have, now, the vocabulary to look at any game's progression system and describe its shape — the ratio, the curve, the topology, the cap strategy, the creep policy. Use that vocabulary when you play. When you encounter a progression system that feels great, ask why it feels great in these terms. When one feels bad, ask what specifically is miscalibrated and whether it is the curve, the tree, the gates, or the caps. This is the practitioner's view.

We close with a reminder the chapter has tried to earn. Progression is not about numbers getting bigger. It is about the feeling of change. The player at hour 30 should be meaningfully, recognizably different from the player at hour 1 — and each hour in between should have felt earned. Engineer that. The numbers are a means, not an end.

🚪 Threshold Concept: The player does not come to your game to watch a number go up. They come to feel themselves becoming something they were not yet when they started. Numbers, levels, trees, unlocks — these are the tools you use to engineer that feeling. They are not the feeling itself. Designers who forget this ship progression systems that are mathematically elegant and psychologically hollow. Designers who remember it ship progression systems that are sometimes mathematically crude and psychologically thrilling. Cross this threshold and the rest of the chapter's specifics become tactics in service of a larger strategy: earn the transformation, hour by hour, by delivering real change under the visible markers. Once you see it this way, you stop designing level curves and start designing growth arcs. The numbers are just where the growth arc meets the UI.

The next chapter turns to combat. Combat is where your progression system gets stress-tested — where all those numbers, unlocks, and skill points meet enemies that want to kill the player. Chapter 26 covers attack design, dodge systems, hitboxes, combo structure, and boss fights. Many of the progression decisions made here — how much HP per level, how damage scales, how abilities interact with combat — will be validated or broken by the combat-design decisions in the next chapter. Build them together, or rebuild both when they collide.

Turn the page.