Chapter 25 — Exercises

These exercises take you from analysis through design, math, and implementation. Budget 10-14 hours across all of them. Several are paired (e.g., Exercise 25.5 depends on the design work in 25.3); do them in order where noted.

Difficulty markers: 🟢 foundation, 🟡 intermediate, 🔴 advanced.

Analysis

Exercise 25.1 — Three-Game Progression Teardown 🟢

Pick three games with conspicuously different progression philosophies. Good starter triads:

  • Celeste, Dark Souls, Diablo III.
  • Hollow Knight, Path of Exile, Horizon Zero Dawn.
  • Breath of the Wild, Persona 5, Destiny 2.

For each game, answer the following in 200-350 words.

  1. What is the skill-vs-power ratio? Where on the scale from "pure player skill" to "pure character power" does this game sit?
  2. What are the progression axes? List each (XP level, gear, skills, abilities, reputation, etc.) and mark them vertical, horizontal, or mixed.
  3. What shape is the XP curve (if there is one)? Linear, exponential, polynomial, logarithmic? Estimate the total playtime-to-cap.
  4. What does the endgame look like? How does the game handle progression after the main story ends?
  5. What is one thing this game's progression system does better than most of its genre peers? What is one thing it does worse?

Then write a fourth comparative section (300-400 words): which of the three games' progression approaches most closely matches the game you are prototyping? Which do you most want to emulate? Which would be a disaster to apply to your design?

Submit: a document of approximately 1,000-1,500 words.

Why this exercise matters. Most designers have strong intuitions about progression but lack vocabulary to articulate what they are seeing. This exercise gives you the vocabulary. Once you can say "this game has a 60/40 skill-to-power ratio with horizontal-dominant gear and a polynomial XP curve that soft-caps around hour forty," you can describe your own game's target in the same terms — and defend it to teammates who are pulling in different directions.

Exercise 25.2 — The Grinding Valley Hunt 🟡

Pick one RPG you have played to completion with XP-based leveling. Try to identify the grinding valley — the range of levels where forward progression felt slowest, where you most often repeated content, where motivation dropped.

Answer in a single-page writeup:

  • What was the level range? (Rough: "levels 25-35 in the Deep Roads section.")
  • What caused the valley? Was the XP curve too steep, the encounter density too low, the reward-per-encounter too small, or some combination?
  • What did you do to cope? Grind? Side content? Skip ahead and under-level? Put the game down for a while?
  • If you were the designer reworking the game, what one change would you make to address it?

Now pick a second RPG — this one ideally very different in design (e.g., if the first was Dragon Age: Origins, pick Persona 5 or Mass Effect) — and repeat. Compare the two grinding valleys.

Submit: the writeup and the comparison (aim for 600-900 words total).

Why this exercise matters. Every RPG has a grinding valley unless the designers found and fixed it before ship. Learning to see the valley — to recognize it while playing, not just to feel vaguely bored — is one of the distinguishing skills of a progression designer. Practice it on other games so you can catch it in your own.

Exercise 25.3 — Power Creep Autopsy 🟡

Pick a live-service game you have followed across multiple content releases (WoW, Destiny 2, Hearthstone, Path of Exile, Final Fantasy XIV, Diablo III/IV, Overwatch, or similar).

Document the power-creep trajectory. Across three or more content patches or expansions, record:

  1. What was the level cap before? What is it now?
  2. What was the gear tier ceiling before? What is it now?
  3. Roughly, how much more powerful is a fully-geared character today than a fully-geared character one patch ago? One year ago? Three years ago?
  4. Has the game implemented any structural response (squish, rotation, seasons, prestige)? When? Why?
  5. What did players say about the response? Celebrated it, resented it, or ignored it?

Write 500-700 words analyzing what you found. Conclude with a prediction: where is this game's power creep heading over the next two years? What should the team do about it?

Submit: the analysis document with a short timeline chart at the top.

