I’ve been saving up a list of various combat and related feedback improvements. That is, feature mostly nice-to-have and quality of life than actual hard features. Of course, most have some sort of framework underneath.
When enemies die in the game, they just change their internal mob state to “dead”. I don’t like this, because they are still mob entities with all the other rules applied. And the more rules I apply, the more exception I need to make. At some point the consistency of keeping them as the same entity doesn’t pay off. So this is a good excuse chance for me to work on enemy deaths and related stuff. (They would still have a breif dying state, but it’s fast enough that it’s not a problem if it’s not 100% consistent.)
First, I’m introducing a prop that is for enemy corpses and each enemy gets their own definition (or shares with others as applicable):
And I’m removing any direct sprite references from mob definitions and having them use their animator setup asset for defining sprites:
The basic states and a single sprite is as far as I will go for now with this framework, because this depends on the art style, direction, assets, etc. and I have not decided on this yet. I will expand this later. But the principle works and I can look up the right sprites:
Also my enemies die on a hard-coded timer, so I can add that as well as a proper parameter:
Shooting an enemy sends it through death “animation” and then seamlessly transforms them into a prop:
One issue is that they lose their weapon, since they don’t drop it. I don’t want to despawn anything in the level — any dead enemies, items, decals, explosions, etc — everything stays until the player leaves. It’s super-important for me to keep a persistent world. So they drop the weapon same as the player does — rotated, offset, with a small force.
Also I want to apply some extra death kick (based on the projectile that finishes a mob):
So now that enemies drop their weapons, I briefly tried marking enemy weapon (items) as not something the player can pick up:
I also tried adding a weapon “priority” for picking them up, so that way the player won’t pick up some shoddy enemy pistol over an actual good weapon next to it.
But after some testing I decided not to actually do it this way. If the player wants an inferior weapon, let them pick it up like all the other guns. After all, this is a roguelite and being able to consistently interact with stuff is one of my unsaid goals. Having some hidden weapon priority-based queue or needing to have UI is just against my immediate design goals.
Still, choosing a weapon to pick is a little trickier than just grabbing the closest weapon, because I need to be able to pick up every weapon around even if it means picking every other first. I need to keep an internal list of weapons that are in range and add/remove items to it in a queue. So, let’s say there are three weapons in range the player approaches (pick-up range here is greatly exaggerated):
As they approach the weapons, the shotgun will be the first in range and then the machine gun, then the pistol:
Even if the player moves, all the weapons in range remain in the same order:
If they pick up a weapon — the top weapon in the list (shotgun), then the remaining ones move up in the list.
Watching the screenshot, this is not very obvious. I don’t want additional UI for this (yet). But I need some sort of indicator when a weapon is in range to be picked up. I think I can do this with an item outline, for which I am using a sprite (may be I will have a shader later) for now:
And this works fine:
(I could even not tell the player anything about the weapon and let them experiment organically. There isn’t any item in the game or immediate plans that’s completely unintuitive.)
But I also need to show if the weapon will be picked up next. I think simply fading all the other outlines will do fine:
Probably a snap-change of the outline color is fine. But I hate abrupt changes, so I’m adding a fading animation:
It is subtle and the GIF doesn’t really show it, but it feels much better in-game (it’s very noticeable when it is gone, which has been a running theme with most of my gradual transitions).
There is one issue with this though: outlines in combat:
It is too much extra visual noise that I don’t think I want in the middle of combat. I’m not sure if I can do anything about it now. I would need some very good art direction and exclusive color use to telegraph clearly the intention of each item and highlight. I guess I’ll revisit this at some later point.
For now, I want to see if I extend my entity animation “system” (more like helper class) to props. A chest and its opening animation is a perfect candidate:
So that way the prop can just reference the relevant animator it wants:
Of course, now all my props need an animator. Chests (open/close) can share the animator. The dead mob can also share the animator, in fact, they can share the mob animator and just use another state with the specified state:
Now I can add an internal state to the prop and transforming props can us their transformation properties to decide what to do:
And this works out nicely:
Another nice-to-have feature is to make my mob hit indicators fade gradually. I am, in fact, doing so many of these, I am starting to make debuggable modular helper classes to handle various conceptually simple, but implementation-wise somewhat complex features:
And then my actual hit controller only needs to pass the parameters and not worry about internal timings or states or any resolution between them:
And it works nicely:
It’s almost impossible to see in the GIF, because it’s deliberately very subtle. I can also use this logic for the HUD blinkers and any other place that will need “blinking”.
Since I’m doing visual things, I might as well fix the entity visuals. Their sprites are currently are not exactly aligned to their coordinates:
Blue line is the sprite edge, green line is where the sprite’s graphics mob’s “legs” are, and yellow is where the actual center is. So it should be more like this:
This also makes my incorrect wall collisions obvious:
So I need a custom collision distance to walls (which is not the same for other mobs). And more to that, I need different X and Y distances due to the game’s “weird” visuals:
Man, those tiny improvements sure take a whole lot of time. Days pass and I can’t even confidently say “I did X”. I still have so many things I want to do and so many features I want to add. But I guess I have to focus on getting the main pipeline finished and playable. And get some art…