This week, I added some enemies to kill, so watch out! The enemies might.. err.. well, they can't move or shoot yet so they're not super threatening.
Still, you can kill them with (two of your three) spells! So you could say they're target practice.
Drawing images
You might think that drawing sprites (images) is key to a game, but we've gotten this far without them: the player is drawn programmatically as a few shapes, and the level's "tiles" (reusable square images) are actually atoms of different colors which get loaded from an image initially, but are actually getting drawn pixel-by-pixel.
But now we can draw (and hot reload on change) sprites from Aseprite:
There's no support for controlling which sprites get drawn on top of others (I have to draw things in the right order), it can't do animation yet and there's no performance optimization 1 - ain't nobody got time for any of that.
Health Bars
To kill enemies, enemies need to have some concept of health.
But you know who also needs health? Players!
Each player is backed by a body of atoms under the hood, which are already accumulating damage:
I made a shiny new health component (in the ECS sense), and now all damage to bodies of atoms get transferred to the matching health component.
That ticks off the most important feature request so far:
The health bars on screen are a bit busy visually so I probably won't go that way long term (e.g. Magicka, Noita and Wizard of Legend all do floating damage numbers), but health bars were easy to implement for now.
A Deadly Foe
With health bars and sprite drawing implemented, I added a deadly foe:
Only the actual target portion of the target (i.e. not my hastily-drawn hay bale) can be hit with spells, as that's the only portion that's actually backed by atoms. 2
Collisions
Both players and enemies are backed by "kinematic" moving bodies - which is to say, the rigid body physics engine doesn't control them directly, and it's up to me to move them.
That also means that if a player runs into an enemy, nothing happens - they can't move through each other, but they also don't push each other away, so it just feels like you get stuck.
To fix that, I made players be able to run through/past enemies (and other players too, while I was at it) - I think that makes more sense than trying to work out whether enemies should push players or vice versa.
Target practice web build
Here, see whether you can actually hit some of the targets using your acid spell.
Reminder: press Q for acid lob and Left Shift for flame thrower (and see all controls by pressing F1).
Okay, Acid Lob's arc is a bit too high for actually hitting enemies easily (and/or the payoff for hitting an enemy is too low), but I'll tweak that at some point in the future.
Next up, we'll see if I can make some enemies move, and maybe even attack!
A proper implementation would also support culling (skipping sprites off-screen), draw batching (asking the graphics card to draw multiple instances of the same sprite), and texture atlases (copying sprite images into one image so draw batching can be used to draw different sprites). But if I'm going to use another engine for that stuff then hopefully that engine will take care of it!
In fact, if you look closely (and/or play with the F2 debug options), you can see the wood atoms peeking out from under the target portion.