Why this exercise matters. Power creep is the slow-motion disease of every live-service game. Studying it in one title teaches you to recognize the signs in others — and in your own, if you ship live service. This exercise is partly documentation, partly prophecy. Both skills matter.

Design

Exercise 25.4 — Sketch a Skill Tree for a Stealth Game 🟡

You are designing the skill tree for a 20-hour stealth-action game. The player plays an infiltrator in a near-future espionage setting. The core moment-to-moment mechanics are: moving unseen, neutralizing enemies silently, hacking systems, combat as a last resort.

Sketch a skill tree with 24-32 nodes organized into at least three branches. Your sketch must meet the following constraints.

  • At least three named branches reflecting different playstyles (e.g., Shadow / Technician / Warrior, or Ghost / Hacker / Brawler).
  • Each branch has a clear identity: the Shadow branch is about staying unseen; the Technician branch is about gadgets and hacking; the Warrior branch is about winning the fight if stealth fails.
  • Cross-branch synergies: at least two nodes that benefit from investment in multiple branches (a "shadow striker" node that needs both stealth and combat prerequisites).
  • At least one node that unlocks a new ability wholesale (e.g., a grappling hook, a silenced takedown, a network override), not just a statistical bonus.
  • No single dominant path: an optimally-skilled player should have at least three viable build archetypes.
  • Assume the player will earn approximately 20 skill points across the game. Your total tree cost should be roughly 50 points — forcing the player to leave most of the tree unexplored.

Format: a sketch (hand-drawn or in any tool — a spreadsheet, Figma, a whiteboard photo) plus a written node-list. For each node, write: name, branch, cost, prerequisites, and one-sentence effect.

Submit: the sketch image plus the node list (expect 500-800 words of structured description).

Why this exercise matters. Designing a tree on paper reveals problems instantly that a coded implementation would hide for weeks. Does your tree actually branch, or does one branch dominate? Do the costs force meaningful choices, or can a single player touch everything? Is any node a dead end or a trap? A good paper pass catches all of these before you write a line of code.

Exercise 25.5 — Ability-Gated Level Design 🟡

Take one area of your prototype level (or design one from scratch if your prototype does not have enough built out yet) and retrofit it with ability gates. You have three abilities to use as gates: dash (clears narrow gaps), double jump (reaches higher platforms), and wall climb (scales vertical surfaces).

For the chosen area, design:

  1. At least one gate per ability (three gates total).
  2. One "tease" for each — a clearly visible area behind the gate that the player cannot reach before acquiring the ability, but can see.
  3. A return path: once the player gets the ability somewhere else in the game, they come back to this area and can now access the gated content.
  4. Reward the return. Put something worth coming back for behind each gate — a secret, a charm, a lore item, a shortcut, a better-positioned save point.

