Chapter 24 — Exercises

These exercises take you from analyzing real games' economies to designing your own from scratch, and from extending the chapter's inventory/shop code to finding an inflation case study in the wild. Budget 10-15 hours across all exercises. Do them in order — later exercises build on earlier ones.

Difficulty markers: 🟢 straightforward, 🟡 moderate, 🔴 challenging.

Exercise 24.1 — Map an Economy You Know 🟢

Pick one game you've put serious time into. Not a game you think you should analyze — a game where you have genuine intuitions about how its economy feels.

On paper or in a drawing tool, produce a Machinations-style diagram for its economy. Include:

  1. Every resource as a labeled circle. Gold, materials, XP, consumables, reputation — anything the game tracks and the player collects or spends.
  2. Every source as an arrow into the appropriate circle, with a short label describing the source (e.g., "enemy drops," "chest loot," "quest reward").
  3. Every sink as an arrow leaving a circle, labeled similarly ("potions," "repairs," "upgrades").
  4. Every converter as a rectangle between two circles (crafting, smelting, sacrificing).
  5. Every trader as a double-headed arrow (for NPC shops, annotate which side is also source or sink).

Once the diagram is complete, answer in 200-300 words:

  • Which resources have the most sources? The most sinks? Are any resources pure source or pure sink (no flow in the other direction)?
  • Do you notice any inflation or deflation pressure? Are endgame sinks present, or is the endgame a wealth trap?
  • If you were the designer, what would you change?

Submit: the diagram (photo or digital), plus your written analysis.

Exercise 24.2 — Analyze Three Games' Economies Side-by-Side 🟡

Pick three games from different genres — for example, one action-RPG (Diablo, Path of Exile, Grim Dawn), one MMO (WoW, FFXIV, Guild Wars 2, EVE), and one single-player RPG (Skyrim, Dragon Age: Origins, Elden Ring). If you haven't played all three, pick games you've played at least 20 hours of each.

Create a comparison table with the following rows:

  • Main currency name(s)
  • Source types (list categories)
  • Sink types (list categories)
  • Converter types (list)
  • Trader types (list: NPC shop, auction house, player market, etc.)
  • Inflation/deflation tendency (your assessment)
  • Endgame wealth state (meaningful scarcity, mild abundance, wealth trap)
  • What the economy feels like to a player (one sentence)

Then write 400-500 words comparing the three. Questions to address:

  • Which economy do you find the most satisfying, and why?
  • What structural differences (source/sink ratios, number of currencies, trader types) drive those differences in feel?
  • Which economy would scale better to 5 million players? To a 20-year live service?

Exercise 24.3 — Sketch an Economy for a Hypothetical Game 🟡

Design the economy for a game concept I'll give you: a cozy farming sim where you run a small coffeeshop in a seaside village, hire NPC assistants, and build up your shop's reputation over a one-year in-game cycle.

You must design:

  1. Resources. Pick 3-5 resources. Justify why each is distinct. (Hint: money, ingredients, reputation, and maybe one more.)
  2. Sources. How does each resource enter the economy?
  3. Sinks. How does each resource leave?
  4. Converters. What transformations exist (e.g., ingredients → finished drinks)?
  5. Traders. Is there an NPC market? Do players trade with each other (if multiplayer)?
  6. Progression curve. How should gold-per-week change from week 1 to week 52?
  7. Endgame sink. What does the player spend on once they've mastered the game?

Sketch the full flow as a Machinations-style diagram. Then write 300-400 words explaining your choices. Pay particular attention to:

  • Why you chose the number of resources you did (more is not always better).
  • Whether your economy tends toward inflation or deflation, and whether that's intentional.
  • What the "feel" of the economy is at week 4, week 20, and week 52.

Exercise 24.4 — Implement Stackable Inventory 🟡

Extend the Inventory.gd script from the chapter to support stack limits. Requirements:

  • Add a max_stack_size(item_id: String) -> int function. Default is 99 for stackable items, 1 for non-stackable.
  • Modify add() so that when an existing stack is full, a new stack is created.
  • Add a function get_stack_counts(item_id: String) -> Array[int] that returns an array of the current stack sizes for that item_id (e.g., [99, 99, 43] if you have 241 arrows across three stacks).
  • Preserve the inventory_changed signal.

