Last week, I started implementing a biped enemy, someone who should be able to match the player character blow for blow. For now, I’m using a variant of the player sprite for prototyping this enemy, but the final design will probably be something altogether different, as I’m trying to avoid humanoid elements in my enemy designs.
In prototyping this design, it became immediately obvious that freezing this enemy in place when taking damage feels wrong. I first added that behavior when I was implementing the green slime baddies in order to more closely mimic Zelda II‘s Bits and Bots. But in that game, the larger, stronger bipedal enemies that Link encounters do not freeze when hit. Instead, they reel backwards, putting themselves out of melee range and increasing the complexity of combat encounters.
As I was basing this enemy’s movement on the player’s own, it made sense to give it the same amount of knockback when damaged as the player experiences. This has been historically been hardcoded in player code, however, and that raised the question of what should really own these values and how they should be modified in the context of wanting to support a variety of weapons, armor, upgrades, champion enemies, and so on.
Previously, in all cases but the player taking damage from being touched by enemies, the weapon was the thing that would define these values (knockback force and decay rate, in addition to amount of damage inflicted). The thing being hit could only choose to opt out of knockback entirely by freezing in place when stunned from a hit.
The weapon is still the source of these values, but there are now opportunities in code for both the weapon’s owner and the target to alter or override them. In this manner, the biped enemy can choose to ignore whatever amount of knockback the weapon wants to administer by default and use a value that suits its needs better.
In this future, this path will likely serve as the basis for features like weapon and armor upgrades, allowing the player to scale down the amount of incoming damage from enemies or scale up the amount of outgoing damage from weapons.
I’ve tried to provide as much information as possible that could be useful in determining how to adjust damage and knockback values, but it’s likely I’ll want even more as time goes on. I currently identify the thing immediately responsible for causing damage (for instance, a melee weapon or projectile), the owner of that thing, if different (typically the player or an autonomous enemy), the target entity (the one taking damage), and an arbitrary damage type name which is currently unused but may be useful in the future for distinguishing physical blade or blunt damage from elemental types like fire or electricity, if I choose to have those. Additional information such as what equipment the context entities are wearing can be looked up from their handles if necessary.
It’s likely too that this model will evolve between Gunmetal Arcadia Zero and Gunmetal Arcadia to adapt to the larger scope of the roguelike game. For now, I’m focusing on content production for Zero, and for that game, the current implementation will likely get me most of the way there.
This weekend, I’ll be at Retropalooza in Arlington showing off Super Win the Game for probably the last time this year. Come say hi if you’re local-ish!
Next week will be just about one year to the day since I started keeping this devlog, and next Thursday is the one-year launchiversary of Super Win, so I’m going to do a bit of a postmortem or recap on each. Let me know if there’s anything specific you’re interested in reading about!