Let’s continue our case study of shooter bosses with one I made myself a while back. This fight below is a total mess for a number of reasons, not least of which being the total lack of even barebones production values. There’s basically no telegraphing for any attacks, the hands teleport to the attacking spot, and important visual information is often hidden by the player’s UI, or obstructed by another enemy or projectile.
There are also serious mechanical problems with this fight. In stage two there are stars spawn and shoot their own projectiles. A neat idea, and one worth exploring further, but this incarnation can be trivially avoided through circle strafing. The other boss attacks are a tiny bit better, but if you just mindlessly circle strafe you’ll avoid far more damage than if you try to actually engage with the boss as intended. This is partly due to the visual confusion, but mostly because this was made before I understood the importance of projectile leading.
Mecha-Greenblatt’s melee attacks are very mediocre. The first, where the boss slams the ground and projectiles come out, is essentially a glorified projectile attack. Underwhelming, but fine. The second, where the hands swipe in front of the boss, would need to be massively re-tuned just to be mildly threatening. The one saving grace is that the boss stops to do these attacks, allowing the player to manipulate his movement.
While the boss is overall a disaster, I can appreciate what I was going for with the dynamically overlapping attacks. For example, in the first stage the boss continuously shoots unaimed projectiles, couples those with tracking shots aimed to the side, and can be manipulated by getting close to him and triggering his melee attack. All these attacks are individually trivial to avoid, but the combination would theoretically force the player to pick their spots. In this case it doesn’t, because circle strafing and basic distance management trivializes the entire fight, but the germ of a good fight is here.
My latest boss experiment doesn’t expand upon these ideas directly, but this is a series so I’ll circle back to it later. Instead, I was focused on another solution to eliminate a problem where a boss can either be kept in hitstun forever, or doesn’t have any hitstun, which makes the fight far less dynamic. It’s a classic problem that plagues a ton of games. Here’s a JRPG I used to play as a kid with the same issue. It’s also got another issue, where if you kill one of the two or three bosses in a fight, the ones remaining are lame ducks, but I’ll talk about that in another piece.
A boss needs some way of being rescued from perpetual hitstun. In the previous experiment, I gave that boss auto-replenishing poise after he takes a certain amount of damage, and made him cast a spell, both of which combined to get the player off his back somewhat. This boss doesn’t get to escape hitstun himself, but he will have flecks of ooze drip off his body, which turn into other enemies, which effectively takes the pressure off him.
The idea works well for both gameplay, and even better for flavour. You get the mechanical/complexity benefit of fighting multiple enemies, while still feeling like you’re actually dueling the boss. Also, I’m sure I can come up with plenty of interesting ideas for a boss who sloughs off ziomass.
Getting the boss’ two attacks to work well together actually took more time. The short range practically undodgeable projectile is essentially a melee replacement, mostly because melee attacks are finnicky, and require a lot of careful animation. The laser was designed to sweep in front of the player and cut off their movement through the arena. It’s there so you always have to pay attention to the boss even if he’s far away.
The attacks themselves were pretty easy to implement, but the code switching/choosing between the two was not, as well as properly positioning so as to maximize the effectiveness of each attack. In the end, I stripped it all out. The boss now always moves towards the player and does the laser attack if he’s far away and anticipates the player popping out of cover shortly.
I have a lot more to say about this, but I’m saving it for the next article, as it’s quite late and I have a very early morning shift tomorrow.