You will also need a small ItemDatabase.gd resource (or a constant dictionary in a singleton) that maps item IDs to max stack sizes. Example: {"arrow": 99, "iron_sword": 1, "health_potion": 10, "gold": 999999}.

Write a small test scene that:

  1. Adds 250 arrows, expects 3 stacks (99, 99, 52).
  2. Adds a sword, expects a stack of 1.
  3. Adds another sword, expects 2 stacks of 1 (can't merge non-stackables).
  4. Removes 100 arrows, expects 1 stack of 99 + 1 stack of 51 (or however your removal logic chooses to distribute — document your choice).

Submit: the modified Inventory.gd, the ItemDatabase.gd, and the test scene script with output screenshots.

Exercise 24.5 — Extend the Shop with Reputation 🟡

Extend the ShopNPC.gd from the chapter to support a reputation system. Requirements:

  • Add an exported reputation: int = 0 variable ranging from -100 to +100.
  • At +50 or higher, buy prices drop by 10% and sell prices rise by 10%.
  • At -50 or lower, prices invert: buy up 10%, sell down 10%.
  • Below -80, the shop refuses to trade entirely (return false from both functions).
  • Expose a modify_reputation(delta: int) method that clamps to [-100, 100].

Also add signal reputation_changed(new_value: int) and document when a caller should emit this (e.g., completing a quest for the shop NPC, stealing from them, helping in a fight).

Write a test scenario in comments at the top of the file showing a sequence: start at 0, complete quest (+30), buy potion (verify normal price), complete two more quests (reputation now +90), buy potion (verify discounted price), steal from shop (-100 rep), attempt to buy (verify refused trade).

Exercise 24.6 — Find a Real-World Inflation Case 🟢

Research and document one real-world inflation event in a live game. Options include (pick one):

  • World of Warcraft gold inflation 2004-2024 (there's a lot written about this).
  • Diablo III Real Money Auction House (covered in Case Study 1, but dig deeper).
  • Path of Exile Mirror of Kalandra economics.
  • Final Fantasy XIV's server-by-server gil economies.
  • EVE Online any major economic event (PLEX price crashes, Bloodbath of B-R5RB).
  • RuneScape Wilderness removal and return.
  • Team Fortress 2 key/metal economy.

Write 500-700 words covering:

  1. What happened (the event, dates, scale).
  2. Why it happened (which flows got broken — sources, sinks, converters, traders).
  3. How the developers responded (or failed to).
  4. What the long-term impact was.
  5. What you, as a designer, would have done differently if you'd been on that team.

Cite at least three sources (community forums, dev posts, economic reports, postmortem articles).

Exercise 24.7 — Design Your Project's Economy 🟡

For your progressive project (the 2D action-adventure), produce a complete economy document. Include:

  • Resources list. Likely: shards, consumables (potions, revives), key items, maybe ability materials for Chapter 25. Justify each.
  • Flow diagram. Hand-drawn or digital, Machinations-style.
  • Flow rate estimates. Shards per hour at early/mid/late game. Consumable usage rates.
  • Pricing document. What does every item in the shop cost? Why?
  • Playtest predictions. What do you expect playtesters to do? Hoard? Spend freely? Complain?
  • Post-launch levers. If you see inflation after players play the game, what would you tune?

Length: 1,000-1,500 words plus the diagram.

Exercise 24.8 — Currency Naming Exercise 🟢

Your 2D action-adventure currently has one currency: "shards." Propose three alternative names, each from a different flavor direction:

  1. A mundane naming (what an economic historian would call it — e.g., "coins," "credits").
  2. A thematic naming rooted in your game's world/lore (what the game's NPCs would call it).
  3. An abstract/mechanical naming (what a systems designer would call it — "points," "spark," etc.).

For each name, write 100 words on what the name signals to the player and how it would change the feel of earning and spending. Then pick one and justify.

Exercise 24.9 — The Spreadsheet Simulation 🔴

Build a spreadsheet model of your project's economy. Rows are hours of play (0-40). Columns include:

  • Cumulative shards earned (running total)
  • Cumulative shards spent (running total)
  • Current shard balance
  • Gear tier (based on upgrades purchased)
  • Average enemy defeats per hour
  • Consumables used per hour

Populate it with your best estimates. Graph the shard balance over time. Does it climb monotonically (inflation risk)? Does it plateau? Does it oscillate with spending spikes?

Now tweak a variable: assume the player skips 30% of optional content. How does the curve change? What if they farm an early area for an hour? What if drop rates are 20% lower than expected?

Submit: the spreadsheet file, plus a 300-word writeup of what you learned.

Exercise 24.10 — Ethical Audit of a F2P Economy 🟡

Pick a free-to-play game you've played or can study (Clash of Clans, Genshin Impact, Candy Crush, Raid: Shadow Legends, Pokémon GO, etc.). Audit its economy for ethical concerns. Checklist:

  1. Currency clarity. Can a player easily tell soft from premium? Are they visually distinct? Can you accidentally spend premium when you meant soft?
  2. Conversion friction. Can premium currency be bought in exact amounts matching what you want to buy, or is there "stranded currency" friction?
  3. Time pressure. Are there timers that resolve to purchase prompts? Are they reasonable?
  4. Loss aversion. Are there systems that penalize not-playing (daily streaks, event deadlines, timed loot)?
  5. Gacha/randomness. If there's a lottery mechanic, are rates published? Is there pity protection?
  6. Target audience. Who is the game designed for? Whales? Children? Adults with disposable income?

Write 600-800 words analyzing the game across these axes. Conclude with: would you work on this game? Why or why not?

This is heavier material. We'll return to it in Chapter 33 on Ethics. But treating F2P design seriously means being willing to look at its darker edges.

Exercise 24.11 — Anti-Economy: Games Without Money 🟢

Some games deliberately do not have money. Journey, Abzû, Flower, and Celeste have no currency. Yet they still have economies in the abstract sense — resources flow, scarcity shapes play.

Pick one of these games or another money-free game you know. Write 400-500 words identifying:

  • What resources exist (health, time, momentum, attention, emotional state).
  • What sources, sinks, converters, and traders exist in the abstract.
  • Why the designers chose not to have explicit currency.
  • Whether the game would be improved or damaged by adding currency.

This exercise sharpens the point that every game has an economy. Recognizing implicit economies helps you design explicit ones.

Exercise 24.12 — Implement a Buyback System 🟡

Many games let the player buy back items they accidentally sold to an NPC within a short window. This is a quality-of-life feature and economically interesting because the sell-then-buyback price spread can create an exploit.

Extend ShopNPC.gd with:

  • A buyback queue that stores the last 12 items the player sold to this shop.
  • A buyback(item_id: String) method that lets the player repurchase at the same price the shop paid for it.
  • A clear on world/scene change (simulate with a clear_buyback() public method).

Question to answer in a comment: what prevents the player from exploiting sell-then-buyback as a way to temporarily convert currency to items for free and back? Is the design deliberately permissive, or did you add friction?

Think through this carefully. Real games have shipped buyback exploits; patches later addressed them. The interesting case study is Skyrim, which had a notorious exploit involving fence buybacks. Research it briefly if unfamiliar.

Exercise 24.13 — Case Study Writeup: Hollow Knight's Geo 🟢

Play the first three hours of Hollow Knight if you haven't. Pay close attention to how geo works. Then write 500-700 words analyzing:

  • What are the early-game sinks for geo? Are they compelling?
  • How does the death penalty (losing geo to your Shade) shape decision-making?
  • What happens when you have "too much" geo? Are there endgame sinks?
  • How does geo compare structurally to Dark Souls souls?
  • What design lesson does Hollow Knight's economy offer indie devs?

Exercise 24.14 — Design Review of Another Student's Economy 🟡

If you're taking this course with others: exchange your Exercise 24.7 economy documents. Review a classmate's document using the following framework:

  1. Is the number of resources justified? Could any be collapsed?
  2. Are the sources and sinks balanced, or is there visible inflation/deflation pressure?
  3. Does the progression curve match the expected player experience?
  4. Are the prices legible? Would a new player understand what to save for?
  5. What is the endgame wealth state? Is it a trap?

Write a 400-500 word review. Be specific and constructive. Your classmate will return the favor.

If you're working solo, do this exercise with a published small-scope game instead (say, Stardew Valley or Terraria's early game economy).

