ISSUES OF CHEAP HEALING IN RPG DUNGEONS

In the recent game balance roundtable, one of the issues we brought up but didn't really get to touch on was the question of how easy healing should be between encounters. While many questions of game balance depend on a lot of factors, this is one I think can be looked at tolerably well without getting too complicated, while providing an example of how design choices can combine to produce unwanted effects.


The Importance of Having Stakes

Briefly, one of the essential components of challenge in a game is that actions have consequences and some consequences are worse than others. The difference in consequences is what gets players to try to accomplish something over an easier or quicker option.

In a typical RPG, a battle threatens the player with two possible negative consequences:

- The player can fail to proceed.
While often this comes in the form of "Game Over", that's not the main point. You have to survive the dungeon or beat the boss to reach your ultimate goal of finishing the game, that's all.
- The player can spend resources.
The player has to make a sacrifice to get out of the battle, either something he had or a potential reward. If this resource could be used to get him out of some other battle, or acquire some better resource later on, this is a negative. But if the resource isn't scarce - if for little cost the player runs little risk of ever running out - it's not a negative worth considering. (One big thing I'm glossing over is the role of time as a resource, which can be a complicated issue in RPGs. Another interesting possibility here is bragging rights - some resource that doesn't make the game easier that the player still wants.)

What cheap, easy resource restoration does is remove this second threat. It hardly matters whether this comes in the form of letting the player bring in tons of cheap healing items, or of healing the player up at the end of battle, or what. Now, there's nothing necessarily wrong with a game in the situation I've described so far. Plenty of games and puzzles do just fine with binary won/not-yet-won results.

The trouble with RPGs, though, is that they tend to have dungeons.


The RPG Dungeon

Since in the easy-healing RPG we don't need to worry overmuch about shopping or finding an inn, we can work with a pretty simple definition of a dungeon: it's a sequence of encounters that occurs in between chances to save the game. Losing a battle forces you to reload from a save. And it's common enough that rewards from beating enemies are fairly static: we can simplify the entire result of the battle to "player gets to continue y/n" without losing much information.

The point of all this setup is that at this point the game designer has run himself out of options: each battle has to threaten the player with a situation where he can lose, or there is no point in fighting it. But to give the player any reasonable chance of getting through a dungeon with several fights, the chance of losing any given battle has to be pretty small. For a player to have a 60% chance of getting through a 10-battle sequence, he needs to have a 95% chance of beating each individual battle.

That's not a lot of risk for the designer to work with. In this setup, once the player knows he's going to win, the rest of the fight is pretty much wasted time. If only 5% of the battles can be losses, how many will even be close?


Application: an exercise for the reader.

Obviously this is simplified. It's not meant to be a conclusive condemnation of every game with cheap healing and dungeons, just the framework for an argument that can be constructed against many of them.

So, if we'd had the time to discuss this minor facet of game balance in the roundtable, this is what I would have tried to get across. But I'm posting it not because I think we can exhaustively cover everything falling under the umbrella of "game balance", but because in a lot of ways, I think this analysis is typical of gameplay systems design.

You'll have some set of choices made for good reasons that do a lot of things well... and then you have to work things through, checking the edge cases, figuring out problems that the combinations of those choices cause. Anything you introduce to solve a problem is of course a choice, and the cycle repeats. The designer looks at things, applies his tricks, and eventually comes to some combination of consequences he can live with.


That's it.

I hope this was helpful.