Iterative Refinement: Playtesting to Polished Demo

Hello! Welcome to the final lesson of our course.

In our previous session, you learned how to conduct thorough playtests—from your own developer playthroughs to blind tests with others—and how to gather and prioritize the feedback into a clear action plan. You now have a list of bugs, usability issues, and, most importantly for today, feedback on the game's pacing, difficulty, and overall feel.

This lesson addresses the capstone module's final learning outcome: Refine game parameters based on playtesting feedback to polish the final demo. This is where we transition from building and fixing to tuning and polishing. We'll take the raw feedback from your playtests and translate it into concrete numerical adjustments within your game's data files. Think of this as the final calibration pass that turns a functional machine into a truly well-engineered product.

By the end of this lesson, you will have a clear methodology for balancing your JRPG's systems, ensuring the difficulty is challenging but fair, the progression is satisfying, and the overall experience is as fun and engaging as the classic games that inspired you.

What is Game Balance?

Before we start turning knobs, it's crucial to understand our goal. "Balance" can be a misleading term. It doesn't mean making every character, skill, and enemy perfectly equal. In fact, perfect equality often leads to boring gameplay where choices don't matter.

Instead, our goal is to avoid "broken gameplay" and foster interesting strategic decisions for the player.

As the article explains, a well-balanced game is one where:

• No single strategy is so powerful that it becomes the only correct choice (like the "All Too Easy" card example).
• Choices are not so equal that they become meaningless (like the identical math problem answers).
• Instead, there are multiple viable strategies, each with its own strengths and weaknesses, allowing players to make meaningful decisions that shape their experience.

Your playtesting feedback likely pointed to areas where this balance is off. For example:

• "The boss was impossible." -> A player felt their strategic options were ineffective.
• "I just spammed the 'Attack' command and won every fight." -> A single strategy was dominant, making other choices irrelevant.
• "Grinding for levels was a total slog." -> The pacing and difficulty curve made progression feel unrewarding.

Our job now is to adjust the game's underlying numerical parameters to address these issues.

The Systemic Approach: Balancing with Formulas

Given your background in Radiophysics and software development, you'll appreciate that modern RPG design doesn't rely on tweaking every single enemy's stats by hand. That would be an impossible task. Instead, designers use mathematical formulas to govern progression for both the player and the game's challenges.

As you've just read, we can model most progression systems using three primary growth curves:

1. Linear Growth (Y = aX + b): Provides a constant, predictable increase. This feels steady and reliable. It’s a good choice for player HP in some games, where you want a consistent increase in survivability with each level.
2. Quadratic/Exponential Growth (Y = aX² + ...): Starts slow but accelerates rapidly. This creates a powerful feeling of growth in the late game. It's often used for the player's damage output to create a "zero to hero" power fantasy, or conversely, for the XP required to level up, making later levels a greater achievement.
3. Logarithmic Growth (Y = ... + b(log X)): Provides large gains initially that taper off over time, approaching a soft cap. This is ideal for stats that would break the game if they grew unchecked, like damage resistance (DEF) or evasion percentage. It creates diminishing returns, so stacking a single stat becomes less effective over time.

Your game's database (the JSON files) is the implementation of these curves. The stat-growth tables for your character classes and the stats you've assigned to enemies in different regions are points along these curves. When playtest feedback says "the game gets too easy after level 5," it might mean your player's ATK curve is quadratic while the enemy HP curve is linear, and the player's power is growing too quickly. Your fix could be to adjust the coefficients in the player's ATK formula or change the enemy HP formula to be more aggressive.

A Toolkit for Practical Refinement

Knowing the theory is one thing; applying it is another. Let's dive into some practical, iterative techniques for adjusting your game's parameters based on your playtest data.

Here's how we can turn those concepts into a repeatable workflow:

1. Establish Your Power Curve

The "Power Curve" is your baseline, your rule of thumb for value. Before you can say a skill is "too expensive," you need to define what a "fair" price is.

• Define a Unit of Value: Pick a core action and use it as a yardstick. For example:
  • "A standard Attack by a Level 1 character should defeat a basic Level 1 enemy in 3 hits."
  • "1 MP is worth approximately 10 points of damage."
  • "A Potion should heal roughly 30% of the main character's max HP at the level it becomes available."