Exercise 24.15 — Write a Postmortem for Your Economy 🔴

This is the capstone exercise for the chapter. Using everything above, write a short postmortem for your project's economy. Structure:

  1. What you set out to design. The feel you wanted, the progression curve, the endgame.
  2. What you implemented. The actual mechanics, the actual curves.
  3. What happened in playtesting. (Project ahead if you haven't playtested yet.) What did real players do that you didn't expect?
  4. What you'd change. Three specific things you'd do differently if you restarted.
  5. What you'd keep. Three specific things you nailed.

Length: 800-1,000 words. This is the document you'll revisit in Chapter 31 (Playtesting) and Chapter 40 (Post-Mortem/Capstone). Start it now; refine it all semester.

A Note on These Exercises

Economy design is one of the highest-leverage skills in game design because economies underpin progression, monetization, and player retention. Badly designed economies bleed players at every stage; well-designed ones feel invisible and keep players engaged for years.

The exercises above are deliberately a mix of analysis, design, and implementation. The analysis exercises build your sensitivity to what's happening in games you play. The design exercises make you commit to specific choices. The implementation exercises prove that the theory is runnable. The reflective exercises (like 24.15) help you internalize the practice.

If you're pressed for time, the minimum viable set is: 24.1 (map an economy you know), 24.3 (design a hypothetical), 24.4 (implement stackable inventory), 24.7 (design your project's economy). Everything else strengthens the core.