Sketch the area (top-down or side-view, depending on your prototype's style). Mark each gate and its corresponding ability. Mark each reward. Mark the return path.

Submit: the annotated sketch plus a one-paragraph explanation of the design intent for each gate.

Why this exercise matters. Unlock-based progression only works if the level designer and the progression designer coordinate. This exercise forces that coordination in your own prototype. You will discover, often to your surprise, how hard it is to design meaningful gates that tease without frustrating and reward without trivializing. Metroidvania level design is a craft in itself; here you get a taste.

Exercise 25.6 — Trap Build Red-Team 🔴

Take the skill tree you designed in Exercise 25.4. Now play the role of a hostile player — one who is determined to build an under-powered character without realizing it.

Identify at least three trap build paths. A trap build is a sequence of node allocations that looks reasonable to a novice but results in a character that cannot handle the intended difficulty of the game. For each trap, answer:

  • What node sequence defines the trap?
  • What makes it look appealing (which nodes seem good, which stats seem important)?
  • What goes wrong at endgame?
  • How would a skilled player avoid it? What signals could the UI provide to steer players away?

Then propose a fix for each trap. Your options are: rebalance the nodes (make them stronger), add explicit warnings in-game, add automatic respec prompts when a player's build is flagged as dysfunctional, or accept the trap as intentional challenge.

Submit: a document describing the three traps and your proposed fixes (500-900 words).

Why this exercise matters. Every real skill tree has trap builds. Good designers identify and either fix or accept them deliberately. Bad designers ship them accidentally, and then the community forums fill with "why does my build suck" threads. Proactive red-teaming is how you catch traps before release.

Exercise 25.7 — Horizontal Endgame 🔴

Imagine your prototype has shipped and is successful. The team must now plan a content update that continues the progression without simply raising a cap or releasing a higher-tier item set. In other words: horizontal progression only.

Write a one-page design proposal (400-700 words) for a "first horizontal expansion" that:

  1. Does not raise the level cap.
  2. Does not introduce gear numerically stronger than existing gear.
  3. Adds at least three new mechanical options (abilities, playstyles, build archetypes) that slot into the existing progression.
  4. Adds at least one new system dimension that previous content did not use (e.g., a crafting layer, a faction system, a seasonal modifier, a new currency that unlocks lateral content).
  5. Convinces the skeptical publisher that this content is worth buying despite offering "no bigger numbers."

Submit: the proposal document.

Why this exercise matters. Horizontal expansions are harder to sell than vertical ones. Players and publishers both tend to respond to "+10 levels, new gear tier" more than to "three new playstyles." The designers who can design — and pitch — horizontal content are the ones whose games have long, healthy tails. This is a craft as much as a design.

Math

Exercise 25.8 — XP Curve Calculations 🟡

Compute the total XP required to reach level 50 under each of the following curves. Show your work or a spreadsheet/python snippet.

a) Linear. xp_for_next_level = 100 * level. Total XP from level 1 to level 50.

b) Exponential. xp_for_next_level = 100 * 1.15^(level-1). Total XP from level 1 to level 50.

c) Polynomial (quadratic). xp_for_next_level = 50 * level^2. Total XP from level 1 to level 50.

d) Polynomial (1.7 exponent). xp_for_next_level = 100 * level^1.7. Total XP from level 1 to level 50.

Now assume the player earns 500 XP per hour on average throughout the game. Compute the approximate hours to reach level 50 under each curve.

Under which curve does leveling feel fastest overall? Which feels slowest at the very end? Which is most "even" — each level takes about the same time?

Finally: if your design goal is "the player reaches level 50 after exactly 40 hours of play, with the final 10 levels taking roughly half the time," which curve best fits this shape and what parameters would you tune?

Submit: the computed totals, the hours estimates, and the design-recommendation paragraph (300-500 words).

Why this exercise matters. Intuitions about XP curves are unreliable. The difference between a curve that produces a 30-hour campaign and one that produces an 80-hour campaign is small in the parameters but huge in the lived experience. Doing the math on paper (or in a spreadsheet) before shipping is how you catch curves that will feel wrong, before thousands of playtesters have to suffer through them.

Exercise 25.9 — Diminishing Returns Function Design 🔴

Design a diminishing-returns function for a defense stat. Constraints:

  • At 0 points invested, defense reduces incoming damage by 0%.
  • At 50 points, defense reduces damage by approximately 30%.
  • At 100 points, defense reduces damage by approximately 50%.
  • At 500 points (the maximum any player could reach with all gear stacked), defense reduces damage by approximately 75%. The hard cap on damage reduction is 80% — no player can exceed it.
  • The curve must be monotonically increasing but steeply diminishing — each additional point past 100 should yield notably less benefit than points earned earlier.

Propose a mathematical function that meets these constraints. Plot it (by hand or via any tool) across the range 0 to 500 points.

Then answer:

  • What is the "soft cap" point of this curve — the inflection where further investment starts yielding meaningfully less?
  • At what point does each additional defense point yield less than 0.1% damage reduction? (This is the effective "not worth investing" threshold.)
  • How does this curve interact with a min-max player? Does it encourage diversification of stat investment, or does it still allow a single-stat specialist to thrive?

Submit: the function formula, the plot, and the analysis (300-500 words).

