Heretic
Cipher
- Joined
- Dec 1, 2015
- Messages
- 844
An interesting article.
http://sinisterdesign.net/designing-rpg-mechanics-for-scalability/
Excerpt:
http://sinisterdesign.net/designing-rpg-mechanics-for-scalability/
Excerpt:
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 create new enemy types 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.
And this, my friends, leads us to our very first technique for achieving content scalability…
1. Let enemy types spawn at differing experience 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.
Exhibit A.
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 theexact 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.
http://sinisterdesign.net/designing-rpg-mechanics-for-scalability/#imageclose-4573
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! 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, keeping 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:
http://sinisterdesign.net/designing-rpg-mechanics-for-scalability/#imageclose-4574
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: