Log inDevlog: Backflip Adjustments & Weakness
A relatively small update, but with some notable changes. Mostly tweaks to older features.
Adjustments - Backflip:
I introduced Rondo of Blood-style backflips some time ago, but felt they were "too good."
Previously, it felt too effortless to perform a string of backflips in quick succession, providing way too much mobility for a game of this nature. Due to the lack of any recovery animation, a player could perform the action immediately after landing. As a result, backflips would quickly become a "meta" tool of traversal -- thus reducing the value of walking, sliding, and jumping.
Here's a showcase of the old backflip behavior:
So, I have since made two adjustments to how backflipping works:
- Players can now backflip during the first frames of the Falling state (ONLY after jumping), essentially making the window for execution wider, and thus easier.
- After landing, players enter a 25-frame recovery period during which they cannot regain control as their momentum pushes them across the floor.
As of right now, it's still a good tool for movement / skill expression that can be a "speedrun strat", since you don't lose much time -- but there's just enough friction in the recovery that I hope discourages frequent spamming. I'll continue to experiment to gauge my feelings.
Adjustments: Damage Calculation
I have finally implemented the "Plant" enemy, which hides in the grass until players approach. The enemy logic has also received several improvements:
- Plant enemies can now function when placed on ceilings & walls.
- Navigating around them is easier thanks to an updated hitbox and new player movement mechanics, such as backflips & sliding.
However, I noticed an issue: Plant enemies required two whip hits to defeat, but three hits from the razor boomerang. This is because the Plant has 7 HP -- the whip deals 4 damage per hit, while the boomerang deals 3 damage per hit (since it can strike again on its return trip - thus an expected max of 6 total damage).
Although mathematically sound, this feels unintuitive because players may otherwise expect the razor boomerang to sever the stationary Plant's tentacles and instantly kill it.
There is also an unintended interaction where standing inside the enemy allows a single whip hit to kill it. These two behaviors feel wrong, both in terms of design and experience.
So I had to adjust how damage calculation worked, though I did so in very minor ways.
Damage Weaknesses:
Although I never intended to implement a resistance system, as that is a feature of the much more complex Igavania titles, such an inclusion felt appropriate here.
I DO NOT want to universally increase the boomerang's damage, since it is already strong. But, this really is an enemy I expected to kill quickly with this weapon (and firebombs too). The solution was to introduce a system that allows certain weapons to deal more (or less) damage against specific enemy types -- a simple weakness system.
Every enemy has two new variables:
- weakness_
- weakness_multiplier_
Both are arrays that function as a matching set and must contain the same number of values. The first array defines the specific weapon object, while the second defines the damage multiplier applied to that weapon in the matching "array slot."
Thus, the boomerang's base damage (3) can now be multiplied by 3 for this specific enemy, allowing it to deal 9 damage per hit and defeat the plant in a single hit. All other enemies will continue to receive the boomerang's base damage, unless they have their own multiplier. Pretty simple and clean!
Of course, I could also make the boomerang weaker on some enemies -- like an armored knight, who would instead take more damage from a piercing weapon... Like a dagger.
Single Hit / Multi Hit:
As a result of how the new engine handles weapon hit boxes, melee weapons create a new hit box every frame of their attack animation instead of updating a single hit box across the whole animation. For example, the whip's first frame creates a hit box behind the player, with each subsequent frame spawning a new hit box further along the swing.
This introduced an unintended issue: if the player is already overlapping an enemy, multiple hit boxes can connect during the same attack, causing damage to be dealt more than once. Which is conceptually cool, but not when it's unplanned.
To solve this, I added a "single hit" variable to player weapons. When enabled, the enemy will remember that this specific weapon instance last damaged it, and all subsequent hit boxes created by this instance (identified by its unique instance ID, not its object type), are ignored, requiring a new attack before that weapon can deal damage again.
It's a simple solution, but keeps changes to the older calculation code as minimal as possible.
-
-
Don't forget to eat & sleep.
