Show Notes:
Mathew and Attila discuss Death and Energy Systems in games. Games discussed in the show:
Robo's World: The Zarnok Fortress
Extended Thoughts
We are fortunate to live in an age where just about anyone with time and dedication can learn to make games and share them. Of course, initially, games and the cabinets they were housed in were very expensive to produce and manufacture, so anyone fronting the cash for creation of an Arcade cabinet needed a promising return on investment. The ideal solution to this would be creating a game that is so much fun to play that it would attract a lot of positive attention. Unfortunately, the case often was that games were made to be incredibly difficult to create circumstances under which players would die frequently and have to keep pumping quarters into their machines to keep playing. This is not to say that all games in this era which were difficult were bad games, not at all! If you're playing a bad game and you die, you give up and move on to another cabinet, bitter about your lost quarter, but that's it. These games needed quality game play to keep players invested in their experience so they would, in fact, invest actual quarters into it.
This created a particular breed of gamer; after all, if you had a budget limiting the number of times you could die, it became all the more important to master the game and play cautiously, taking in your surroundings and memorizing the structure of familiar levels to limit the number of times you died.
As time went on and home consoles became available for purchase, many arcade games were ported onto them. Many games produced in that era were made with similar levels of difficulty to their arcade port brethren, although with a different motivation. Rather than having to justify an endless stream of quarters from the player, games needed to justify a large up-front cost. Now, the difficulty of a game wasn't used to draw money out of the player, but to elongate the player's experience and make the initial investment seem more worthwhile.
In the modern era, the last old ideas about death are slowly being overturned, studio by studio, but there are many studios for whom it seems the old line of thinking is all they know.
We are now in an era where designers should be thinking about death as a possible means of helping players, rather than as a punishment. For instance, if a player is attempting to make a jump between between two ledges but fails, it is more merciful to "kill" the player and drop them back at the top of the ledge than to force them to climb all the way back up before attempting the jump again. Of course, for this death to truly be of help to the player, there are other things that need to be addressed about the nature of that death. Designers need to evaluate the penalties and "iteration time" associated with the death condition in their game.
First of all, not every Death needs to result in a penalty. Try to see if you can separate the instances in which a player deserves an actual penalty from those where the death is not necessarily deserving of penalty. After all, not every death is a failure, and not every failure should result in death. As designers, we must divorce Death from Failure in our minds. I would not go so far as to remove all penalty from all Deaths. For after all, if death has no meaning, it can rob you from your sense of satisfaction upon completing a challenge without dying (although, if a challenge is difficult enough, the measure of skill might simply be how efficiently an objective can be completed, and Death need not even be a factor). The genre and mechanics of a game determine what sort of penalties are possible in a game, and which make the most sense. Typically, the penalties for death involve taking progress away from the player, usually in the form of traversal (having to re-navigate an environment to get back to where you were) or in taking away currency which the player needs to progress. Sometimes, the traversal penalty is combined with the currency penalty, forcing the player to loose both on death. In games like Shovel Knight and perhaps more famously in the Dark Souls series, lost currency can be reclaimed if the player can navigate back to their point of death provided the player doesn't die again, in which case the original currency is lost forever, and they loose more of what they had. In Dark Souls, this creates a constant tension as you are always in danger of loosing the required currency for leveling up. The combination of both traversal and currency penalties may seem harsh, but it is integral to the play experience of the game and has been expertly woven into the design of the game and the nature of its challenges. However, just because it works well and is well regarded in the Dark Souls series doesn't mean everyone should lift this mechanic wholesale and add it to their game, especially if your game has more traversal based challenges that can result in instant death.
In Dark Souls it is the player that chooses to press on, and how far they travel before retreating to a Bonfire and spending their currency. In Shovel Knight, you can only go forward through a level and cannot spend your hard-earned currency before you end up in a scenario where you loose it.
For a great example of how the traversal penalty can actually be helpful, we can look at the check-point system in the Halo series. When a player dies, they are reset to an earlier period in time before they died, usually very close to when they died, but after dying many times over, they may be sent back further.
When the player is sent back further, it is an opportunity for them to scavenge different weapons for the fight ahead, or perhaps pick up more ammunition or even find a different angle of attack on the encounter which has killed them so many times. Of course most times, a player has only failed due to execution (not equipment) which is why the designers give them a couple tries from a nearby checkpoint before they consider sending them further back in the level. and the player always has the option of reverting back to their previous checkpoint if they feel they are in a no-win scenario.
Iteration time should be thought of as the time it takes between when the player dies to when they get to try it again. For instance, if you expect a player to encounter death frequently in any part of your game, the iteration time should be kept as fast as possible. This means no lengthy player death animations, and if possible, no long load sequences should be necessary to reset the player to get another shot. Here's another, even more basic affordance; if your game uses a Keyboard as player input with the Arrow Keys and perhaps Spacebar for jump, don't force the player to press the "R" key to restart the game after they died. There is no reason they should have to alter which keys they have their hands resting over. The only time you want to make the process of restarting difficult to perform accidentally is when, in the instant the player respawns, they must be ready to give the game their full attention to prevent another, quick death. However, if you're contending with that situation, then perhaps your Checkpoint system needs some refinement.
As is often the case, the most important thing to remember is that you want players to complete your game, and even Death can be a tool you can use to help them accomplish this.
