Why did Sam decide not to show the killing blow damage after all?

[piwakawaka]

Just a game design question really:

I recall a few videos ago @sampattuzzi decided not to show the damage delivered by the killing blow (by putting the call to takeDamage.Invoke(damage) only in the not-yet-dead side of the comparison in Health.TakeDamage()). At the time I wondered why, but now this subsection is complete I’d really like to understand the reasoning behind this game design decision.

Watching the video, when the enemy dies, and its health bar disappears, it’s pretty obvious that it died, but why wouldn’t a player want to know that they scored damage on the enemy? Imagine encountering an enemy that is only one hit away from death - if the player hits it, there’s no visual representation of any damage, even if it was a huge amount - they just die.

Just curious really - seems a little unusual to me so I’d like to understand why that decision was made.

[sampattuzzi]

I felt there was already too much going on on the screen and it made it too noisy.

[piwakawaka]

Fair enough, thank you for answering my question.

I received a bit of feedback for my own course project and some players felt that the lack of apparent damage on the killing blow, along with the immediately disappearing health bar, was a little strange and made the combat feel somewhat detached, as if the enemies we just falling aside. For what it’s worth, they preferred my own modification which showed the killing blow damage and kept the (now empty) enemy health bar on-screen for about half a second after the death animation. It seemed to help confirm the feel of a definite “kill” in their mind.

Either approach works

[sampattuzzi]

I think in my original prototype I might have had a death particle effect which made the choice more obvious.