Chapter 32 Exercises

These exercises move from arithmetic through analysis through design to implementation. Do them in order. The math exercise builds the vocabulary, the analysis exercise calibrates your eye, the design exercise puts you in the chair, and the implementation exercise turns the chair into a tool.

Math Exercises — DPS, EHP, and TTK in a Fighting Game

You are tuning a small fighting-game roster. Three characters, each with the following stats:

Character 1: Brawler - Health: 1000 - Defense rating: 0% damage reduction - Light attack: 60 damage, 8-frame startup, 16-frame total animation - Medium attack: 110 damage, 16-frame startup, 32-frame total animation - Heavy attack: 200 damage, 24-frame startup, 60-frame total animation - Special move (Uppercut): 300 damage, 14-frame startup, 50-frame total animation, costs 25% super meter - Frames per second: 60

Character 2: Tank - Health: 1300 - Defense rating: 15% damage reduction - Light attack: 50 damage, 10-frame startup, 20-frame total animation - Medium attack: 90 damage, 18-frame startup, 36-frame total animation - Heavy attack: 180 damage, 28-frame startup, 70-frame total animation - Special move (Ground Pound): 350 damage, 30-frame startup, 80-frame total animation, costs 50% super meter - Frames per second: 60

Character 3: Speedster - Health: 800 - Defense rating: 5% damage reduction - Light attack: 50 damage, 5-frame startup, 12-frame total animation - Medium attack: 80 damage, 10-frame startup, 22-frame total animation - Heavy attack: 140 damage, 18-frame startup, 40-frame total animation - Special move (Dash Slash): 220 damage, 8-frame startup, 30-frame total animation, costs 25% super meter - Frames per second: 60

Question 1. For each character and each attack, compute the theoretical maximum DPS assuming the attack is repeated as often as the total animation allows. Express in damage per second. (Reminder: total animation in seconds = frames / 60.)

Question 2. Compute the effective HP of each character against a flat 100-damage attack from another character. Show your work. Note: damage reduction applies before the hit is subtracted from HP.

Question 3. Compute the time to kill (TTK) for each pairing — Character X using their best non-super attack against Character Y. There are nine TTKs to compute (Brawler vs. Brawler, Brawler vs. Tank, Brawler vs. Speedster, Tank vs. Brawler, etc.). Express in seconds. Build the matrix as a 3×3 grid.

Question 4. Express the damage per super-meter cost for each character's special move. Which character's super is most efficient per meter? Which is least?

Question 5 (analysis). Look at your TTK matrix. Identify the matchup that looks most lopsided. Now propose two specific stat changes — one to the attacker, one to the defender — that would bring that matchup closer to symmetric. Justify each change.

Question 6 (extension). The Speedster has the lowest health and the lowest damage. Argue, with numbers, whether the Speedster is balanced or underpowered. What additional information would you need to confirm your answer? (Hint: think about what these stats do not capture about a fighting-game character.)

Analysis Exercise — One Month of Patch Notes

Pick a competitive multiplayer game you actively follow or are willing to research. Common choices: League of Legends, Dota 2, Overwatch 2, Hearthstone, Valorant, Apex Legends, Marvel Snap, Smash Bros. Ultimate, Rocket League, Counter-Strike 2. Find the patch notes for the most recent four consecutive patches (about one month of changes for most live-service games).

Step 1: Catalog. Build a table of every change in those four patches. Columns: patch number, target (champion, item, system), change type (nerf, buff, rework, bug fix, neutral), magnitude (number change, qualitative description), stated rationale. If the rationale is not stated, write "implicit" and infer.

You should end with somewhere between 50 and 300 rows depending on the game.

