[Journal] Making 'Stretcher' - AI (Pixiv Fanbox)

Continues from the last journal.

Let's imagine this kind of monster's placed on the map, and player needs to get pass over it. It has large hitbox, and doesn't move while it's getting attacked. I'll be too easy to handle this monster.

I want to make more difficult, want to make it to be hit only when player attacks its 'core'. The core will move along with its slime part.

I've wrote a code for 'follower behaviour' long time ago. It wrote that code to make sphere to move smoothly, having some delay.

This code I have makes object to follow the destination, regardless how extreme its change is.

If we assign proper destination for the core along with the monsters movement, we can get a nice result.

In game, when monsters gettting hit, they generally display their status by changing their color to white. but as this '???' basically invincible except its core part, we can't use that method.

Instead, we can slightly modifity the bounce effect we already have. then we can express if its hit or not, seperated from the 'health reduced' effect.

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓

┃ Boring part begins from now on. For the gist, just watching the images would ┃

┃ be enough. other followed sentences are just for the clarifications. ┃

┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

- AI part.

The monster need to decide its destination by its own. There's two options to we can choose to implement this AI function. First is to give it a speed, and make it move until it meets the wall. Second is to calculate the destination before it moves, just like we see stuffs and think before we grab actually them.

First method is far more easy and lighter than the second one. but sadily we can't use the first method, as situations like these will happen :

If we don't manage its destination, there will be occasion where it lands on absurd position. So we need to calculate which position is valid and which is not.

And even validity checking is not enough, as situation like below can also be count as invalid.

If this kind of occasion is checked as invalid, monster won't attack the protagonist and we don't want that to happen. We need to check if it's 'adjustable' than mere validity.

There's lots of occasions to check when it comes to adjustment. There might be even more that I've missed.

But all these occasions can be handled with one condition.

=> If parallelogram contatins retangles edge(s), the edges that makes the line which has the differnt gradient sign compared to parallelogram, adjust parallelogram according to it. Else, consider it as invalid.

But that's the solution for only one platform to consider. If there's two or more platforms, there will be a problem.

Once parallelogram adjusted, it's adjusted very tightly. so if it gets adjuested again to opposite direction, we can assume that It's not valid. same applies to other types of adjustments.

Other 'possibly can go wrong' parts can be handled by doing another checking routine repeatedly.

So with all of these, if we stitches up these requirement nicely, we can finally have disred result. we can make it run by its own.

It's really been a long journey, but now everything is done(except some bugs). It'll be able to be seen in the game soon. Merging it with the game will definately be a struggle, but I think It won't be that bad :3