The Droid Rammer
The “Rammer” was my first departure from creating enemies with drifty asteroid-physics: I wanted to create something with a semblance of AI (and aggression!), possibly to act as a final challenge of the game in its present state.
Up until this point, I’d been using a white silhouette version of enemy sprites for the “hurt flash”, but I wanted the little thruster modules on the Rammer to get blown off as it moved through its increasingly distressed visual states – that meant a different silhouette, which would mean a “hurt flash” sprite at each state, which would mean bespoke programming, and which would ultimately discourage me from doing fancy things like this in the future.
So, instead, I found lifted a solution involving direct calls to GameMaker’s shader interface, allowing me do flashes that would fade more gently, and also eliminate the need for specific “hurt flash” sprites for everything. Hoozah.
In terms of Rammer’s AI, I programmed this as a lot of if-then-elses with some variables to keep track of what the rammer was currently doing (ramping up, ramming, resting). I later found that this was an ideal candidate for a state-machine and should loop back someday to refactor it.
2021-10-13 10:23 PM Today, I switched to using shaders rather than “hurt” sprites for flashing frames when enemy objects take hits, mainly so that my droid_rammer wouldn’t look weird blinking when some of its bits had been blown off. Pleasingly, I’ve incorporated a very subtle fade effect to the flash, so it’s a big win (in addition to me not needing to worry about all those extra sprites).
In the evening, I programmed in the ramming behaviour and it worked like a charm! It’s fabulous! Very happy.
I’ve created an animation curve to make the ramming speed drop off more precipitously and smoothly at the end—I just need to figure out how to incorporate it. But, rammer boss is built! What fun!