Slow Rush Studios logo,
    depicting an apprehensive-looking snail rushing forward

Slow Rush Studios

◂  Architectural Questions
News index
Pew Pew Pew  ▸

Target Practice

Contents

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:

Is my live editing improving this Spawn Point? It's hard to say.

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:

Secretly, each player is currently made of wood atoms.

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:

Your friends are now flammable.

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:

Act quickly, or else the target might just stand there on its own for a bit longer.

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).

Click to focus, then play with keyboard and mouse. No mobile support! Give feedback.

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!


1

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!

2

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.

◂  Architectural Questions
News index
Pew Pew Pew  ▸