Why this exercise matters. Diminishing-returns functions are everywhere in RPG design and almost always sketched in a weekend and then shipped. Designing one deliberately — with explicit targets and a checked plot — is the difference between numbers that feel right and numbers that produce broken builds. Math is design.

Exercise 25.10 — Skill Point Economy 🟡

Imagine a game where the player earns skill points through multiple sources:

  • 1 point per level (up to level 50).
  • 1 point per major story beat (assume 15 beats across the game).
  • 1 point per rare collectible (assume 20 exist but the average player finds 12).
  • 1 point for completing each of 10 optional side quests.

Compute the total skill points the average player will have at various milestones: end of tutorial (assume level 5, 2 story beats, 2 collectibles, 0 side quests); mid-game (level 25, 8 beats, 6 collectibles, 5 side quests); endgame (level 50, 15 beats, 12 collectibles, 10 side quests).

Now assume your skill tree has 40 nodes total, each costing 1-3 points, with total cost across the whole tree of 80 points. What percentage of the tree can the average player complete? The completionist? The speedrunner who skips all collectibles and side quests?

Does this shape feel right for a 30-hour RPG? If not, what would you adjust — point acquisition rates, tree costs, or the tree size?

Submit: the calculated totals plus a 200-300 word analysis.

Why this exercise matters. The shape of your progression economy — how many points players have at each stage, how expensive the tree is relative to availability — determines whether the tree feels branching (players must choose) or comprehensive (players touch most of it). Most teams do this math late and learn they built the wrong shape. Do it early.

Implementation

Exercise 25.11 — Implement ProgressionSystem.gd 🟢

Implement the ProgressionSystem.gd script from the chapter in your Godot project. Match the pattern, not necessarily the exact code — you may refactor for clarity or add features.

Requirements:

  • An Autoload singleton accessible from anywhere in your project.
  • XP gain that correctly handles multi-level jumps.
  • A configurable XP curve (polynomial by default; make the curve function swappable).
  • Signals for xp_gained, leveled_up, and ability_unlocked.
  • A has_ability(id) query function other systems can use to gate gameplay.
  • Basic save/load to user:// (serialize xp, level, skill points, and unlocked abilities to a file).

Test it by writing a small test harness: a scene with a button that calls gain_xp(100) and a label that displays current level and skill points. Click the button enough times to level up several times; verify the level-up signal fires and the label updates.

Submit: the GDScript file, the test scene, and a screen recording of the test.

Exercise 25.12 — Extend with Multiplier Sources 🟡

Extend your ProgressionSystem.gd from Exercise 25.11 to support XP multipliers. Players can receive temporary XP boosts (e.g., a "Rested" bonus that doubles XP for a time, or a consumable scroll that triples XP for the next hour).

Requirements:

  • A set_xp_multiplier(factor: float, duration: float) method that applies a multiplier for a duration.
  • Multiple active multipliers stack multiplicatively (so a 1.5x rest bonus + 2.0x scroll = 3.0x combined).
  • The multiplier applies to all gain_xp calls during its window.
  • Expired multipliers cleanly remove themselves.
  • A signal xp_multiplier_changed(current_multiplier) fires when multipliers start or expire, so the HUD can display the current boost.

Submit: the extended script plus a test scene that activates multiple multipliers and verifies stacking behavior.

Exercise 25.13 — Implement SkillTree.gd with UI 🔴

Implement the SkillTree.gd resource from the chapter and build a minimal UI for it. The UI should:

  • Display the tree as a graph (nodes as buttons, edges as lines connecting prerequisites).
  • Show each node's display name, cost, and allocation state (empty / allocatable / allocated).
  • Clicking an allocatable node spends the points and marks it allocated.
  • Clicking an un-allocatable node (insufficient points, missing prereqs) shows a message explaining why.
  • A respec button that un-allocates all nodes and refunds their points.

Populate the tree with at least 12 nodes across 3 branches.

Submit: the skill-tree resource, the UI scene and scripts, and a screen recording of allocation, respec, and prerequisite-error cases.

