I don't know how much to include in the updates here, so I'll just treat this as an abridged blog. Maybe someone will find value in a meandering dev's thought process, someone can yell at me for doing something silly, or if nothing else I can sanity-check myself to make sure I'm on the right path by explaining my train of thought.
The list I gave above will need to be reordered, but the first item is probably the best to start regardless since enemy logic is broad. I say "logic" instead of attacking since I'm changing my approach. Before, I was using a very basic mob class and slapping an attack function on it. The attack function just checked if a player was within a line and ran a damage check on them. That's silly, shallow for gameplay, and would introduce a lot of redundant checks further in development. I realized it could be better.
Now, the base enemy class checks five zones (two are mirrored sets) for the player on each designated "awareness" frame.
Per diagram in order of priority, (1) does not mirror, and is for determining if the player is above the enemy (so they can do things like dodge an expected downthrow or thrust upwards). (2) detects incoming players and signals to use some range-centric attack. (3) both determines if there is ground adjacent to the enemy for possible dodges, and/or performs some close-range action when the player is near enough WITH a height cap (to allow players to do things like divebomb enemies). The actual actions taken and distance for each check can vary, but this is the general design philosophy that I'd like to follow when writing how each enemy handles which zone. Heck, if can even be used for bosses.
To debug this, I tested by making an enemy "hop" whenever the player enters one of its ranges, height-dependent on the zone. This is so stupid looking that I'm keeping it in the game and using it somewhere.
(All of these are placeholder sprites lol. Also on the to-do list, find a decent way to capture screens without making the game fullscreen.)
In accordance with this, I'm holding off on make a general "damage" prefab since this should be handled as an attack with any visual flare added in the sprite. This also crosses off edge-detection, so it's really just a matter of standardizing the hurtbox generation.
Up next, I'd like to do the movement restrictions and "grab" refinement.