Step 2: Categorize. Group the changes by what kind of thing they target. Common categories: power-level adjustments (a unit was too strong/weak), pattern adjustments (a unit's playstyle felt unsatisfying), counterplay adjustments (a unit had no effective response), accessibility adjustments (a unit was too hard or too easy to use well), bug fixes, and meta interventions (a strategy was dominating tournament play).

For each category, count occurrences across the four patches.

Step 3: Diagnose the philosophy. Based on the category counts, what does this team value? Some hypotheses you might test:

  • Do they prefer many small changes or few large ones?
  • Do they target the dominant strategy, or the dominated strategies, more often?
  • Do they nerf more than they buff, or vice versa?
  • Do they explain their reasoning, or do they ship and watch?
  • Do they patch reactively (responding to the most recent meta) or proactively (anticipating future shifts)?

Write a 500–800 word analysis answering: what is this team's balance philosophy, and what does it imply about their goals for the game?

Step 4: Predict. Based on the philosophy you identified, predict three changes you expect to see in the next patch. Be specific — name the unit, the direction (nerf/buff/rework), and the rationale you expect them to give. Then, when the patch drops, score yourself: did your predictions land? If not, what does that tell you about your model of their thinking?

Submission: the table from Step 1, the count summary from Step 2, the philosophy essay from Step 3, the prediction list from Step 4.

Design Exercise — Rebalance Three Weapons

You are the lead designer on a single-player action game with the working title Verdant Blade. Three weapons in the early game are causing playtest problems:

Weapon 1: Iron Sword. - Damage per hit: 12 - Attack speed: 1.0 hits/second - Stamina cost per swing: 8 - Range: short - Acquired: starting weapon

Weapon 2: War Hammer. - Damage per hit: 35 - Attack speed: 0.4 hits/second - Stamina cost per swing: 22 - Range: short - Acquired: chest in Forest Ruins (1 hour into game)

Weapon 3: Hunter's Bow. - Damage per hit: 18 - Attack speed: 0.8 hits/second - Stamina cost per shot: 12 - Range: long - Acquired: tutorial reward (early game)

Player has 100 stamina, regenerating at 15 stamina/second.

Playtest data from Chapter 31: - 11/12 players abandoned the War Hammer within 20 minutes of finding it. Verbatim quote from one tester: "It hits hard but I keep running out of stamina before I kill anything." - 9/12 players used the Iron Sword exclusively for the first 3 hours, even after finding the Bow. Quote: "The bow is fine but I forget I have it." - The single player who did use the War Hammer beat the first boss in 90 seconds — the average time was 4 minutes. - Players reported the Hunter's Bow as "boring" — it works, but they did not feel anything when using it. - The Iron Sword's stamina cost felt invisible — every player reported never running low on stamina with it.

Your task:

  1. Diagnose. For each weapon, write 3-4 sentences identifying what is wrong, based on the playtest data. Be specific about the metric you think is at fault (damage, speed, stamina, range, acquisition timing, feel, or something else). Distinguish between numbers problems and design problems.

  2. Hypothesize. For each weapon, propose two distinct rebalances — one that addresses the immediate complaint by changing a number, and one that addresses the underlying problem by changing the weapon's role in the kit. (Example for the bow: number-fix could be "increase damage to 25 per shot"; role-fix could be "give the bow a charging mechanic that rewards committed shots, with a payoff of true damage that ignores armor.")

  3. Decide. For each weapon, pick which of your two hypotheses you would actually ship, and explain why. Address: what does this change do to the rest of the game? What playtest data would confirm or refute the change?

  4. Build the spreadsheet. Create a small CSV (you can do this on paper, in actual Excel/Google Sheets, or in your head — but show the columns and at least the rows for the three weapons after rebalance). Columns: name, damage, attack speed, stamina cost, DPS, stamina-cost-per-damage, swings-before-empty, time-to-kill against a 100-HP enemy.

  5. Write the patch note. For each weapon, write a 2-3 sentence patch note in the League of Legends style — what changed, why it changed, what you expect, what you will watch.

Implementation Exercise — CSV-to-GDScript Balance Loader

Build a working balance-loader system in your Godot project. The deliverables:

Part A: The CSV.

Create res://balance/unit_stats.csv with a minimum of: - 8 enemy entries (use the units in your progressive project, or invent them) - 4 player-weapon entries - 2 boss entries

Columns must include: id, category (enemy/weapon/boss), hp, damage, attack_speed, move_speed, plus at least three additional category-relevant columns (e.g., armor, xp_reward, gold_drop for enemies; range, stamina_cost, crit_chance for weapons).

Part B: The Loader.

Implement BalanceLoader.gd as an autoload (Project → Project Settings → Autoload). It must: - Load the CSV on _ready. - Parse headers automatically (do not hard-code column names — your CSV should be addable-to without code changes). - Provide a get_stat(unit_id, stat_name) method that returns the value, or null if not found. - Provide a get_all_in_category(category) method that returns all entries of a given category as a dictionary. - Provide a reload() method that re-parses the CSV (for hot-reload).

Use the code in the chapter as a starting point, but extend it with the additional methods above.

Part C: Integration.

Modify at least two existing scripts in your progressive project to read from the loader rather than using hard-coded values. Examples: your Enemy.gd reads hp, damage, and move_speed from the loader; your Weapon.gd reads damage, attack_speed, and range.

The behavior of the game should be unchanged after this refactor — same numbers, just sourced differently. Verify by playing.

Part D: Hot-Reload (optional but recommended).

Implement BalanceHotReload.gd from the chapter. Confirm that you can edit the CSV, save, and see the changes in the running game without restarting.

Part E: A Small UI for Designers.

Create a debug scene (res://debug/balance_inspector.tscn) that displays the current loaded balance as a table — one row per unit, columns for each stat. The scene should be reachable via a debug key (F12 or similar) and should be removable from production builds with a if OS.is_debug_build() guard.

This UI is a designer-facing tool. Make it readable. Use a GridContainer or Tree node. Columns should align. Numbers should not be in scientific notation.

Part F: Document.

Add a README.md to res://balance/ that explains: - What each CSV file contains. - The format (columns, types). - How to add a new entry (step by step). - How to enable hot-reload. - The convention for IDs (e.g., "use snake_case, prefix with category — enemy_slime_green").

This README is what a future designer (or you, six months from now) will read to understand the system. Write it clearly.

Submission: the CSV file, the loader script, the modified game scripts, the inspector scene, the README, and a screenshot of the inspector showing your balance data loaded successfully.

Bonus Math — Cost Curves Across a Roster

You are designing a card game. Cards in your game have a "mana cost" from 1 to 8. You are setting the power level baseline — the average damage a "vanilla" creature should have at each cost.

Historical reference: in early Magic: The Gathering, the rule was roughly "vanilla power+toughness equals 2 × mana cost." A 1-mana creature is a 1/1, a 2-mana is a 2/2, a 3-mana is a 2/3 or 3/2, and so on. This is a linear cost curve, and it became the baseline against which every "exceptional" card was measured.

Question A. Build a power-curve table for your card game. Decide on a curve type — linear, exponential, plateau, S-curve — and justify your choice in 2-3 sentences. What does each curve type imply about your game's late-game?

Question B. Now design five vanilla creatures (no abilities, just stat sticks) at costs 1, 2, 4, 6, and 8. Use your curve to set their stats.

Question C. Design five non-vanilla creatures (with one ability each) at the same costs. For each, decide what to take away from the vanilla baseline to "pay for" the ability. (Example: a 2-mana creature with a vanilla baseline of 2/2 might become a 1/2 with a +1 buff aura — losing 1 attack to gain the aura.) Justify each cost in 1-2 sentences.

Question D. Now compare your designs to a real card game (Magic, Hearthstone, Marvel Snap, Slay the Spire, Legends of Runeterra — pick one). Find a card in that game at a similar cost with a similar ability. Are the stats the same? Different? What does the difference tell you about that game's curve compared to yours?

Question E. Identify which of your five non-vanilla creatures is most likely to be too strong, and which is most likely to be too weak. What playtest data would you collect to confirm?

Extended Math Exercise — Synergy and Variance

This second math exercise builds on the basics with two harder concepts: synergy and variance.

Synergy. Imagine an RPG where the player can equip two of three relics:

  • Relic of the Storm: +30% lightning damage.
  • Relic of the Conduit: Lightning attacks have a 50% chance to chain to a second target for 50% damage.
  • Relic of the Crit: +25% critical-hit chance, +50% critical damage.

Base lightning attack: 80 damage, 100% hit chance.

Question A. Compute the expected damage per attack for each pair of relics: 1. Storm + Conduit 2. Storm + Crit 3. Conduit + Crit

Show your work. Identify the strongest pair and the weakest pair.

Question B. A new player loadout adds a fourth relic, Relic of the Echo: "After dealing critical damage, your next attack within 2 seconds deals double damage." How does adding Echo change the value of Crit (which now triggers Echo)? How would you model this in your spreadsheet — what column would you add?

Variance. A class has two ultimate options:

  • Ultimate A: Deals 500 damage every cast. Always.
  • Ultimate B: Deals 1000 damage with 50% probability, otherwise deals 0.

Both have the same expected value (500). Both have the same cooldown (60 seconds). Which would your player base prefer, and why? Argue both sides for at least three sentences each. Then propose a third option, Ultimate C, that has the same EV (500) but has different variance from both A and B — for example, "deals 250 damage three times in a 1-second window, with each instance independently rolling for hit." Calculate the variance of each (you can use the variance formula for binary outcomes: Var = p(1-p)(diff)²).

The lesson: EV is a starting point, not a complete characterization of an option.

Reflection Prompts (Optional but Encouraged)

These are not graded. They are for your design notebook.

  1. After your balance pass on the progressive project, what surprised you the most? What did you think was the problem that turned out not to be? Where did the spreadsheet's prediction match your gut, and where did it disagree?

  2. Which of your nerfs or buffs felt the hardest to commit to? Why? Was the difficulty about the change itself, or about your relationship with the affected piece of content (a unit you loved, a weapon you spent weeks polishing)?

  3. Find a game you love that has bad balance. Articulate what the imbalance is, and propose three changes that would fix it. Now ask: would you actually want the game to change? Sometimes the imbalance is the charm. Smash Bros. Melee is technically unbalanced — Fox is dramatically stronger than half the cast — and that imbalance is part of what makes the competitive scene what it is. Could the same be true of your example?

  4. Imagine you have shipped your progressive project, and the community has discovered a degenerate strategy that is dominating play. Walk through your response: how do you confirm it is real, how fast do you patch, what do you change first, what do you write in the patch note? Practice writing the actual patch note text now, before you ever need it. The discipline of having pre-written language for "we noticed X and we are doing Y" pays dividends when the situation is real and the pressure is on.

  5. The chapter argues that "perfectly equal" is the opposite of balanced. Find or invent a counter-example — a game where equal-power options are exactly what the design wants. (Hint: think about parties, party games, accessibility-first design, sports with handicap systems.) Why does equal-power work in those contexts and not in competitive video games?

  6. Your progressive-project spreadsheet now exists. In ten years, when someone asks you about it, what is the first column you will be embarrassed by? Imagine the audit. What would have made the spreadsheet more defensible, more readable, more durable? Apply those lessons to the version you have today.

  7. Pick one of the two case studies and stage a debate with yourself. Argue for the design philosophy in the case study; then argue against it. What did you learn from the second argument that you did not see in the first?

  8. The progressive project has been your companion since Chapter 3. Looking back, identify one balance decision you made early that you would now make differently with what you know about cost-benefit, simulation, and per-skill-level analysis. Write 200 words on what changed in your thinking.

Submission Format and Grading Notes

For instructor use:

The math exercises are objective; partial credit for correct method even when the arithmetic slips. The analysis exercise is subjective but verifiable — students should be able to point to specific patch notes that justify their categorization. The design exercise asks students to make and defend a real decision; grade on coherence and on whether the decision actually responds to the playtest data given. The implementation exercise is binary: either the loader works or it does not. Run the student's code; load their CSV; verify that BalanceLoader.get_stat("orc_warrior", "hp") returns the right value.

Total time estimate: 8-12 hours of student work for the full set, depending on whether they choose to do the optional reflections. The math and design exercises are roughly 90 minutes each. The analysis exercise will take 3-5 hours depending on the game chosen. The implementation exercise is the largest — expect 4-6 hours for a student who is comfortable with Godot and twice that for a student still learning the engine.