Time to make bosses awesome (more realistically, I’ll add some more framework for all mobs and special consideration for boss AI). Currently, my boss mobs are just enemies with larger sprites. And their AI wiring is exactly the same as regular enemies. In fact, they are in no way different to regular mobs except that the HUD displays their health bar when the player is close.
One thing I can do is make their sprites bigger so they feel “bossier”:
Of course, that just makes them a scaled version of other junkbots. What I need is to add more parts:
Except now I have to make dead mob prop parts for the mob so they can explode into bits when dying:
I don’t really want to be doing this for every single part. Instead, I will pass the animator and state info to the prop when the death setup creates it. I think at best I will have some props like “large part” or “small part”. But the parts will get shared across mob death setups:
Now, each of my death setup entries needs to recreate each part from the animation setup:
This is still stupid tedious. In fact, I can just use a common prop definition since they are all the “same”. And I can also use the same state animator’s name since they will come from that state anyway:
I can also make my forces and explosions automatic and simply (well, so to speak) use the parts position to decide which way it is going to explode and rotate. This makes my list of death setup entries pretty much just animator’s entry indices:
In other words, I can specify which parts to explode, but I don’t need to specify anything else on a per-entry basis. Anyway, this works fine:
(Making GIFs has become so hard now because all mobs running around all the time…)
But now I can add many boss parts and not worry about having to “animate” every part multiple times. I lose some individual control over the parts, but I don’t think anything I would do would be noticeable enough for gameplay to matter.
I am also pretty fed up with having to tweak all the numbers while enemies are running around, shooting, overlapping, having camera move, and just generally making it hard for me to adjust them as a static entity. So I made the animator setup preview show it in the editor (I already had the sprite drawing logic from room definition editors):
There’s no actual animation preview here yet, but I guess I’ll may be get to that at some point. So now I can do mob parts much easier and hopefully that takes a few steps towards making my bosses better. (But, oh man, does a small intention turn out to be a massive change.)
While testing the boss a bunch, I realized they don’t behave quite as I’d want them to. I need to change their AI to be more boss-like. But my enemy AI system is… complicated. It works great and can support some very organic gameplay. But it is also very parameter-intensive and–if I am to make a copy for the boss mob–well, this is the amount of things currently in it:
It’s not reasonable for me to make a copy of this for every single enemy. Not because I cannot make a 1000 assets, but because any change or problems I discover will require me to fix those 1000 assets. In other words, I am duplicating a lot of work and duplication is almost always bad — and definitely with this much content.
I think I will solve this by having a “template” AI belief/desire definition and then base all my individual ones on that template. By default the AI belief senser would use the template values, but they can be overridden. Firstly, I need the template asset (which is what my definition was) and I need the definition asset, which references the appropriate template:
Now, most of the work is just making an editor. In this case, I just “copy” it from the template — it’s the same structure as in the template that gets automatically populated and I’m just showing the template values. So I can show all the values (editing is disabled here as they come from the template and not definition):
However, the whole point of having this is so I can override the values, and I can implement that with an optional checkbox (blue – same value, green – higher value, red – lower value):
And this works at run-time as well, making my changes easy to test. It simply picks the value based on the toggle status. This means I can have unique versions for certain mobs, like the boss in this case:
I also want to be able to disable and enable certain behaviours. Which means I first need to be able to disable behaviours in the template and the belief senser:
And this works great for the base template. Now I can specify overrides for this (first checkbox – override; second – value: red – disabled active, green – enabled disabled, blue – unchanged):
So now I can make new desires and beliefs for enemies without necessarily affecting others. I can also disable desires and beliefs when enemies don’t need them. For example, the boss AI shouldn’t investigate disturbances or seek the player far away, but should return quickly to spawn instead and wait for the player to come back (basically, the player cannot “lure” them out). I can now encode that with a couple checkboxes and a couple changed numbers. (But, again, small intention — big change.)
Now how about some actual boss gameplay. What does that even mean? I guess there are several broadly stereotypical things bosses do (that I will definitely not implement right away):
- Have unique visuals. That’s what I have been doing at the start of this.
- Have special weapons. I would need to make something for the boss.
- Do special moves. This is complex and implies many new gameplay mechanics. But I can likely also reuse them for regular enemies. I’ll think of some abilities for this.
- Go through multiple phases. This would be specifying when the boss is allowed which move. I can likely just add it to the AI desires/beliefs.
- Have something unique. Now that’s the hard and time-consuming bit. If every boss has to have something that is truly unique to that boss.
One thing I can add is the health state belief (disabled by default for mobs) for firing at the player (as an example):
And I can add a bunch for different health levels:
And the boss gets the belief enabled and valued:
So, in this case, the boss with low health is more aggressive — fires at player more. And I could add something to other mobs too, like being more cowardly or something.
I should also add some new desires for boss special move (whatever they are) use:
And I need to have some default relevant beliefs to increase/reduce it:
And I can add health stuff here. So, theoretically, the boss can desire to use a special abilities. Speaking of which, they don’t exist yet. I can start by defining them (with a new asset, of course) that boss enemies can reference:
I think I will fix the number of abilities to 3 and build everything around this assumption. There can be less per mob (or none), but it’s at most three and all relevant selections only work up to three.
To actually have a mob perform a special ability, I need to create an “action state” for mobs, which described what they are currently doing in terms of actions that conflict each other. That is, firing and using a special are conflicting actions, while walking and firing are not. This makes sure that enemies, no matter what they want to do, can only do one thing at a time.
Then I can add beliefs that–theoretically–make the bosses use their abilities:
First ability is always desired. Second and third become active once the enemy goes below 2/3 and 1/3 health respectively. Having the ability unavailable removes the desire to (try to) use it. And this works, sort of:
Only issue is timing. I need to add both duration and cooldown to abilities, so they remain active for a while but also not get activated too often, even if the enemy wanted to:
After messing around with properties and various ways to trigger and check specials, this seems to work out okay, although I will need to playtest it a lot and tweak the numbers to make sense later.
Well, that’s the framework. For something content-intensive like boss abilities this isn’t too much work. I will need to adjust it more, but the main parts are there and everything else is basically implementing concrete abilities. I have a few ideas, but I need to think on it more and decide on the best ones in the gameplay variety and fun vs implementation time and difficulty.