Last week I hinted that timing animations was a bit of a pain, but fear not!
This week we've got that all worked out, so enemies can play perfectly timed attack animations.
Matching Art and Gameplay
From last week, we know that animations in pixel art games are just sequences of images displayed really quickly.
But if you've got an animation of an archer shooting a bow, how do you know when the animation is at the point where the game should "spawn" (create) the actual arrow that's getting shot out of the bow?
And how do you know where that arrow is supposed to be spawned, relative to the archer?
One answer is: you fiddle with the projectile's exact spawn time and spawn offset until things look okay - but there's a better way.
Animation Hotspots
We're already drawing each attack animation as a sequence of images.
And as we're drawing, it's pretty clear where & when each projectile is supposed to appear.
What if we just.. drew that information onto the animation images directly? 1
We can! We just say "hey game, when you see the bright pink (hot)spot, create the arrow there": 2
Now the game knows both the attack's timing (because the game knows when each frame of animation will be played) and the attack's location.
As a bonus, we can use this to solve other fiddly problems too - like positioning enemy eyes in the right place, or marking which bits of enemies (or players) can be hit by attacks.
Hotspot Tooling
Of course, we don't want to have those special hotspot pixels actually get shown, so I draw them in a special hidden layer.
And to make it easy to draw the right hotspots, I made a small extension: 3
Under the hood, the extension saves information like pink is attack and blue is eyes inside the animated image itself. 4
Putting It All Together
Now our enemies' attacks are in sync with their animations:
The implementation is still very basic overall - for example, each animation can only have one attack hotspot. But I figure I can improve that when I need more complicated attack patterns.
In Other News
I redid the news listing of the Slow Rush website to show a featured animation beside each weekly update.
It's pretty cool: you can scroll from top to bottom to see the progress each week.
I also finally took care of some legal things, like setting up a company and getting a privacy policy in place. 5
Playable web build
I also made the website's layout a fair bit wider, so that this playable demo has a lot more space:
I can't claim credit for this idea! I first saw it in an old cave-flyer game called Jetmen Revival that has you flying around ships and shooting bullets & rockets at a friend: it used hotspots in its ship designs for defining your thrust locations and where bullets should appear.
Noita also uses this approach, of course.
Technically I have the game calculate the bounding box of the hotspot pixels, because sometimes I want a box but other times I just want a single point (the center of the box).
My aseprite hotspot extension is published here if you want to use it.
As JSON-encoded data in the Sprite's userdata; my game reads the Aseprite file format directly so there's no export step needed.
Having the colors configurable per sprite also means that I can e.g. use bright pink as an actual colour in a sprite if I want to.
There isn't anything crazy in the privacy policy, but I did have it drafted broadly enough to allow me to collect things like gameplay analytics, gameplay recordings and crash log information in future - just because it's nice to know if anyone's actually playing the game demo, and to know where people are getting stuck, and it's especially nice to know if the game is crashing a whole bunch.
But if you read it and it makes you freak out for some reason then please shoot me an email about it.