Why this exercise matters. Building a skill tree UI reveals the UX problems that a paper design conceals. Does the UI scale when the tree grows to 40 nodes? Does the player understand why a node is locked? Does respec feel forgiving or punishing? These questions cannot be answered on paper.

Exercise 25.14 — Build an Ability Pickup 🟢

Implement AbilityUnlock.gd as described in the chapter and drop one into your prototype world. Configure it to grant the "dash" ability. Modify your Player controller so that dash is gated behind ProgressionSystem.has_ability("dash").

Playtest the experience yourself. Start a fresh game, try to dash (confirm it doesn't work), find the pickup, take it, try to dash (confirm it now works). Adjust the feedback (visual/audio/message) until the pickup moment feels satisfying.

Submit: the script, a screen recording of the pickup experience, and a one-paragraph reflection on what the pickup feedback taught you about unlock design.

Exercise 25.15 — Power Creep Simulation 🔴

Write a small Python (or GDScript, or spreadsheet) simulation that models power creep over five hypothetical expansions.

Starting point: a character at level 60 with gear that averages +10 stats per slot, six slots total (+60 total stats). Baseline damage output is 1000 per second.

Each expansion does the following:

  • Raises the level cap by 10.
  • Raises max gear stats by 20% per slot.
  • Introduces one new gear tier.

Simulate the stats, gear, and damage output of a fully-geared character at each expansion. Plot the damage-output curve.

Then simulate a "squish" event after expansion 3: all stats divided by 5, but the relative power differences are preserved. Plot the damage output before and after the squish.

Finally, answer: at what expansion does the damage output exceed 100x the baseline? How does the squish affect the player experience — does it preserve progression feel, or break it?

Submit: the simulation code, the plots, and a 300-500 word analysis of what you observed.

Why this exercise matters. Power creep is easy to see in abstract. Seeing it in your own simulated game — watching damage numbers spiral into the millions across a few expansions — makes the problem concrete. The squish is what the designer does when they realize the problem has gotten away from them. Simulating both is cheap prevention against shipping a game with an inevitable squish in its future.

Exercise 25.16 — Reflection 🟢

Write a 400-600 word reflection answering:

  • Before this chapter, what was your default instinct for designing progression? Did you reach for XP-and-levels, ability unlocks, or something else?
  • After this chapter, how has your thinking changed? Which concept (XP curves, horizontal vs. vertical, trap builds, power creep, unlock-based model) stuck with you most? Why?
  • For your own prototype, describe in two to three sentences your intended progression system. What ratio of skill to power? What curve? What unlocks? What caps?
  • What is one specific thing you now plan to add to your prototype that you would not have added before reading this chapter?
  • What question about progression design do you still have that this chapter did not answer?

Submit: the reflection (no length padding — four to six tight paragraphs).

Closing Notes on the Exercises

You do not have to do all sixteen. The minimum viable set is: 25.1 (analysis), 25.4 (design), 25.8 (math), 25.11 plus 25.14 (implementation). Those four give you the vocabulary, the design experience, the numerical literacy, and the working code. The others deepen any of those dimensions.

If you are working through this book at one-chapter-per-week pacing, spread the exercises across the week. Start with analysis (25.1, 25.2, 25.3) early. Move to design (25.4, 25.5) mid-week. Implementation (25.11-25.14) benefits from the weekend when you can focus for a longer block. Reflection (25.16) closes the loop.

One practitioner note. The single most common mistake new progression designers make is designing the system in isolation from the content. The XP curve is not a number in a spreadsheet; it is the pacing of a real playthrough, meeting real encounter density, awarding real XP from real enemies. If you design the curve without simulating the content, you will ship a broken curve. Do your math alongside your level design, not before or after it. This is the discipline exercise 25.8 is pointing you toward.

Submit what you can. Then move to the quiz, the case studies, the key takeaways, and the further reading. Next stop: combat design, where your progression system meets the enemies that will test it.