Exercise 24.16 — The Inflation Simulator 🔴

Build a small simulation in your preferred tool (spreadsheet, Python, GDScript, etc.) that models a simple economy over 1,000 "ticks" of simulated time. Requirements:

  • A single currency (call it "coin").
  • One source: each tick, a random number between 5 and 15 coins enters the economy.
  • One sink: each tick, a random number between 0 and 12 coins leaves the economy.
  • Track the total money supply over time.
  • Track the "price of a sword" — an item whose price rises or falls with the money supply (simulate using a formula like price = base_price * (supply / starting_supply)^0.5).

Run the simulation. Is money supply stable, inflating, or deflating? Now try three variants:

  1. Increase source by 50% (to 7.5-22.5 per tick). What happens to prices?
  2. Add a periodic "event" — every 100 ticks, inject 500 coins as a "holiday bonus." What happens?
  3. Add a second sink that activates only above a certain money supply threshold. Does this stabilize the economy?

Write 300-400 words interpreting the results. This exercise builds intuition for how small changes in flow rates cascade over time.

Exercise 24.17 — The No-Gold Economy 🟡

Design an economy for a 2D adventure game that explicitly has no currency — no gold, no coins, no credits, no numbers-that-represent-money. Yet the game must still have economic activity: players must gain and spend something meaningful, and their choices must matter.

Options for alternatives: materials that craft into equipment, favors owed to NPCs, reputation in factions, time of day, or something stranger. You're not required to reinvent the wheel; Pathologic uses stolen/bartered items; Pyre uses Truths as reputation; Hollow Knight's geo is close to currency but feels different because of its mortality.

Write 600-800 words outlining:

  • Your alternative resource(s).
  • The sources, sinks, and any converters or traders.
  • What decision points exist for the player.
  • Why this is better for your specific game than a traditional currency.

This exercise stretches your thinking. Most designers default to "add gold" when they need economic friction. Sometimes the better design is to ask what friction you actually need.

Exercise 24.18 — Playtest the Vera Shop 🟡

