next »

[RaconteurNick]

Hi everyone!

I'm Nick, the lead on Close Order. We're releasing via Early Access very soon and it's so exciting!

There's been a discussion recently at Raconteur about the necessity of player death. Some of us think that there are other challenges besides surviving, so it's not entirely necessary if done correctly. However, some are strong believers that there's nothing to fight for if you can't die/fail, and subsequently, player death is ABSOLUTELY necessary.

We're doing a two question survey here, but I wanted to weigh in with the wonderful minds of TIG.

What do you think? Is player death something inseparable from games by nature? Or do you believe there are other ways to emphasize challenge and complexity rather than simply encouraging the player not to die?

[DireLogomachist]

Interesting idea.  I think player death is mostly used as a temporary reset mechanic, rewinding player progress to some point (last checkpoint, last save, level start, etc.) Some games use it differently - roguelikes for one use death not as a temporary reset but a permanent one.  Both uses raise the stakes of the game and give clear win and loss states.

Without a loss state from death, the flow of the game may suffer.
Reset mechanics like death can help game flow by letting users cut their losses when on a failing streak.
Sometimes being forced to limp along to the finish line can be worse than failing and being sent back to that start.

[starsrift]

Games are about presenting the player with a challenge that they make choices - or practice reflexes (skill) - to overcome.
Death is a punishment mechanic to emphasize the failure and encourage the player to make different choices - or practice their skill.

I don't think death is a necessity to every game, but it adds tension and punches up the immediacy of the game for the player. It's a way to interact with the player, rather than an integral component of the actual game's system. If you don't use death to generate tension, you have to add it in via other ways.

With a quick log at your tig-devlog and without downloading your demo, I'm not sure in what way you want to have 'death' be a thing. Failure to complete the immediate challenge should be a death, right? I mean, if it isn't, you're just cruising around until your ships blow up their ships? I would assume?
So are you talking about number of attempts you want to allow the player to have in the course of your campaign?

Again, I'm not familiar with your game mechanics, but the one thing I would strongly avoid with your game is to punish the player by placing them in the situation where they can 'permanently' have minions die and succeed a mission - and then end up with insufficient minions to continue the next.

[Zorg]

Death seems to be the ultimate fail state.

In a business simulation, having lost all money, or being fired says basically the same (without the actual death part), imho.

[RaconteurNick]

Interesting idea.  I think player death is mostly used as a temporary reset mechanic, rewinding player progress to some point (last checkpoint, last save, level start, etc.) Some games use it differently - roguelikes for one use death not as a temporary reset but a permanent one.  Both uses raise the stakes of the game and give clear win and loss states.

Without a loss state from death, the flow of the game may suffer.
Reset mechanics like death can help game flow by letting users cut their losses when on a failing streak.
Sometimes being forced to limp along to the finish line can be worse than failing and being sent back to that start.

I definitely agree that it affects the flow of the game. However, I then think of a really simple example -- Animal Crossing. Are the stakes high by any means? Not at all! But there's no way to "fail" (and no way to "win") yet people eat it up (myself included)!.

I don't think death is a necessity to every game, but it adds tension and punches up the immediacy of the game for the player. It's a way to interact with the player, rather than an integral component of the actual game's system. If you don't use death to generate tension, you have to add it in via other ways.

With a quick log at your tig-devlog and without downloading your demo, I'm not sure in what way you want to have 'death' be a thing. Failure to complete the immediate challenge should be a death, right? I mean, if it isn't, you're just cruising around until your ships blow up their ships? I would assume?
So are you talking about number of attempts you want to allow the player to have in the course of your campaign?

Again, I'm not familiar with your game mechanics, but the one thing I would strongly avoid with your game is to punish the player by placing them in the situation where they can 'permanently' have minions die and succeed a mission - and then end up with insufficient minions to continue the next.

Good points! In Close Order, currently, minions can die (as our entire core mechanic is based on building them to fight enemies), but the player cannot. We have context-specific situations that simulate fail states (for example, getting sucked into a black hole, which propels you back to the hub world/level select area). I think as long as the player has a way to feasibly keep moving forward, and you've given them an interesting context, they won't care about whether or not they can die, because if it's not interesting anyway, they won't play!

Death seems to be the ultimate fail state.

In a business simulation, having lost all money, or being fired says basically the same (without the actual death part), imho.

Very true! We tend to think of failure as an all-or-nothing-type situation. It interests me as to how we can present alternative situations to players.

[JWK5]

Death, no. Consequence, yes.

Why not stick your hand on a hot stove? You'll get burned. Why avoid getting hit by an enemy's arrow? You'll take damage. Consequence and reward are tools of direction. Player death is just a means of directing the player through the level (for example), it is not necessarily the only or best means and it is not essential or even necessary for every game.

[DXimenes]

Death in games, as anything, is drapery hung over a logical system.
It is very important drapery, sometimes so important that you decide to change the logical system underneath it so that it looks better and adds more meaning, gives the game more depth in player experience, but it's still drapery.

In some games, death means absolutely nothing to the player, as he can die any number of times without consequence. In this case it becomes only a way to produce visceral responses on the player - one which will get weaker with each death>rebirth cycle as the players gets used to his death amounting to nothing.

