CombatBeginner

Invulnerability Flicker

The classic post-hit blink — the character strobes in and out to say 'you can't be hurt right now'.

combatdamagei-framessprite

Examples

Captured from this page's own interactive demo below.

Overview

After taking a hit, most action games grant a second of invulnerability so one mistake doesn't chain into three. The flicker is that second made visible: the character blinks in and out at a steady rate, and every player since the NES era reads it instantly — I'm hurt, I'm briefly safe, I should reposition NOW. It's a status effect communicated with zero UI.

The blink is a square wave, not a fade: visible, gone, visible, gone, at somewhere between 8 and 15 toggles per second. Slower reads as a rendering glitch; much faster fuses into semi-transparency and loses the urgency. The final flicker should end on 'visible', and the rate can accelerate near the end as a wordless timer — Mega Man taught everyone that trick.

The visual must match the rules exactly. If the sprite flickers, hits MUST pass through harmlessly, and the moment the flicker stops, vulnerability is back. Any drift between the two — invulnerability outlasting the blink, or a hit landing mid-flicker — is read by the player as the game lying, and trust in every other signal erodes with it.

Interactive Demo

vulnerable — a hit starts the flicker

I-Frames1200ms

Blink Rate10Hz

Use Cases

Post-hit invulnerability in platformersRespawn protection in arena gamesDodge-roll i-frames made visiblePowerup grace periods running out

Best Practices

Do

✓Toggle visibility hard on/off at 8–15 Hz — a square wave, not an alpha fade.
✓Bind the flicker and the invulnerability to the same timer so the visual can never lie.
✓End on 'visible', and consider speeding the blink up in the last quarter as a built-in countdown.

Don't

✕Don't drive the blink from frame count — at 30 vs 144 fps the same code flickers at wildly different speeds; use time.
✕Don't let the character blink out during a boss's big telegraph — the player needs to see their own position to dodge.
✕Don't reuse the exact same flicker for damage and for powerups; one pattern must mean one thing.

Common Mistakes

⚠Invulnerability lasting 1.5s while the flicker runs 1.0s — the player eats a 'safe' hit and calls it a bug (they're right).
⚠Flickering by toggling the GameObject active state, which also disables the collider, physics, and running coroutines.
⚠A flicker so fast it renders as 50% alpha on high-refresh monitors, silently deleting the effect for those players.

Implementation

Paste this into your AI assistant (Cursor, Copilot, Claude) to add the effect to your project.

Prompt

Add the "Invulnerability Flicker" game-feel effect to my project: The classic post-hit blink — the character strobes in and out to say 'you can't be hurt right now'.

How it works: After taking a hit, most action games grant a second of invulnerability so one mistake doesn't chain into three. The flicker is that second made visible: the character blinks in and out at a steady rate, and every player since the NES era reads it instantly — I'm hurt, I'm briefly safe, I should reposition NOW. It's a status effect communicated with zero UI.

Guidelines:
- Toggle visibility hard on/off at 8–15 Hz — a square wave, not an alpha fade.
- Bind the flicker and the invulnerability to the same timer so the visual can never lie.
- End on 'visible', and consider speeding the blink up in the last quarter as a built-in countdown.

Avoid:
- Don't drive the blink from frame count — at 30 vs 144 fps the same code flickers at wildly different speeds; use time.
- Don't let the character blink out during a boss's big telegraph — the player needs to see their own position to dodge.
- Don't reuse the exact same flicker for damage and for powerups; one pattern must mean one thing.

Implement the effect in whatever engine/stack the project already uses and follow its existing code style. Wire it up where it makes sense.