Devlog - Pain and Suffering


At a loss for what to do next, I turned my attention towards the player "hurt" state. In this state, the player will take damage and be knocked away from the source of that damage. A little bit of extra clean-up is needed, but it largely works.
---

Pre-Damage Phase

Before the player can enter the "hurt state," they need to detect whether they've been hit by an enemy in the first place. Upon legal contact with a source of damage, the player will then enter a "pre-damage" phase. The core behavior of this script is:
  • Find the amount of damage dealt
  • Get direction of damage relative to the player's position
  • Determine if the player can be knocked back in their current state

After all of that, we can enter the the hurt state proper.



The Basics:

I believe I've successfully recreated the basics of the system, though some bugs might slip through. We have knockback and being stunned on ropes / stairs -- just like my old engine.
Both projects use different values for gravity, which means knockback isn't 100% accurate to what it was before. If I recall, the change in gravity is a difference of [ 0.3 ], which isn't a lot -- but it does result in the player jumping slightly higher than before, which does change things. I am continuing to fiddle with these numbers, however.
I'm also re-using my [scr_helper_player_jump_xmove] script to handle horizontal collisions, as if the player were jumping normally, allowing me to keep the hurt script much cleaner.
I've made a small edit to the start of that script, replacing all instances of [hsp] with a local [_spd] variable. Now, this variable will dynamically change between a jump's horizontal speed and a knockback's horizontal speed based on the current state before any calculations.
Now that we have a slide ability, I've also made sure to create a smaller hitbox for it.


Gameplay Tweak: Knockback Stun

Historically, players are knocked back when they take damage -- unless on rope / stairs, then they are simply stunned for a second or so. But I felt players regained control too quickly after a knockback (immediately), so I've added a minor stun effect to basic knockbacks too.
It's actually extremely quick (5 frames at 60fps), but it's enough to make the impact of being knocked back feel a bit more tangible, and looks less abrupt. The sprite origin point has also been adjusted so the animation looks a bit more natural. Both are very subtle improvements.
It's difficult to see, but there is a slight delay when the player hits the ground before they exit the hurt animation and are thus allowed to move. This delay is non-existent in the old demo.



New Feature: Crouch Stun Negates Knockback

Players can now crouch before taking damage to completely negate knockback. If they perform any actions while crouched, this effect will be removed (not yet implemented).
I'm uncertain about this feature, as it's not authentic to the classic CVs, but it was an obscure feature in a game most players don't care about (Dracula X - SNES). I like damage knockback and have no plans to remove it, but I think this adds an interesting variety to the toolkit while also softening a mechanic that might be a pain point for inexperienced players.
Although this feature makes the game easier, its benefit does not come for free. Players must trade the possibility of avoiding damage via using a risky dodge in exchange for tanking a hit & suffering guaranteed damage -- but without knockback as a trade-off. I don't know if this will ultimately affect the balance in a negative way, but I do think it's an interesting idea.



Feature: Damage Logic

In my previous engine, I used a "lookup table" for determining how much damage the player is supposed to take from any enemy contact. Here's how that goes:
  • Player touches enemy, triggering the Hurt State.
  • The Hurt State has damage values for every enemy (this requires I manually add them to this specific script every time I add a new enemy type to the game engine).
  • Player takes damage based on the value stored in that table within its own hurt script.

My new solution is to make damage inherent to the enemy instance itself (which does have potential problems if the event order isn't right). This also lets me change the enemy's dmg stat inside the room editor itself, so two zombies can have different stats. 
  • Player touches enemy.
  • Player looks at the specific enemy instance & saves its "dmg" value.
  • The Hurt state is triggered.
  • Player takes damage based on the value previously saved. 

Although the damage logic is still at an early stage, it works. My only concern is whether the game crashes if the enemy dies before the game can read the enemy's dmg value. But if I get that data early enough in the event order, it should be non-issue?
I've already performed some quick tests using the room editor to change an enemy instance's dmg, but without further testing, more varied enemies, and a proper health system, it's hard to say just how good it is in practice.

Ejection:

Although I hoped I wouldn't need to perform additional collision checks within the hurt state, I had to -- albeit very little. If players end up inside of [o_solid] for any reason, the hurt state will push the player out of the block before its conclusion.
It is unlikely players will get stuck inside of blocks during any other state, so hopefully I won't need to do this in any other logic. This could happen to players in the old engine, and if it was bad enough, the game would often (unintentionally) push the player down, resulting in death.


Don't forget to eat & sleep.