• Use it for Initial Estimates: With these baselines, you can price everything else. If 1 MP = 10 damage, a spell that deals 50 damage should cost around 5 MP. A spell that hits all enemies for 30 damage each is dealing ~120 damage to a 4-enemy group, so it should cost much more, perhaps 10-12 MP. This gives you a solid starting point.

2. Price Complex Effects with "Dark Magic"

How do you price something that doesn't deal direct damage, like a "Sleep" spell? The article calls the process "Dark Magic," but it's really a form of bracketing.

1. Find the "Obviously Too High" Price: What cost would make you never use the spell? A Sleep spell that costs more than your strongest damage spell is probably too expensive.
2. Find the "Obviously Too Low" Price: What cost would make you spam it constantly? A Sleep spell that costs 1 MP is a bargain if it can incapacitate a strong enemy for several turns.
3. Narrow the Gap: Is it still too high at 15 MP? Is it still too low at 5 MP? Keep asking these questions until you find a range where you're not sure.
4. Pick a Value and Test: Choose a value in the middle of that uncertain range.

3. Iterate Efficiently with "Triple Tapping"

This is perhaps the most important technique for acting on playtest feedback. Your intuition will be to make small, gentle changes. Fight this intuition.

Let's say playtesters find your Golem boss is too easy. Its current HP is 500. You think maybe 600 HP would be better.

• The Inefficient Way: You change its HP to 600. In the next test, it's still too easy. You now only know the correct value is > 600.
• The Triple Tapping Way: You think 600 might be right, so you intentionally overshoot and set the HP to 800. In the next test, the boss is now brutally difficult. Fantastic! You've just gathered much more information. You now know the ideal HP is somewhere between 500 and 800. You've bracketed the solution. Your next change to 650 is much more likely to be close to the mark.

The goal of your first change isn't to find the perfect value; it's to gather the maximum amount of new information for the next change.

Your Polishing Workflow

Here is a step-by-step process to apply these techniques to your demo:

1. Isolate the Problem: Take the highest-priority pacing/difficulty issue from your playtest backlog. (e.g., "The random encounters in the first dungeon are tedious and drain too many resources before the boss.")
2. Formulate a Hypothesis: Why is it happening? ("The encounter rate is too high, and the enemies have slightly too much HP, requiring extra MP usage.")
3. Identify the Parameters: List the knobs you can turn in your data files.
   • map_data.json: encounterRate for the dungeon map.
   • enemies.json: The maxHp value for the dungeon's enemies.
   • items.json: The price of Potions and Ethers.
   • enemies.json: The gold dropped by enemies.
4. Make a Bold Change (Triple Tapping): Don't just lower the encounter rate from 5% to 4%. Cut it in half to 2.5%. Don't lower enemy HP by 10. Lower it by 25%.
5. Re-Test: Play through that specific dungeon section again. How does it feel now? Is it a cakewalk? Is it still a slog?
6. Iterate and Refine: Based on your test, make another adjustment. If it's a cakewalk now, maybe bring the encounter rate up to 3.5% and enemy HP back up slightly. Zero in on the value that feels right.
7. Document the Change: In your project notes or commit messages, log the final change and the reason. "Reduced dungeon encounter rate from 5% to 3.5% and enemy HP by 15% to improve pre-boss resource management, based on playtest feedback."

Conclusion: The End is the Beginning

Congratulations on reaching the end of the course! Today, we've demystified the "art" of game balancing, turning it into a systematic process of analysis and refinement. You've learned to think about your game not just as a collection of features, but as an interconnected system of mathematical relationships that define the player experience.

Key Takeaways:

• Game balance is about creating meaningful choices and avoiding dominant or useless strategies.
• Mathematical curves (linear, quadratic, logarithmic) are the key to creating scalable and predictable progression for stats and difficulty.
• Your playtest feedback is data that points to which parameters in your game's database need tuning.
• Use a systematic workflow: Establish a Power Curve for baseline values, use "Dark Magic" to price complex effects, and apply "Triple Tapping" to iterate on feedback efficiently and quickly converge on a solution.

You have successfully built a complete JRPG demo slice, from the initial engine architecture to the final balancing polish. You now possess the foundational knowledge and practical skills required to expand this demo, add new content, and pursue your goal of creating a full-fledged game in the spirit of the classics you admire. The development cycle you've learned—Design, Implement, Test, Refine—is the core loop you will use for the rest of your game development journey.

Good luck, and have fun creating your world