Once you have implemented the Vera shop NPC in your progressive project (per Chapter 24's Project Checkpoint), find at least two playtesters who haven't seen the design. Watch them encounter Vera for the first time. Take notes on:

  • How do they initially discover Vera?
  • Do they understand the shop interface on first contact?
  • What do they buy first? Why?
  • What do they sell? Do they understand the sell-price-is-lower-than-buy-price spread?
  • Do they feel the currency is scarce, abundant, or neutral?
  • Do they ever run out? Do they ever feel rich?

Do not coach. Do not correct them. Just observe. After each session, ask: "What was that like?" and listen.

Write 500-700 words summarizing what you learned and what you would change about Vera's design. This is a preview of the playtesting discipline we'll develop in Chapter 31.

Exercise 24.19 — Compare Economies Across Sequels 🟡

Pick a game series where at least three entries exist (Final Fantasy, Diablo, Dark Souls/Elden Ring, Dragon Age, Mass Effect, Fire Emblem, Monster Hunter, Pokémon). Analyze how the economy evolved across three entries in the series.

For each entry, note:

  • Number and type of currencies.
  • Source types (what changed? added grinding? added quest rewards? added daily bonuses?).
  • Sink types (what changed? added cosmetics? added housing? added upgrades?).
  • Trader types (did trading get more or less sophisticated?).
  • Overall feel (was it tighter or more generous than the previous entry?).

Write 700-900 words analyzing why the designers made the changes they made. Use the shipped games as your evidence; supplement with dev interviews, patch notes, and community postmortems where available. What does the arc tell you about the designers' evolving philosophy?

Exercise 24.20 — Teach Economy Design 🟢

Prepare a 15-minute presentation on game economy design suitable for a non-specialist audience (friends, family, a classmate who hasn't taken this course). You must cover:

  • The four economic functions.
  • Inflation vs. deflation as failure modes.
  • At least one concrete game example.
  • Why any of this matters to a player (not just a designer).

Deliver it. Then answer questions. Note which concepts were hard to communicate, which examples landed, and which ideas your audience pushed back on.

Teaching is the fastest way to expose gaps in your own understanding. If you can't explain sources and sinks to your mom, you haven't internalized them yet.

Exercise 24.21 — Endgame Wealth Sink Pitch 🟡

Imagine you've been hired as an economy consultant on a popular single-player RPG that just hit 200 hours of average playtime per player. Playtesting reveals the "Skyrim problem" — by hour 60, players have more gold than they can spend. Your job is to propose three endgame sinks that could absorb the accumulated wealth without breaking existing progression.

Each proposal must include:

  • Name and concept (1 paragraph).
  • Target price range (what it costs, in the game's currency).
  • What the player gets in return (cosmetic? functional? social? narrative?).
  • Why it won't feel like a grind or a cash grab.
  • Estimated development cost (rough: small, medium, large).

Write 600-800 words total. Prioritize your proposals and recommend which to implement first. This exercise mimics the kind of pitch a working game-economy consultant actually produces.

Exercise 24.22 — Compare Single-Player Economies 🟢

Write a 400-500 word comparison of the economies in Breath of the Wild and Elden Ring. Both are open-world action games with massive scope, but their economic design differs substantially. Cover:

  • Main currency and its feel.
  • Source types and how the game introduces each.
  • Sink types, particularly at mid-game and endgame.
  • Whether each game has an "endgame wealth problem" and how it avoids (or doesn't avoid) the Skyrim trap.
  • Which economy you prefer, with reasons.

BotW's rupees vs. Elden Ring's runes is a subtle but rich comparison. Runes are dual-purpose (leveling + buying) like Dark Souls; rupees are purely transactional. This structural difference creates very different play experiences.

Exercise 24.23 — Ship It 🟡

Stop reading. Implement the Inventory.gd and a minimal ShopNPC.gd in your project. Get them working in-game. Hook the shop to your hub NPC. Add three items to the shop. Playtest for 15 minutes yourself.

Submit: a 30-60 second video of you or a friend walking up to the shop NPC, buying an item, selling an item, and seeing the currency counter change. No analysis, no writeup, just proof that the code from this chapter runs in a game.

Sometimes the exercise is to shut the book and build the thing. The whole chapter is theoretical until you have a running prototype. Run it.