A Good Death
What is a good death?
I'm referring to these new-fangled videogames, of course, and specifically challenge-based games with failure conditions which force a reset of state - usually dying, hence the title.
That's the topic of this article, then, but I'm just going to arrogantly declare the answer below. Stick with me and I'll explain myself afterwards.
A good death is one which costs the player no more than they expected and which the player believes to be their fault.
Or, in short, a good death has acceptable losses and is fair.
Those are the two key elements to a good death, a term I have yet to define. For the purpose of this article, a good death is the kind which makes the player want to try again, to persist, as opposed to making them snap the controller and attempt to forcefully insert it somewhere the developer would prefer remained untouched.
This should be an important topic to game designers if only for the sake of personal comfort, is my point. If players can die in your game, they will. If it's something you can be sure every player will meet, it should receive significant attention in the design.
In order to discuss these elements, then, we must first discuss what they resolve. Specifically, we need to discuss the negative, frustrating aspects of failure, the reasons why we hate to die. There are two: Perceived unfairness and relative loss.
...is the belief that the player could not have avoided their death, that they had no input in their untimely demise. It is easily recognised by the phrase "Oh, come on, that was bullshit."
Unfair is the floor dropping away to spikes without warning. Unfair is the boss using his screen-filling ultimate attack five times in a row out of sheer randomness. Unfair is enemies spawning behind you in an area you'd thoroughly cleared. Unfair is really annoying.
The 'perceived' part is equally key, although less obviously so. Players don't play the game as it exists in the development notes, they play the game in their heads. The big signpost marked "Warning: Spikes" counts for naught if the player never bothers to read signs.
Everyone can probably think of a few examples here, games which fail you like a PE teacher in an English class - without rhyme or reason.
Of course, there's always been games which do this entirely intentionally, starting with the old arcade machines of yore in which any absurdity able to force even a skilled player to cough up a few more coins was considered fair game. In the modern era this has persisted in the form of games designed to be viciously lethal until assuaged by the calming touch of in-app purchases.
Please don't do this.
The other significant example are games which have the knowledge barrier problem. This is particularly common in RTS and MOBA titles, and occurs when a significant understanding of the game is necessary not just for players to win but to understand what happened when they lose.
At this point the 'perceived' element of perceived unfairness becomes the problem, causing many new players to reject the game before they achieve the mastery necessary to understand it. Until you build up an incredible amount of knowledge, the game seems equally incredibly unfair as players are unable to perceive the mistakes they made which led to their defeat.
Some things you need to know for League of Legends (to pick an example) to have a snowball's chance: Every ability your champion has, every ability all of their champions have, the power of turrets, the value of minions, which stats you need for your build, which items you need for those stats, which items you need to make those items, laning, group fighting, solo fighting, jungling...
Until you know all of these, League of Legends is easily perceived as unfair - and that's said to be one of the simpler titles in the genre. It doesn't matter what the numbers say about the balance, it's the game in the player's head which matters. The knowledge barrier translates into perceived unfairness until that barrier is overcome. This isn't to say that no games should have high knowledge costs - that's clearly ridiculous. The problem can certainly be resolved, but that's not the topic of this article.
...is the difference between what the player lost and what they expected to lose. It is easily recognised by the phrase "Wait, when did I last save?"
Loss is something that seems pretty simple; it's the time they spent, items they gained, experience they harvested, etc. etc. between where they died and where they start up again. The negative aspect relative loss isn't quite that simple, though. It can't just be that the more they lose, the worse it is - if that were true, no-one would ever play roguelikes at all.
It's actually to do with checkpoints.
Not the autosaving checkpoints beloved of modern games, of course. The checkpoints in our heads, the ones we don't even realise we're making. All the time, as we play, we're checkpointing subconsciously. A game's style and design affects exactly where and when, but we do. Every time we finish a battle, talk to a character, solve a puzzle, defeat a boss, open a door, every time we do anything we think is important. Checkpoint.
Then we die, and instinctively we expect to find ourselves back at our checkpoint, back at the start of "this bit". Except we're not, because the last autosave was before that long cutscene, because the last time we saved was at that village six hours ago, because we forgot to save since how far back? Jesus. Never mind then.
All of these common gaming frustrations are due to that disconnect between what we expect to lose (the minute we spent fighting the boss) and what we actually lost (the minute fighting the boss, five minutes in the pre-battle cutscene and ten minutes clearing out his easily-beaten mooks). That cost is much more than just the fifteen minutes.
Although autosaves are the most common cause of complaint here, it's worth mentioning fixed save points separately. Something of a JRPG entry in particular, the issue with these restricted save areas tends to be when these points are so far apart the player needs to unlock the obligatory airship to move between them. This highlights a notable point - the player can be actively, consciously aware of where they'll reload and still be checkpointing in their heads, still actively hurt when they lose more than they "should".
So those are the two negative aspects of death. Frustration at death comes from being unable to avoid it and losing more than we expect from it. Player frustration at any death in challenge-based gaming can be described using just these two terms, the axes of frustration.
Now we understand why death is frustrating, in the next part we can solve these problems with the aspects of a good death: Fairness and acceptable loss.
...is making sure that the player understands their death to be due to their own failure, at least in part. Since dying without understanding is unfair, it follows that we can make it fairer by telling the player how we're about to kill them. Then trying to kill them, obviously. Surviving is still their own problem.
This means you need to telegraph and you need to be consistent. Every enemy attack should speak of survival as clearly as it speaks of death, every trap should trace out the danger it represents for all the world to see. Assuming they look, of course - not only do things become fair, but a new opportunity for challenge appears, the challenge of correctly interpreting the warnings. Testing the player's perception, planning and learning, not just their reflexes.
Note that the consistency is necessary for telegraphing to be effective - if you send many signals but change what they mean the player can't actually read the warnings accurately and therefore nothing is being conveyed.
Clover Studio's last hurrah, God Hand, understands the rules of telegraphing and consistency through and through. A brutally (and comically) vicious game of hand-to-hand combat, God Hand will throw many, many punches during the course of the game. In response to this, you have a few options: You can step left or right, you can dodge where you stand, you can backflip away and you can hit your opponent in the face.
There are different limitations to each of these, different attacks they can or cannot deal with and different situations to which each should be applied - with the exception of the last, which should be applied liberally wherever it will fit. It's that sort of game, really.
When the punches (and kicks, grabs, flying charges, teleporting demons, sparkly death bolts...) are coming thick and fast, one thing pushes the game from frustrating to glorious: every strike can be predicted by the wind-up, with a little practice, and types of attacks look similar across many foes. Oh, some enemies will use feints or tricks, but there's nothing you cannot learn and then react to, nothing undodgeable or unbeatable. And when you fight and you watch and you learn and then you dance through a mad melee in a blur of perfect evasion and precision retaliation, well, then you earn the game's title.
Moving on from the simplest telegraphing of a strike to the more cautious environmental warnings, From Software's Dark Souls shows us the way with a lift. One lift of many, with one significant difference and a swathe of supporting ones.
You see, this lift kills you.
Specifically it cranks steadily up to the next floor, hesitates a short moment, then slams vertically into the spikes lining the top of the lift shaft. Charming, really.
No lift before this one has been dangerous in any way, in fact they've all been extremely helpful - an example of breaking consistency in order to avoid the player becoming complacent. To make sure the lift is fair despite not being consistent, many kinds of telegraphed warning are provided.
- The lift is found in Sen's Fortress, a trap-filled labyrinth which would make Indiana Jones put down his whip and go back to lecturing. That's our first clue.
- The second are the visible chains of the lift's pulley, which can be seen even when the lift has risen out of sight and as they pull, stop, pull, stop, reverse. The room is even large enough that it is unlikely the player will not see the lift rising at some point.
- For a third, the truly paranoid (i.e., anyone who got this far) can look up the lift shaft and see the spikes.
- Finally - but probably the first clue seen - the lift looks like this:
Players still die to this but it is impossible not to be aware that they were warned, which means realising that it was their fault and, therefore, that the lift was fair.
Telegraph that which your players cannot have learned, and be consistent so you don't have to spell everything out.
...is when the losses incurred by death align with the player's expectations. In part I we discussed the tendency for players to mentally checkpoint, constructing for themselves an idea of where they should return when they die. Our problem becomes making sure that the reload point and the player's checkpoints align.
There are two main approaches: either your game's load points are subservient to the player's checkpoints or the player's checkpoints are shaped by the game's design.
The former is common, usually with an autosaving mechanism of some kind. At its simplest games just scatter an autosave at the start of every level, or at every loading boundary, or every five minutes. Depending on the game just saving at the beginning can obviously be the best approach - Super Hexagon, Ridiculous Fishing and the like would make little sense with a mid-run save point. These are all short-burst challenge games, though. Anything longer form needs a smarter solution.
Gunpoint provides a noteworthy example of matching an autosave system to the design - it autosaves every five seconds and offers you the previous three autosaves to choose from immediately when you die. As Gunpoint is essentially a stealth puzzle game with chance of sudden death, dying usually indicates either a critical planning flaw - in which case it'll be fatal next time, too, forcing a change in plans or level restart regardless - or a minor mistake in implementation which needn't be too heavily punished.
Instead of scattering our autosaves, we can try predicting where they should be. Humans have a tendency to checkpoint at breaks in game flow. This means cutscenes (before and after), bosses (also before and after) and other significant events. It also means changes in environment; in particular traversing doors is a common trigger for mental checkpoints. A good boost to this strategy can be achieved with a lot of playtesting and analysis of their play, most famously used to the extreme by Valve.
Providing a manual save system is neither a solution nor a problem, incidentally, and instead is an addition heavily dependent on the overall design of the game. Manual saves let the player define their own game sections, possibly breaking something intended as a larger experience into smaller sections through repeat saves. This isn't necessarily an issue, it just depends on the game's design. That said, if you're relying on a manual save to create acceptable loss, relying on the player to remember to save regularly, you either have a non-real-time game or not as much control over your design as you might want.
On the other hand I also suggested shaping the player's checkpoints according to the game's design earlier. Put simply (and it isn't simple) you have save points or autosaves which are designed not just to force the player to checkpoint, but also to get them to stop checkpointing on anything else.
The earlier Resident Evil games had a neat trick for this, requiring the expenditure of a finite number of ink ribbons to save. When saving is a commodity the player becomes very aware of their last investment. That said, a fine balance is necessary - if the player ever actually runs out that's not going to result in an acceptable death at all, but having too many ruins the effect.
The best example of shaping player checkpointing I've yet seen can be found in Dark Souls, and specifically in its iconic Bonfires. I could write an entire article on challenge-related design in Dark Souls, but the Bonfires may be my favourite.
Their appearance fits with the game's aesthetic but stands upright and visible, and the game rarely hides them. First marking one as reached involves lighting it with a press of a button and a unique lighting animation, cementing the success of advancing further in the game. Once lit, warm and comforting flames curl upwards from the base - an effect used nowhere else, since offensive fire effects are faster and far more aggressive. Actually using them as a checkpoint even involves your character sitting down at them and resting. Their entire design is geared towards having the player checkpoint there and only there. They're fundamentally just save points, but I've yet to see a better save point.
...I like to play Monster Hunter 3 Ultimate. Monster Hunter is a game of planning, learning and attrition, a few hunters attempting to wear out and bring down a seemingly unstoppable mass of muscle and bone. My first proper hunt in Monster Hunter was a Barroth - an oversized T-rex with a club tail and a tough bony spade-like ridge for a forehead.
The battle takes forty full minutes of my constant attention. I have no potions, precious little health, my stamina failing me. He limps, much of his strength lost, many attacks ending in lumbering falls. Earlier he raged and I could do little but strive to dodge and survive but now even that fire is gone.
He seemed unstoppable, invincible and powerful, but I'm learning.
When he lashes out I dance aside, when he pauses I strike where he cannot reach, when he shakes great masses of mud to delay me I step in to cut at his vulnerable belly. We're both nearing our end.
He charges, great ridged head lowered. I step in, roll left, turn to raise my sword for the final blow - and have time enough to realise my mistake before a flicked tail smashes me into a defeated backwards slide.
Forty minutes and a great pile of potions, whetstones, rations and resources, everything I have lost, and all I feel is exhilaration. I earned every step of that battle. The loss of that much time and effort would be inconceivable to many games, but that was a hunt, its separation from the safe camp clearly defined, and I had failed it - an acceptable price, a reasonable one, stated up-front. My defeat was my own mistake, the flick of a tail which always flicks in that direction on that attack, a mistake I had made and learned to avoid but still, in the end, forgot. A fair end, without a doubt.
A Barroth is, by the standards of the game, a very weak monster - but that battle is still one of my most fondly remembered.
Death is frustrating when players lose more than they expect and feel that they have been cheated out of their fair earnings, and this loss can be made acceptable by either understanding or defining what they expect to lose. Death is frustrating when players feel that they have no control over their loss, and can be made fair by informing the player about the threat of death both before and after, such that they either perceive the threat or recognise their mistake after the fact.
A good death is one which costs the player no more than they expected and which the player believes to be their fault.