On my journey through creating myself a 2D scroller, in the Terraria genre, I've started updating my basic AI a little. Since I've decided against pathfinding, I am currently using a very basic, "move towards player position" for hostile mobs. I've spiced it up with some basic abilities to jump over obstacles, within a certain height, and also jumping over holes if they are too deep to jump into, and aren't too wide.

This approach does end up with many situations where the mob will get stuck in doing the same thing like trying to jump over an obstacle, but because there's some tiles above it, it can't jump over it and stuff like that. It will quickly turn into a lot of code if I have to take everything into account, so instead I decided to look at how Terraria did it. So I took a look at how Terraria zombies work (haven't tested on other mobs) and, apart from being a bit more smooth in their movement, there are certain situations, like mine, where they just keep doing the same thing over and over. In Terraria however, the zombies will, after a short while, simply leave. They turn around and walk away, until they're offscreen or the player attacks them.
I would like to mimic this behavior. But I am trying to think up a smart way to do this. So far I've considered the following:
- Over the course of a few seconds, check a few times if the mobs position is the same, or within a very short range (for cases where the mob moves back and forth because it's on top of you, but with solid tiles between you).
- Make a small list of the mobs movement and compare all the elements, and check if the same position is passed multiple times.

So my question is:
Are there any better ways than the ones I've described above? - and if so,what should I do?

Thank you for reading.

Part of your object data should be 'what did I do last time' and a repeat counter.

Depending on all the possible actions only the ones that can fail endlessly need be candidates - it sounded like movement was the chief one ? Its always expected to keep moving towards the player? If it fails to move, its stuck?

If a 'mob's behavior is to kill the player - moving towards and maybe firing - the firing I would guess could be just repeated as it often misses normally or takes alot of shots to kill so there is no real 'stuck' for it.


If its always expected to keep moving towards the player then when its coordinates stay the same after each Move attempt that is an obvious sign of failure (getting stuck).

To test for that :

each successful move you save the new coordinates position(x y)
for each movement attempt test the new coordinates against that saved position
if it did not change then it failed

if it failed you can try to do some other tactic (go around or retreat or whatever)

OR if its failed action has a probability of succeeding and you want it to retry
you increment a counter
if the counter reaches a threshold number great enough to say "its tried enough of that - time to try something else"
if counter isnt reached that limit then wait for next turn to try again

Remember to reset that counter every successful move (and initialize it at 0 on object creation)

The save XY coordinates should be initialized (on object creation) to some outside map value so that the first iteration will never possibly be seen as a repeat.

-

If there are more than one action that can be retried like that, then you also have to save the action (some ordinal representing it) when you fail so that you can be sure what action was previously failing repeatedly

you would test after each failure as before except first check if the current action is the same as that saved action value
if its the same then its a repeat. if its different then this failed action was different and would be a start of a new repeat sequence (you would reset the counter at this point and save the current action save value -- as this would now be the first of doing that current action.


As long as your game uses fairly simple logic a system like above can work well enough. Its up to you to decide how many repeats should be attempted before giving up on that action and switching to some contingency.

----------------------------

I reread your description which may have your objects jumping about a little and not simply stopping' when they get stuck.

If the 'stuck' movement keeps them in the same small area (some radius) you may be able to do a radius (or box test) every time you move and build an averaged position as it repeats - eventually deciding that its 'stuck' and now time to try something else.

The problem is how far is far enough(outside the radius) to tell that the object is moving successfully, making progress towards its target (versus just bouncing around a little area when 'stuck'. You may have to find that out by observation depending on your movement mechanics.

A counter could keep track of how many samples (each subsequent attempt) was within a 'failed to move' radius value)
when it fails the counter is incremented and the current XY would be averaged together with the saved coordinates (centering it automatically)
[a running average would improve the centering]

if you step far enough from that center then you succeed and you reset the tracking (XY, counter) data

When the counter reaches enough retries (your threshold) then time to do something else (remmember to reset counter etc...)

Hey there, thanks for your reply.

Your post was really informative, and I'm glad I wasn't totally off in my way of thinking.
I think I will go with your last suggestion, since that should cover all the possible "stuck situations".

You actually covered this so well that I should be able to jump right into it. So thanks a lot for your reply, and for taking your time to explain things