Adventure games particularly don't have Death as a core mechanic, but the player can and will get stuck on certain parts of the game and this is punishment enough for not exploring.
Roguelikes (like in our Satellite Rush) use permadeath as a core game mechanic, not as punishment but as something that dictates the pace of play, making the game about learning with each new run.

The real question is: what does Death bring to your game?

[JWK5]

The real question is: what does Death bring to your game?

Also, consider what it might take away from your game.

[King Hadas]

Failure is automatically built into a challenge, the designer doesn't necessarily have to point it out with a fail state. As an example in Space Chem most levels don't have a lose state, you either can or you cannot complete a level. Success/Failure.

Actually killing the player does give good feedback though, letting the player know they're doing something wrong.

[DXimenes]

Failure is automatically built into a challenge, the designer doesn't necessarily have to point it out with a fail state. As an example in Space Chem most levels don't have a lose state, you either can or you cannot complete a level. Success/Failure.

Yes, but you have to establish that "getting stuck" is a possibility early on in the game and make it very very clear to the player. If you don't, you're failing on fulfiling compliance.
Keeping the player stuck without making him know that whether he can or can't complete a level is his judgement call and not the games is basic. Otherwise he can just get needlessly frustrated, which makes your game a little worse...

[Jordgubben]

Some kids games do not have a fail state (Kirbys Epic Yarn, LEGO-games, etc.). Some forms of  solitaire do not have a fail state either. Common for both of these classes of games is that they are usually played for relaxation, not for challenge.

[sodap]

sandbox games come to mind, in many/most of them you can't win nor lose

[darkhog]

I'm with OP that death is not that necessary if game provide other challenges. Those challenges may be puzzles or other. Most puzzle games worth playing doesn't have any death, only gameover when you really f-up beyond recover.

For sandbox games, death isn't that important either. If done right, you will get successful game without death. Heck, in GMod you can't die (not in default game mode at least) and it's still a success story.

[Bmud_Team]

Very interesting question, I would have to say that player death in my opinion is not a necessity, I agree with DireLogomachist, the reset mechanic that the player death has is paramount in over coming challenges. Many other games substitute player death with another action such as a loss of an item, power-up, animal, crop etc.

I believe that the reset mechanic is definitely important in games, it quantifies the players progression, failures and achievement’s, which in turn allows the player to feel immersed and satisfied with over coming a challenge.

[oahda]

"Death" is definitely overused and I've heard it cited as a relic of the arcade model, where it was necessary so that they could have people lose in order to put in more money or let other people play — it seems a lot less necessary in many games today that are not arcade games, and many games seem to have a "death" state where it really doesn't add anything, seemingly there only for the sake of tradition.

So no, it's not important, but it might actually work for some games. I definitely encourage anybody to think about solving it in some other way (or just scrapping it entirely) before they add it automatically out of tradition, tho.

---

I actually used "death" for the first time in a long time for my last LD game this weekend. It's a game where you're walking through a long set of corridors, with a little puzzle kind of thingy in every other notch with monsters that will chase after you if they see you, killing you and taking you back to the last checkpoint, which is always right before the puzzle section you lost at.

I think it made sense in this game, because here you were supposed to get scared by these monsters and either avoid them entirely or have only few seconds to trap them or lock yourself in safety behind a door before they reach you, making it important that they do not get to you.

In this game I felt it made sense, to help "provide" the player with some panic, but it's been a very long time since I last felt like adding a death state to a game.

But I almost always avoid using death states, and I'm really trying to make it interesting in one of my main games now by providing different paths to go from somewhere in case something should fail (then that chance is permanently lost and there will be some other way that has to be found instead).

My other main game might do something like this: you're entering a cave of sleeping trolls, having to sneak past them, but if you wake them up, they don't kill you, but simply chase you out of the cave, making you have to try again, or perhaps they might throw you in a dungeon where you have to start from like the first time you're in Forsaken Fortress in Wind Waker, keeping the flow of the game intact without breaking out of the game into a "death" screen.

---

"Lives" too are important to think about. They're often even less necessary than "death".

In a game like the main 3D Super Mario games (SM64, Sunshine, Galaxy...) they seem completely unnecessary because there is already a direct death state if you run out of "health", and decreasing "lives" until a "game over" state where the only loss is that you have to walk back to the level (which isn't an actual loss) isn't really a punishment — it's just an annoyance.

There's nothing about the "game over" state in these games stopping you from continuously trying until you make it; it just takes a few more seconds to get back to the level after every X lives when you get "game over" instead of simply "death" and you don't lose anything else, so the game might as well just have had the "death" state alone ("health" runs out) and just restart the level like it does when you lose a "life" anyway unless it's "game over".

[Orymus]

If you take a look at games such as Zelda: A Link to the Past, you'll notice you can abstract death as "loss of time" (nothing is undone, you just need to re-enter the dungeon from a distant location).
Conversely, many other things can you make you lose an equivalent amount of time (not having the required arrows to kill a Red EyeGore which acts as a hard check monster.

(Details on this here: http://www.gamedev.net/page/resources/_/creative/game-design/the-art-of-enemy-design-in-zelda-a-link-to-the-past-r4147)

[Moth]

Orymus, that's a spectacular analysis, kudos for such a great article.

[Orymus]

Thanks Moth.
But it goes to say how much Death is a construct that appeals more to theme than mechanic. It's really the 'red screen' that makes death so memorable, because in many games, the outcome isn't that bad (in some, almost non-existent in fact).