Time to finish up the arch-types of my primary mobs.

I present a Gyrobot, because I am totally running out of ideas (it’s literally a ball with a head):

I guess it’s a variation of movement — a “gyroscopic” ball (like in that one sci-fi movie). It’s slow to gain speed, but slides around. Not sure how it  will differ otherwise, but–again–a unique-ish visual. A different visual might be all I need for some of these…

But, no, that’s boring (P.S. the time between last sentence is 3 days later). I think I will add a new ability (that I can likely use for bosses later) — force shield. It’s kind of like cower, but it doesn’t “disable” the enemy while it’s active.

First of all, a new gyrobot-specific AI belief behaviour:

And a new desire to use the forceshield with similar condition to the cowering:

The two main new beliefs here are “forcefield active” and “forcefield available” — both reducing the desire to do the forceshield. One makes sure the enemy doesn’t try to activate it when it’s already active. The other stop the enemy trying to activate it when it cannot — out of charges or something.

I also need to define

I though I was going to add some sort of damage reduction, but I think I can just wire the mob to add some shields to itself when it activates the forceshield. In fact, I can just use the default shield value and only activate it for forceshield when the sprite is specified:

Finally, I need the mob world object to show the extra sprites:

And all of this works out nicely in-game:

The enemies were a bit slow to activate the forcefield when low on health, so I added more belief steps to make sure low-health enemies prioritize shields:

They can of course still fail to do so — and that’s fine. If the player focuses an enemy, they will likely kill it before they activate shields. If they however shoot a bunch of random mobs, they will all eventually trigger shields and make the fight harder (or at least longer). So this is sort of the opposite of how to deal with cower — the player wants to finish off mobs before they “pop shields”.

I played around with this a bit and I realize I should make my “forcefield” a more generic ability and have the actual shield be the mob shields. After all, I’m not really showing that mobs have shields yet. So why am I adding extra ability graphics when I haven’t even added regular ones?

First of all, I won’t have any sort of “active forcefield” — it will just be mob having any amount of shields.

And the values to define these amounts need to be separate:

And I can specify the actual sprites for every mob size (like drop shadows) for reusability:

And this all works a bit better. Now all mobs with shield can show the shield graphic. While a forcefield ability is just the mob adding a bunch of shields to itself, which automatically adds the shield.

Incidentally, this works for player too:

I will likely need to tweak this though and add some hit effects, but that’s for later.

 

And, finally, a Chargebot:

The idea is that this ones moves on tank threads, but can occasionally charge at the player…

But after thinking about it I really don’t want to implement charging (P.S. the time between last sentence is 6 days later). This is the sort of feature that will expand its tendrils into all the other features. My AI will need heavy adjusting for how these behave in melee. I will need proper charge damage, player push-back, etc. Not to mention making actual charging state and somehow linking it to the charge boss special. I will need to balance it all. In short, no charging.

Instead, I think I will rename the mob “Platebot” and make it a tanky bot that you have to damage a lot. I want it covered with shield plates:

In fact, the feature I want implemented is to have mob part animation that knows how to ask the mob itself whether to show a part. So if I make three parts:

Then I can select how and if each part should query the owner mob:

For editor preview, I also need to be able to toggle these triggers as a “virtual mob”:

I can then preview the mob with the right parts:

I want the mob to lose the parts as they take damage. To implement the actual logic, I need to specify for this mob type a rule of how to respond to animation toggle requests for part visibility:

And this works nicely, the mob loses its parts (it took 10 attempts to make the GIF, darn AIs running all over the place):

I also want the mobs to lose the parts in a random order. So I need to choose the part order when a mob is first created.

I also want a random death part to fall off whenever the mob loses a part (I need to stop calling everything “part”). For that I can add another rule for what to do when “approaching death”, broadly speaking. In this case, drop parts at same intervals as the visual parts get toggled:

And this works great — the enemy loses small bits as it takes damage:

Of course, I will need more effects for this. But these use the same death part logic, so I will be able to implement it there eventually and it will work for this as well.

This is very cool and I think I want another mob that has this. I think since I have a tanky mob, I need a flying one. So I will reuse the copterbot and just add some butt protection to it:

It is henceforth known as (flying) “Buttbot”.

I can then extent the above new logic switches for 2 parts instead of 3:

And have the bot lose the parts gradually:

They could even fly faster as they loose the “baggage”… but that’s just way more extra work than I do need to add to myself right now. Later, may be.

Well, that’s two more unique mobs and one extra with reuse. For a total of 10 semi-unique mobs:

I did “just” add extra features onto mobs that I can now reuse for other mobs. I will likely do a pass on all the mobs adding and reusing these, especially the part dropping. I am really running of viable fully-unique ideas otherwise. I mean, I have plenty of ideas, it’s just that most cannot be done easily. Besides, I need bosses too (first) and those need even more work than the regular mobs.

And I’ve been thinking about bosses in parallel. I think the bosses will have similar arch-types to these mobs. I might even go for the similar visuals. I really need to finalize this so I can have an art asset list that is at least somewhat representative of the final sprites. I might need to work on the bosses and finalizing art assets (which is sort of what I’m doing with placeholder finalization).

MicroRogue DevDiary #112 – Final enemy types
Tagged on:     

Leave a Reply

Your email address will not be published. Required fields are marked *