There is a secret known only to RPG developers, a gleaming nugget of knowledge unearthed anew through long struggle by each succeeding generation of would-be Richard Garriotts and Shouzou Kagas. It is, simply: making RPGs is kind of a pain in the ass.
I love making RPGs, but it’s true. The RPG is a ramshackle colossus of systems, each one stitched onto the other, and all forced to interact to produce something resembling a cohesive play experience. Exploration, dialogue, combat, character advancement, item usage, inventory management, party management, crafting, stealth…even the most focused of RPGs is guaranteed to have at least three or four of these systems, each with its own attendant design demands and opportunities for bugs to show up.
But forget those design demands for a moment–because the truth is, it’s the content demands that are the real killers. An RPG with a play time of less than 20 hours is unacceptable to the market, and ideally, you should aim for 40 hours or more. You need to create so much art, and so much writing, and so many encounters to fill up those hours that even the most basic, old-school, stripped-down RPG can easily take years upon years to make.
A developer with limited resources at her disposal, staring down the barrel of a half-decade development cycle, might be inclined to wonder: “Is there some way that I can design my game’s systems to alleviate the burden of producing all that content?”
Well, I have good news! I’m here to tell you that you can: by designing your mechanics for scalability. Before we get into the “how” of it, though, let’s set out exactly what we mean by “scalability.”
Content scalability, and what it has to do with RPGs
I almost always hear the word “scalability” used in terms of building a business. In that context, it refers to the ability to efficiently grow one’s operations to take advantage of economies of scale. At the risk of oversimplifying it: if you can expand your business operations without having to rework the whole damned thing, it means your business is “scalable.”
Here, I want to talk about a different sort of scalability–the ability to efficiently grow one’s RPG content to meet the needs of your player as his or her characters improve. This is what I’ll call content scalability: design that permits the usefulness of (or challenge posed by) existing game content to scale so that the content remains relevant throughout the whole game.
When I say “content,” I’m not specifically referring to art assets. There are a number of techniques for structuring your game’s art assets to make them scalable (limited palettes and palette-swapping, for instance), but I’m not going to go into that here. Instead, I want to talk about game mechanics and how those affect content scalability.
Your game’s mechanics can have knock-on effects that impact content scalability throughout the entire game. To name one example: the choices you make in crafting your game’s combat and character progression mechanics can lead to brittle encounters which only pose an appropriate challenge during a very narrow window of the player characters’ development. Do this, and you’ll have to constantly recreate those same enemy types under new guises in order to keep encounters appropriately challenging–and you’ll also have to make your game more linear, exercising fine control over which areas players can access in order to keep them from constantly running into battles they can’t possibly survive. In short, failing to design for content scalability means taking on more work for a worse payoff.
By the same token, designing for content scalability means you can devote the resources you do have to making better content. Instead of creating enemies A, B, and C, where B and C are just reskins of enemy A with their stats manually rejiggered, you can use that time to create enemies A and D, where D is totally different from A. Approach (1) gets you “more enemy types,” but in reality, they’re functionally the same enemy; approach (2) gets you a game with more interesting and varied content without increasing development time.
And this, my friends, leads us to our very first technique for achieving content scalability…
1. Let enemy types spawn at differing powers levels
To be clear: I’m not talking about automatically scaling enemies to match the player’s level here. I’m only talking about making it so a given enemy can be spawned at different power levels.
Most RPGs have a fairly brittle way of constructing enemies: there are different enemy types, and each instance of a given enemy type is identical to any other instance of that enemy type. This means that when that enemy ceases to be challenging, it must be replaced with a new enemy type.
This is transparently inefficient, and thus, many RPGs will attempt to alleviate the burden this causes by recycling assets. The goblin won’t be challenging for long, so they’ll add in a tougher goblin that has a shield tacked on, and maybe an even tougher one with a palette swap.
However, this approach is still brittle: any given variant still has fixed stats, which means the variant is only usable for a relatively brief period. This, in turn, means that as the developer, you’re going to have to create yet more enemies (or variants of existing archetypes) to plug in those gaps, and you’re going to have to hand-craft their stats every time you do. That’s a lot of unnecessary work.
So, how to get around this? Simple: instead of creating multiple palette-swapped variants of an enemy, each with specific stats, just create one version of the enemy at level 1, then dynamically level-up each instance of that enemy to whatever you desire.
Take this example from Telepath Tactics, for instance: there is an enemy type called “Bloodbeard’s Bandit.” At level 1, every Bloodbeard’s Bandit is identical, possessing 19 Health, 3 Energy, 5 Speed, and 6 Strength. If I stopped there, I’d have to hand-create a new variant of this unit for when the player is no longer challenged by level 1 enemies: a level 4 variant, say. Maybe I’d palette swap that one so its skin is blue. And then I’d need another variant for when the player stops being challenged by level 4 enemies; and again and again, for as long as the player keeps battling this particular faction. The more I try to reuse this content throughout the game, the more of my time will end up wasted creating variants.
Instead of doing that, I gave this enemy some stat growth data: that is, rules for determining which stats improve upon level-up. (Bloodbeard’s Bandits are very likely to have their Health and Pierce Resistance improve upon level up; only slightly less likely to have their Strength and Slash Resistance improve; and fairly low probabilities to have their Energy and Counterattack Limit improve.) I also gave this enemy a skill progression: which is to say, a sequence of skills that it learns as it reaches particular levels.
With both stat growths and a skill progression in place, I was then able to use the exact same level-up function I used for player characters to dynamically improve Bloodbeard’s Bandits on the fly! This meant that I could tune the power level of each enemy to the needs of a given battle.
I could have a battle with all low-level Bloodbeard’s Bandits, plus one higher-level Bloodbeard’s Bandit as a boss. I could have a battle filled with Bloodbeard’s Bandits at whatever the player’s level is. For that matter, I could make a Level 60 Bloodbeard’s Bandit to serve as the final boss of the whole game! (Not that I’d want to do that, but you get the idea.) That, my friends, is scalable content: one enemy that’s useful as a challenge to the player throughout the entire game.
And this approach needn’t just apply to enemies: the Disgaea series and Fire Emblem Fates both allow equipment to level up, permitting the player to actively commit resources in order to keep less-powerful items relevant for longer. I don’t think I’ve yet seen a game that lets status effects from attacks level up, but that could be useful as well. Think outside the proverbial box!
2. Use linear stat progressions rather than exponential stat progressions
Lest you think that enemies are the only bits of content you really need to be concerned about scaling well, consider this: if you make the wrong choices in how your RPG handles its stock of items and equipment, you can end with the dreaded equipment treadmill. “Equipment treadmill?” you ask. Oh yes! The equipment treadmill is a condition which plagues many jRPGs, and can be described as follows:
[p]rogression through the game involves constantly replacing old items and equipment with newer, more expensive models. That stuff you bought in the last town worked really well against wolves, but now you’re fighting giant toads, and they barely scratch them. So you buy the really expensive new models. And those work exceptionally well–until you get to the next area, which has enemies those weapons can barely scratch, and a town that sells a yet more expensive version of that same equipment. And so on.
If you haven’t designed your mechanics so that item usefulness scales with the player, then as the developer, you’ll have to constantly come up with new item content that–functionally speaking–does the exact same thing as the old content. This is, bluntly, a waste of your time and resources.
One of the oldest and purest examples of an equipment treadmill occurs in Dragon Quest (originally known in the US as “Dragon Warrior”), the game that started off the Dragon Quest series way back in 1986. The reasons why this game has an equipment treadmill start to become apparent when we look at the stat progression employed for the player character and his foes. This stat table, put together by GameFAQs user akira slime, shows how the player character progresses:
As you can see, each stat (strength, agility, hit points and magic points) has one of two possible growth patterns–but in either pattern, you’re looking at a character whose stats increase by roughly two orders of magnitude over the course of 30 levels. Enemy stats, likewise, increase by very nearly as much over the course of the game.
For the sake of making the consequences of this clear, let’s focus on just one part of the game: Cantlin. By the time you reach Cantlin, enemy defense will be in the 60s and 70s, with hit points in the 60s. It is suggested that your character be at level 15 by this point, meaning that your strength will be about equal with these enemies’ defense ratings. Damage in Dragon Warrior is somewhat randomized, but on the whole, this means that much of the damage you’ll do with your attacks will be coming from your equipped weapon. Here, meanwhile, is your weapon table, courtesy of StrategyWiki:
By the time you reach Cantlin, you’ll most likely be about level 15, with a strength of either 58 or 64. You’ll also most likely have a hand axe equipped, with an attack power of 15, effectively putting your strength at either 73 or 79. The formula that Dragon Quest uses to determine attack damage is a little convoluted, but basically: pitting that sort of attack strength against enemy defense ratings between 60 and 80, your attacks will do between 8 damage (in the worst case scenario) and 25 damage (in the best case scenario). Against enemies with 58-65 total health, assuming no dodging or critical hits, that works out to between 3 and 9 attacks to kill a typical Cantlin-area enemy.
Upgrade to a broad sword, and your strength will go up to either 78 or 84–you’ll be doing between 9 and 27 damage per swing, putting your swings-to-kill rating between 3 and 8 (but much closer to the low end of those numbers). On average, you can expect the attack boost from upgrading your weapon to save you 1 swing in defeating your enemy in each combat, which translates directly to 1 turn in which the enemy can no longer attack (and damage) you. Apply that advantage over the course of numerous combats, and it adds up to a huge difference. Thus, the only choice that makes any sense is to upgrade your weapon!
The player is faced with this sort of non-choice repeatedly throughout the game. The optimal choice is never in doubt: the only difference between the weapons is damage output, after all, and higher is always better. But each time, climbing to the next rung of the weapon ladder entails a 3- to 6-fold increase in price over the previous rung. The new weapons just become an excuse for forcing the player to repetitively fight enemies so as to build up enough money to afford the next weapon. Hence, the proverbial equipment treadmill.
So, how do we avoid putting an equipment treadmill into our own games? One powerful solution is to adopt a linear stat growth approach: this will cause early game weapons to remain viable for much longer; potentially, for the entire length of the game! And all of that time you would otherwise have to spend remaking early-game weapons under different guises, over and over, just to try to keep pace with characters’ relentless stat inflation, you can instead put into developing weapons that actually behave differently so as to give your players interesting and meaningful choices about their equipment load-out and battle tactics. In terms of “amount you’ve actually improved your game” relative to “time you spent making content,” this is a way better deal.
This principle does not apply only to equipment, however; it applies to consumable items as well! Think back to…well, to any Final Fantasy game you’ve ever played, really. Pick any of them. Early in the game, there are invariably potions that restore some set number of health points (typically between 50 and 200). For the first couple of hours of the game, these items are incredibly helpful: indispensable, even.
But as the game goes on and character and enemy stats exponentially inflate, these items become increasingly unhelpful. By the end of the game, when characters have multiple thousands of hit points and enemies inflict hundreds or thousands of points of damage with every single attack, the notion of using up a character’s turn to restore a pitiful 200 health is just absurd. By that point, you’ll have long since graduated to spells and other, more potent healing items that can actually keep pace with the damage your characters are taking. Potions, in other words, will have fallen off the far end of the equipment treadmill.
Now, for the sake of comparison, I want you to think about the Fire Emblem series. The Fire Emblem equivalent to the potion is the vulnerary, which typically heals 10 health points when used. That might not sound very impressive, but unlike the potion in Final Fantasy, it remains genuinely useful throughout the entire game!
The reason why is simple: unlike Final Fantasy, character stat progression in Fire Emblem is linear. It’s so linear, in fact, that with the sole exception of a one-time (forget Radiant Dawn for a second) promotion, characters only ever gain +1 to any given stat upon level-up. Characters start the game with somewhere in the neighborhood of 16 to 24 health points; by the final battle at the end of the game, your very beefiest tanks might have hit points somewhere in the 50s or 60s, with your weakest units stuck with health in the low- to mid-20s. This means that even at the end of the game, that same healing item you relied upon at the game’s start to heal between 42% and 62% of a character’s total health can still heal damage equivalent to somewhere between 1/6 and 1/2 of a character’s total health. It’s not as useful as it once was, granted, but it never reaches a point where it becomes a total waste of time to have around. The linear stat growth of characters in Fire Emblem games means the vulnerary is useful the whole game through; it’s scalable.
What’s more, because the vulnerary is so scalable, when more powerful healing items like concoctions and elixirs become available, the player has a legitimately interesting choice to make about which items to take into battle for healing purposes. (By contrast, deciding whether to use a healing item that effectively does nothing versus a healing item that actually heals a reasonable amount of damage is not a terribly interesting decision.)
Now, I’ve mostly been talking about items and equipment here, but don’t think that linear stat progression won’t also improve the scalability of your enemy encounters, because it absolutely will! In particular, if you opt to ignore my first suggestion and choose not to allow your enemies to spawn at differing experience levels, then definitely employ linear stat progression for equipment and for player characters as they level up. This way, it will take longer for the player characters to completely outclass various enemies as the game goes on. This, in turn, will prolong the usefulness of your game’s various enemy types, and reduce the need to constantly cycle through new versions of your old enemies.
Phew–all right! That’s two suggestions down. We’re not done yet, though…
3. Use percentages instead of additive/subtractive effects
Having implemented suggestions 1 and 2, you might feel content to stop. Don’t! Not before you’ve given due consideration to using percentages for various in-game effects and character defenses, anyway.
Why would you want to use percentages when you could just use simpler, more intuitive addition and subtraction? It all comes down, once again, to content scalability. Consider a tale of two battles, each similar in approach, each in an RPG with enemy types that can level up and linear stat progression. The battles in question: the Leo battle (Chapter 18) from Fire Emblem Fates: Birthright, and the Coria Dogs Tavern battle from Telepath Tactics.
Both of these battles creatively reuse low-level enemies, forcing the player to stand against a swarm of them with his or her own, comparatively high-level characters. Because of the mechanics of these two games, however, only one of these battles actually works as a battle.
I won’t keep you in suspense: “Leo” is the one that doesn’t work. It makes use of the Faceless enemy type, with low-level Faceless making up the bulk of the enemy force. Defense in Fire Emblem is subtractive: a character’s defense is subtracted directly from an enemy’s attack rating to arrive at the damage dealt by a given attack. Because of this, these low-level Faceless can barely scratch your units–and in a great many cases, will actually deal no damage at all! It barely matters that you’re outnumbered. With most of the enemies on the map posing absolutely no risk to you, the battle is intensely boring. It’s less a fight and more like wading through a bog while swatting gnats.
The Coria Dogs Tavern battle, by contrast, actually works. This battle features a small horde of level 1 baddies, which by this point in the game are much lower in level than your own characters. But here’s the key difference between the level 1 enemies in the Coria Dogs Tavern fight and the Faceless in Leo: because defense in Telepath Tactics is percentage-based instead of subtractive, these units can still damage your characters with their attacks! Their sheer numerosity (combined with the risk that they may achieve backstab bonuses) means that the player remains under threat despite the gulf in levels between the enemies and their own characters.
“Okay Craig,” you might say, “I get the point: they should’ve made the enemies tougher in the Leo battle.” No! That’s not the point at all. Remember, our goal here is to achieve scalability in content. If the designers used fewer, higher-level Faceless, then it would have been just another battle between comparable numbers of characters of similar level–they’d be using their existing content in the exact same way they’d used it before. The designers had an idea for a twist that would reuse their game’s units in a new and interesting way, and the game’s brittle attack damage mechanics let them down. By subtracting defense directly from damage instead of reducing it by a set proportion, the developers rendered themselves unable to scale their enemy content in the way that they wanted.
This principle doesn’t just apply to defense and attack damage; it can be employed elsewhere as well. Health-restoring items, for instance. Instead of employing linear stat growth to keep a healing item’s restorative effects within a reasonable percentage of maximum health, you could literally just have those items restore damage equal to a set percentage of the user’s maximum health. The indie jRPG Deadly Sin 2 does this, and it works exceedingly well.
Status effects, too, are a good candidate for percentage-based math. This was actually something that I failed to do in Telepath Tactics, and it ended up making certain ongoing-damage status effects (like “burning” and “poisoned”) markedly less deadly by the end of the game. Burning, for instance, always deals 4 damage per round. Thanks to the game’s linear stat progression, this still matters at the end of the game, when a character’s maximum health is likely somewhere in the 60s–but not as much as at the start of the game, when it’s between 24 and 32. If I had it to do over, I’d have made the damage a set percentage of the victim’s total health (as more recent Fire Emblem releases have wisely done with their own “poisoned” status effect).
It’s an obvious point, but it bears repeating: developers have limited resources, both monetary and temporal. In this regard, developing a game is a series of zero sum choices about what to prioritize. With every moment a developer spends creating one thing, they choose–consciously or not–to expend resources on creating that thing and not another.
Devoting resources to content that effectively duplicates other content means not devoting those same resources to content that does something different–which enlarges the possibility space, forces interesting decisions, or offers the player role-playing options. Content scalability is not merely about staying on time and within budget: it’s about making a better game.
Craig Stern is an indie developer best known for the turn-based tactics game Telepath Tactics, and currently hard at work on a New Secret Project. Craig is the founder of IndieRPGs.com; he can often be found rambling in short, 140-character bursts on Twitter.