Spell Scalability (or, Utilitarianism in an RPG Setting)

No player wonders “Fire or Fire 2?”
Every player wonders “Flamethrower or Fire Blast?”

Of the three biggest RPG series—Pokémon, Final Fantasy, and Dragon Quest—only one has consistently delivered gameplay that brings compelling decision-making into play. Choosing to teach a Pokémon Surf or Hydro Pump reveals whether players place more value on accuracy and extra uses or power; choosing Heal or Healmore/Midheal reveals whether players know math. In Pokémon, only the earliest attacks become moot; the rest compete for one of four move slots. Each attack has its own niche advantage of power, accuracy, priority, status effects, or other quirks.

One positive to the streamlined spells of FF and DQ is the immediate clarity of progress; even if the names don’t make obvious which is superior, as in Blizzara and Blizzaga, the levels at which they’re learned will. However, most attack and healing spells eventually become wasted space that players scroll through and never use. Out with the old.

Secret of Mana is an early RPG that shows there’s nothing wrong with simplicity; in fact, maybe it needs to go one step further. These heroes bring their weapons to Watts the blacksmith to level them up through a reforging process that unlocks more of their inherent power. Spells grow stronger with usage, so they never fall out of favor; since no one would cast Freeze Lv. 1 if Freeze Lv. 4 was available, the SoM designers keep one core spell in the same menu position and progressively boost its power. Both of these techniques are straightforward upgrades that phase out weaker firepower as necessary, pushing it out of sight and mind to keep everything compact and useful.

On the other side is the Shining Force series, which keeps different levels of spells but asks the player to decide the appropriate strength depending on the situation. Magic does fixed amounts of damage depending on the spell, enemy HP is visible, MP costs are high, and the spells vary in their range and area of effect. A weakened skeleton with 4 HP can be safely dispatched with Blaze level 1 to retain an optimal amount of MP; a distant gang of adjacent gargoyles at full health should eat the brunt of Blaze level 3, which deals more damage and hits a cross-shaped area. Spread-out gargoyles call for Bolt 3, which hits the largest possible area; a boss calls for Bolt 4, which deals far more damage but only targets a single space.

The ideal no-dead-weight RPG either retains the value of every spell and ability from beginning to end or replaces the spells and abilities that lose their worth. I find that more recent RPGs than not get this right, but I’d like to be able to say that all of them do. This is an elementary concept in game design—an extremely crucial one at that, and every developer needs to consider it. It applies outside of RPGs as well. The silenced PP7 gun in GoldenEye 007 was weak and non-automatic, but it didn’t alert enemies to James Bond’s presence; in a time when first-person shooters usually followed the mold of Doom, where strongest equals best, the advantages of a handgun established that GoldenEye was no clone.

Writers know of a saying to “Murder your darlings”: a saying that implores them to kill their babies, which are their words. Game designers should hear about this principle too. If a weapon, spell, or ability doesn’t stack up to par—or a dungeon, or a level, or a race track, or a mission, or a piece of music, or a 2D sprite, or a 3D model—then cut it and cut it with no concern over how painfully and at what great length you labored to deliver it. Players don’t fall in love with game designers who give them a bronze medal effort. Cut slipshod work until everything in your game is gold—and then keep cutting. Gold is not enough. Neither is platinum. Cut until all that remains is a single flawless diamond.

2 thoughts on “Spell Scalability (or, Utilitarianism in an RPG Setting)

  1. Pingback: What’s In A (Changed For Localization) Name? | Game Design and Deconstruction

  2. Pingback: Dreamblazers Devlog: Week of March 23, 2015 | Project Dreamblazers

Leave a Reply

Your email address will not be published. Required fields are marked *