The Joy of Ilinx



Have games become too dependent on health-based mechanics? Health is a common resource mechanic in videogames, and is easily understood by any player. Do certain types of games require health mechanics? Would you miss them if they were gone?


  • Health originally appeared in game designs as a more forgiving version of arcade-style 'lives', reflecting a change in the underlying interaction models from 'mistake = death' to 'mistake = loss of health'. Also, we are gradually moving from 'death = game over' to 'death = reposition' (e.g. move avatar to a hospital). Can we take this chain further?
  • In Shadow of the Colossus, certain actions by the player result in a timed penalty, at times when other games would inflict a health penalty. For instance, if one falls a great distance, it is a second or so before being allowed to move again. Similarly, a collision with a geyser leaves the avatar immobile on the ground for several seconds. Is this system an improvement? Or an annoyance?
  • Very few modern games posit an immortal avatar; death is pre-supposed in most games (Animal Crossing not withstanding). Imagine a GTA-type game in which the avatar cannot die. Vehicles can still be destroyed, and missions can still be failed. (Our pre-production game Bandits was based on this premise). How much would this hurt the play of this kind of game? Does avatar death provide a significant source of fiero by intensifying the risk of failure?


Feed You can follow this conversation by subscribing to the comment feed for this post.

Lego Star Wars does something a little bit like that: although there is a health system, the player´s character has infinite lives (which is different, but slightly similar, to an avatar who cannot die). It could have been a risky design decision - but it seems to work! Of course, the Lego universe was the perfect setting to test it...

I guess that games less centered in ´ludus´ have a better chance of abandoning such conventions (as the Animal Crossing series has been doing). Plus, the concept of "lives" is directly connected (or so I´m told) to the coin-op Arcade system, where it makes more commercial sense.

I'm thinking of using health only in a limited context, where it delimits specific instances, namely combat situations, which are relatively rare compared to other games. The health works the same way you'd expect, until you lose, at which point the story takes a different flow than if you'd one, or, if you managed to corner your opponent into a draw with an immobilizing spell or somesuch, which provides the third option.

Both with reference to this post and the previous post about minimalist vs. complex or baroque (which I think is an excellent term for sprawing games like GTA), I was reminded of the classic game Another World (known to us Americans as Out of This World). It's a classic for many reasons, least of all its radical visual styling, but equally for its incredibly elegant storytelling and play mechanics.

Another World might be slightly too fiero-centered/"old school" for some players these days, with its passcode progress system and somewhat unforgiving one-shot-death mechanic... but progress still ratchets fair better than some recent games, and I believe most people are willing to overlook that in favor of the game's brilliantly elegant control scheme (lots of verbs packed into 4 directional keys and two action buttons). As a result the game also lacks any HUD elements... we've had the discussion before about how that's an admirable goal but not really suitable for all game types, it's undoubtedly an asset here. I bring it up because I honestly think it's one of those rare exemplars of great design--simple to learn but engrossing for all players.

Debates about health systems also recall the difference between classic Sierra adventure games and the classic SCUMM-engine based of LucasArts games. Sierra adventure games for the most part were a gallery of a thousand deaths: characters could fall off ledges or precipices, succumb to a variety of hazards or timing-based challenges (though not explicitly "action"). In fact, death was so much a part of these games that, especially in the Space Quest series, killing off poor Roger Wilco in a variety of entertaining ways was part of the fun.
In diametric opposition to the Sierra model, all the old LucasArts games never (or very seldom) allowed the player to die; if they did, he was immediately replaced in the position just prior to death.

