boss struggles

12 Jan, 2026

久しぶりだな…

So.

Counting from when I started painting the sprites for it, it has been more or less a year since I started working on the stage 1 endboss for ProjEx. It's not done yet.

Okay, it's almost done. Honest! Right now I'm elbows deep in animation, which is admittedly a fancy word for "make this thing explode, then make a lot of booms, shower the screen with metal shards, and oh god so fcking done with this shit". Realistically it's just an hour or two left, and then maybe another few rounds of playtesting though it's more or less where I want it to be.

And also what happens when the boss timer runs out (dw it's lenient, unless you have the lowest gun power, and even then it should be doable). I mean, it's game over, but gotta put it in the procedures.

Of course, the question is, why did this boss take me basically more than everything else combined. Well, for one thing, I didn't work on it all year long. Two-ish months went to the gamejam game, which was fun, actually worthwhile, and I will probably go back to it once alpha/demo of ProjEx is out. Reworks, more levels, more stuff, who knows? Then, a lot of time went into refactors and bug squashing. Things are hopefully better organized now (better, not good...). I went back and forth on some gameplay things. I wrote procs that automate a lot of things I had to do by hand.

But still, a lot of time. There's no denying I had some sort of burnout going through October, and November, and September, and August, and May, and um. Yeah. But then again, it's not like I wasn't working on the game. I just wasn't doing it in the editor. The thing was, I had to strike some sort of balance between the vision in my imagination (yes, I do have one, despite evidence to the contrary), and what I can draw, what I can put into code, and, crucially, what would be fun. So even on the days I didn't work on the game, the conceptual engine kept on churining. Concepts ablated, abandoned, revisited, cut apart and stitched together, but differently (or not!).

For instance, the OG pitch I sent to DSA when I asked him for boss music (it's great!) was a high speed duel during atmospheric reentry, with time pressure of beating the boss before you burn up or crash into the ground. But that turned out to be infeasible; I could never make a believable reentry burn effect. At least not for at least a few years. Then I wanted a classic R-Type battleship raid style fight - during stage 1 this boss would at least once appear from above to rain some bullets and missiles, only to float away after some time, in a gameplay bit rip- inspired equal parts by Walker and Solaris 104. But I also wanted it to be a bit more dynamic than just going around a huge, static sprite, shooting bits off as they appear. So I wanted phase 2 and 3 be from the top, rather than from the side. But I couldn't draw a reasonably good rotation. So I invented a starfield effect to convey the idea while the boss conveniently slides offscreen for a moment.

Then, in phase 2, I had an idea for what's termed internally as panic mode - below a certain threshold main gun of the phase fires more frequently, but shorter bursts. The idea is that the internals are failing and the thing gets pushed to unsafe limits. But, after cooking up all the assets, and a neat spark effect, the concept did not stand up to funtesting. The result was rather headache inducing from frequent blasts, and annoying to deal with. So I scrapped most of it, only leaving frequent sparks/discharges as a visual cue that it's almost done. Related to that, I decided to rework my hit-flash effect, which was previously done by overbright (modulate = Color(10.0,10.0,10.0), i.e. multiplying each color component by 10), which had some major flaws if things were too high or low in base value. Eventually, I had a shader effect doing a nice processing on each pixel, averaging it with pure white. But that was frustrating too as I wanted to do more with shaders but hit roadblocks from either godot or shaders themselves, usually both.

More things happend and un-happened (and sometimes, re-happened as I went back and forth). I think I do have solid things going on there, but will probably know for sure from player feedback (if my own boss keeps kicking my ass, delaying testing of things further down the line, is that good or bad?). I keep making embarassing mistakes, such as mixing rotation and rotation_degrees in code and then trying to figure out what the hell.

Probably the last real roadblock I hit was related to the final phase. In this phase, there are two shuttered launch pads that periodically open and dispense a dumb shooting drone (see SWIV title screen / part 1 boss). The issue is making those things actually slide out from the "inside" of the launch pad. For days I was messing about with Z-levels and how Godot decides draw order, which is not always very clear when you add things dynamically. It could maybe be sorted by making everything Z absolute and keeping mental track of what goes where but jesus h. christ - and as I was trying to set things arbitrarily, each change fixed one thing and broke two more. At some point I had parts going at Z=500, which was getting ridiculous so I went back to square one - instead of trusting things to sort themselves, maybe I could code up a solution? Godot, unfortunately, has no easy way to fetch an object's Z-level, which seems kinda like a major oversight, but googling revealed a good enough recursive algo. So I just had the boss' body be at Z=0 (relative), interactive bits at Z=1, the shutters at Z=3, and armor at Z=4. Then, whenever it was time to spawn a drone, it would get set at [shutter's absolute Z] minus one. And it works, so it's a jerb well done, homestar.

And oh yeah, the intro now has a real spinning 3D Coco-cube instead of a fake spinning sprite, which took some work in blender, and was very educational (I now know how to slap 3D objects onto 2D scenes, yay).


Cats come with RGB preinstalled

#dev