When you play old games, especially platformers, a common "special effect" is rapid blinking of your character when they are hit. Also, enemies often blinked before dying. Not all games did this, but it was very common, to the point in practically became a trope, and today many games that aim for the "pixelart" look also emulate this.

To me, this effect has always seemed quite jarring, like the system is kinda malfunctioning; or is being forced to do what it's not supposed to do, and this is a side-effect.

So, why was this so widespread? Was it simply because it was easier to do than anything else (and, you know, limited hardware of the day), or was it something else?

  • 47
    Death is jarring! If it made you feel uncomfortable, perhaps that was good UX. ;) Commented Sep 2, 2019 at 9:48
  • 4
    Also, isn't seeing flashes of light an actually common, real physical reaction to being severely injured, impacted, electrocuted or irradiated? Commented Sep 2, 2019 at 13:07
  • 3
    In addition to what others said, I can think of just practical reasons - it was hard to ensure styling is applied (like - colors) to stuff in-game simply because some devices were black and white. Blinking is the easiest and most robust solution in such cases as it guarantees to be working so long as the device can output the original text/image.
    – Alma Do
    Commented Sep 2, 2019 at 14:11
  • 2
    It should be pointed out that blinking is still used in some current racing games after a "reset" to indicate collision is off for a few seconds after the "reset".
    – rcgldr
    Commented Sep 2, 2019 at 19:22
  • 7
    Character blinking usually shows a window of invulnerability IIRC, not damage.
    – enkryptor
    Commented Sep 3, 2019 at 15:03

7 Answers 7


So, why was this so widespread? Was it simply because it was easier to do than anything else (and, you know, limited hardware of the day),

Exactly that. To make a sprite blink, all you've got to do is to set it to be not displayed and then displayed again. Usually by just writing a single register or pointer or setting a flag to skip drawing it. No additional sprites (for dying or whatsoever) needed and especially no complex (*1) animation code to be developed and added. All of that would have not only required additional effort, but code space and certain functionalities, both which may have been quite restricted on early systems (think Atari 2600).

And yes, as you noticed, it was already these very very early, limited game systems that coined the trope of blinking being usually some badness indicator - like losing a life. So with that topic set, it was just natural for later games, on more capable machines to still go the same way.

Of course it was used for other effects as well, like invulnerability, in which case dying did need a different visualisation.

*1 - Complex as in relative to environment and time. Doing even simple animation on a system with restricted RAM/ROM can be challenging. Squeezing another sprite into a 2 KiB Atari 2600 game-ROM might be impossible, even if it's 'just' about a few dozen bytes for the definition and handling.

  • 7
    There's a reason they used 2 digit years instead of 4. That 2 bytes was worth saving back then. If they did that with 2 digits, think what they will do with a 2 KiB sprite...
    – Nelson
    Commented Sep 3, 2019 at 1:30
  • 13
    And if you want something more advanced than on-off blinking, you can use palette swaps to do flashing colors. Also very cheap. Commented Sep 3, 2019 at 6:59
  • 7
    @Nelson 2 digit year is actually just one byte
    – Cubic
    Commented Sep 3, 2019 at 15:44
  • 4
    @Cubic, no, a two-digit year is two columns on the punch card.
    – Mark
    Commented Sep 4, 2019 at 0:19
  • 1
    @Raffzahn yep, my brain has escaped somewhere :)
    – OrangeDog
    Commented Sep 4, 2019 at 21:42

In addition to the other answer and comments, a character would often enjoy a brief period of invulnerability after sustaining damage — this period was indicated with the character blinking. The blinking effect here helps suggest an ethereal state where you can’t suffer more physical damage.

  • Some very poor games doesn't have this invisibility period, and often this leads to bugs where it's very easy to get a de-facto OHKO.
    – Bregalad
    Commented Sep 10, 2019 at 15:05

Because it was an acceptable way to show damage

Remember who's playing these games. Primarily it was children. Games back then were entirely aimed at children (or at least young people). With that in mind, some way of showing damage without graphic imagery became necessary.

As a counter-example, consider Barbarian which had more graphic depictions of violence which included blood and decapitation. As Raffzahn correctly says, earlier games simply didn't have the ability to do this with sprites, but later games became more sophisticated, and of course newer computers could manage more. The outcry at the time was incredible. It's notable that no future home-computer games continued with this for some time after.

A number of years later, Mortal Kombat appeared in the arcades with more graphic violence. Earlier games like Pit-Fighter had started to use more realistic rotoscoped characters, but still did not include visible damage or blood. Mortal Kombat again provoked a significant outcry. Not long after that, Wolfenstein and Doom emerged on home computers as the start of the first-person shooter genre, and the outcry over them was immense and is still ongoing, with claims that they allow people to "rehearse" mass murder.

  • 4
    At first sight I read "and of course newer computers could carnage more". Commented Sep 3, 2019 at 2:07
  • 2
    @A.I.Breveleri Would that be a Freudian slap?
    – Graham
    Commented Sep 3, 2019 at 9:05