Obviously the LucasArts model was "more fun" or at least less frustrating for a lot of players, making them much less prone to ritual and compulsive game-saving, but by the same token it lost a lot of the tension induced by certain situations in the Sierra games.
If you know that failure or death isn't a possibility when you're playing the "wrestling with the bear" sequence (not a real sequence, but shouldn't it be? :) ), I would wager that the dramatic tension of the situation is considerably diminished.

Most of the time, I'm happy to take a game that allows me to die (with smartly ratcheted progress, anyway) over the alternative of feeling like I'm stuck in some sort of limbo, created by my own inability to solve the possible/beat the given challenge. In some situations, at least dying is giving the player some sort of feedback.

Oh, and I meant to link this when I mentioned Another World: the game's original creator re-calculated the vector graphics and spruced up the backgrounds a bit, and re-released it for a small sum.


game purchase:
it costs €7, which is roughly ~ $9 / £5

Perhaps a "deeper" question would be: What role do health systems play in games? And, the followup question would be: What other gameplay elements can game designers tap in order to fulfill the same role.

I think we'll find that "health systems" are used for very different purposes across different games...and that similarly, other games use non-health systems to accomplish the same goals.

Consider the following, all similar, yet subtly different:

1. FPS with healthpoints and healthpacks.

2. FPS with healthpoints and always-on regeneration.

3.FPS with healthpoints and shieldpoints.

4.FPS with health and shieldpoints. Shield regenerates, health does not.

5. Driving game with damage modelling that decreases vehicle performance.

6.Driving game with decreasing time counter.You get time added to the clock by reaching checkpoints.

7. "Marble" game, with decreasing time counter. You lose time from clock when marble rolls off ledge.

8. RPG where you "die" if you don't regularly "eat".

9. Missile command - your cities (lives) are under attack and you must protect them. (lose a city = lose a life?)

10. Game where you have a certain number of "moves" to solve a puzzle. ( 1 move = 1 life?)

Hmm..lots of food for thought!

I always saw the move from an "instant death" mechanic to a "health" mechanic being a move driven by the increasing complexity of games. In, say, Space Invaders, you could only make two kinds of mistakes - a mistake which cost you an opportunity, and a mistake which cost you a life. As games (particularly brawlers and fighting games) became more prevalent, there was a necessity to gradiate mistakes - to be able to separate a small mistake from a big mistake. A small mistake costs you x health, a big mistake costs you 2x health. (Of course, a lot of these games still implemented this badly by having bottomless pits where a mis-timed twitch cost you an entire life.)

I think it matters less what punishment mechanic you use than it does to accurately correlate the extent of punishment to the depth of the mistake. "Sitting out" several seconds for a tiny mistake is a very bad idea; likewise allowing an instant respawn after the player deliberately jumps to their death breaks immersion.

I think Greg's spot on--Chris' example from Shadow of the Colossus of Wander suffering the "stunned" response from long falls or a particularly bad jostling fulfills the requirement of gradiating the reponse to a given "mistake" to the appropriate level, but without (unlike many boss fights in games) seriously impacting the player's health. There are countless boss fights where getting hit with the boss' giant (yet easily avoidable) projectile equals death or near-death, which is a much harsher punishment.
Not that SotC has it perfect. Though the "stunning" mechanic usually works very well as both a play mechanic and to help heighten dramatic tension, there is at least one Colossus' attack pattern that is just slightly faster or equal to the time it takes to recover from being stunned. Such that being stunned once means being stunned repeatedly, often to the point of death, which is one of the most frustrating positions possible to put the player in.

Chico: LEGO Star Wars recieved a lot of praise for its infinite lives system... I don't want to knock the game at all, but I am honour bound to point out that the majority of platform games have had infinite lives for years now! I think that game players in general just stopped playng platform games and thus forgot that this had already happened! :)

Oh, and spot on with the co-op connection. Lives and timers both originally existed as a convention to promote putting in extra coins. In fact, the Game Over screen itself is an arcade relic. I contend it's value in modern games is limited (except for games trying to replicate arcade-style play).

Patrick: Magic Circle is now so imbedded into your thinking you don't even namecheck it any more! :) I like the idea of failure in combat resulting in narrative consequences instead of repitition; this is similar to what we were planning for Bandits.

Jack: The adventure games did indeed subdivide into two types: fatal and non-fatal (or rarely fatal). I originally included a comment about this, but trimmed it to keep the post short. Magnetic Scrolls Jinxter was, I think, the first game with no concept of death (or permanent failure, if you will) - but I'm prepared to be enlightened to earlier examples.

The two adventure games I worked on - Discworld II and Discworld Noir - were non-fatal. Actually, you *do* die in Discworld Noir, but only as part of the plot. :) I personally don't think the dramatic tension in Noir was affected by the removal of death, any more than the dramatic tension of a novel is affected by the knowledge (in most cases) that the protagonist has script immunity.

Jose: the four FPS examples are all functionally similar. (1) and (2) are distinct, as (1) favours fiero at the risk of greater frustration, whereas (2) reduces frustration but increases the risk of boredom. (3) and (4) are what we have called bipartite health systems, and are simply extensions of (1) and (2) - although (3) should probably be called Health and Armour. The interesting case is Goldeneye where Health cannot be restored but Armour can. In all cases, it is resource management for the purpose of building tension and supplying fiero.

(5) is not what I would call a Health mechanic personally, it is rather a positive feedback loop which penalises the player for their mistakes. Not recommended except in games where loss of vehicle is not equal to failure! (e.g. GTA) (6) also is not what I would consider Health - but there is a relation, as time limitations are also resource systems with the purpose of heightening tension and hence fiero. (7) is similar - but more interesting. Impossible Mission used this model - but set the time limit very high. You had literally hours of play, but lost (I think) 20 minutes when you died (as a new agent arrived on the scene). That was an inescapably brilliant idea for its day - because the second half of the game's play (after the platforming) was solving a puzzle which took perhaps 30-60 minutes to solve. I don't know that one could make this fly any more. Again, though, the underlying purpose was to build tension and therefore to deepen the payoff of fiero. (8) is just plain dumb in my humble opinion. :-D Misguided mimicry. (9) seems, as you suggest, to be a shuffled life system. Very arcade. (10) is something different to the other cases, though. This is another resource limitation, but with the goal of increasing difficulty. It may have the same effect - to enhance fiero - but it also affects the play, removing experimental play and forcing state space searches. Not my idea of fun. :)

It does seem that tension (excitement) and fiero are the key purposes of Health systems. Thanks for offering the list - it was an interesting set to explore!

Greg: I think you're correct that these moves are a product of increasing complexity in games... The question therefore remains, where next? Any ideas?

Jack (again): I really liked the timed penalties in SoTC for reasons you mention here, and I believe almost certainly that the boss you allude to was purposefully designed to be extremely frustrating - to give the player the experience of being tossed about like a straw doll. Frustrating, yes, but SoTC is all about invoking fiero, and heightening frustration has the potential (but not the guarantee) of enhancing fiero. If I had died fighting it, I would have been extremely annoyed; thankfully, we scraped through. I didn't get the fiero though. Just relief.

This is the gamble with fiero - if you keep the player engaged, the frustration pays off with fiero, but if you lose the player, the payoff is instead relief. This is nowhere near as satisfying. This, indeed, is the problem with bosses - they are only fun for a fiero-seeker.


Great set of comments - thanks for chipping in everyone! No-one seems to have a feeling as to where this may go in the future, but I guess that's not really a surprise. I suspect it will lead to more refined systems by some mechanism, but I remain curious as to how.

If, as it seems, Health is about excitement and fiero, one possible step is inverse exponential gradiations - i.e. suffer less damage the more beaten up you become (thus prolonging the tension). Does any game use this yet?

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment

Your Information

(Name is required. Email address will not be displayed with the comment.)