Why do old games use flashing as means of showing damage?
... Not all games did this, but it was very common, to the point in practically became a trope, and today many games that aim for the "pixelart" look also emulate this.

Games were of a limited resolution, it would be very difficult to show a little piece missing to indicate damage. There needed to be light, sound, and often a gauge, bar, or number to indicate gains and losses.

It wasn't as though if the player piece had a recognizable face that you would be able to see sweat or tears (unless they were comically huge), or an unhappy face (unless the player was essentially a smiley).

Some games, such as ones with Mario or Pac-Man, used no flashing for damage or death.

There were a limit to what could be portrayed and how it could be shown, both from a technological and creative point of view. It far more of a trope that video game deaths are prolonged.

The website TVTropes describes the effect as "flash of pain" and that it's a simple palette swap or turning on and off of the sprite that is easy to do (uses minimal CPU cycles).

The website Giant Bomb has a page explaining "Damage Flash" and a list of 128 games (probably incomplete) of where flashes are used to indicate that one is taking damage.

They claim that the video game "Laplace no ma" (1987) was the first to use flashes (video) to show damage. Earlier games "Pac-Man" (1980) used flashing to draw attention to something, and dying was animated (video) (damage not being part of the game, it was live or die).

The game called Mad Crasher (1984), also listed on the Giant Bomb website, used flashing (video) to indicate that shield was being applied or lost.

Flashing (and other sounds or screen shaking) are simple to do from a hardware standpoint (and easy on the very limited CPU cycles per second that were available) but were used to indicate a number of things besides damage or dying.


From an UX stand of point, the blinking of the Player character when it takes damage it's both the cheapest way and the best way to inform the human player that it took damage.

Imagine what happens if you have a Player character that walks up, down, left/right and also jumps, fires melee and ranged weapons and has a bunch of other states.

Say the player is walking down:

Player walking down

Then it takes damage, while walking down:

Player waling down - taking damage

That is an entirely different sprite and animation (say 3 to 6 frames). This is expensive, it has to be done for all the Player states that have a visual representation.

Also the animation takes precious time. If you're playing a platformer or an adventure game where your reflexes matter, you, as a human player will be frustrated with the outcome of waiting for the animation to finish rendering (let's say 3 frames, 16ms / frame, that is 48ms +input lag, it's 50ms of waiting time).

If the player was jumping while getting hurt, that means you also need four JUMP_GET_HURT animations (up, down, left/right).

As a game developer, this is expensive both art-wise and developer wise as oppose to just applying a mask (as suggested in the other answers).

This answer may not apply to NPCs, because from a player POV, you like seeing them getting hurt, you enjoy getting feedback from your action but not some much vice-versa.


Just wanted to add my 2 cents.

Making the enemy blink upon damaging them was/is an effective way of informing the player that the enemy took damage.

I remember plenty of times seeing my weapon "strike" the enemy but the lack of blink let me know that my attack failed without needing to constantly check if the enemy's HP bar decreased.


Was it simply because it was easier to do than anything else (and, you know, limited hardware of the day), or was it something else?

Yes, it was fast!

For example, in EGA mode 0Dh or VGA mode 13h with a resolution of 320x200 pixels each color value was indexed by using a a palette. EGA allowed 16 different colors at the same time out of 2^6 bits = 64 colors and VGA allowed 256 colors out of 2^18 bits = 262144 different colors.

So instead of redrawing each pixel of the 3d surface of a destroyed enemy all the time, you redraw it only once with another entry of the palette and then you could simple change that one entry's value in the palette to have a flashing effect on the that 3d surface of the destroyed enemy.

Because this was very fast, many games used that technique.

To give some examples take a look at the following DOS Games:

  • M1 Tank Platoon
  • Gunship 2000
  • F-19 Stealth Fighter
  • F-15 Strike Eagle II
  • F-117A Nighthawk Stealth Fighter 2.0
  • EGA in 320x200 mode 0Dh did not support any 16 colours out of 64. Maybe clone monitors or cards but not original IBM EGA monitors and thus not IBM EGA cards. On VGA you could of course select the 16 colours using any method you want. When in 350-line EGA mode 10h, the IBM EGA monitor and thus the IBM EGA card allows selecting the 16 colours freely from the available 64 colours.
    – Justme
    Commented Dec 31, 2023 at 21:38
  • That's strange. I just run F-19 in EGA 320x200 mode in DOSBox to test what you said. I destroyed a building to see how the surface of it changed. It was flickering with red and yellow and this surface even still flickered, when the simulation was paused. According to Wikipedia's EGA article that seems to be related to the monitor. In this WP artcile it is stated that all 200 lines modes will be interpreted as CGA by the monitor. But there are some switchable EGA monitors that will allow the use of the full palette.
    – Coder
    Commented Jan 2 at 19:37
  • This flickering effect could of course also be simulated by re-rendering, but that wouldn't be as efficient.
    – Coder
    Commented Jan 2 at 19:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .