Pathfinding with a large mob

This forum is currently in read-only mode.
From the Asset Store
Units do not overlap each other and use different ways if there are several free ways.
  • I started to experiment with the ghost shooter demo and RTS object to try and figure out the best way to move my large groups of enemies.

    enemies are really simple,slow and small (only about 32x32 or so), and they need to only know where the player is and how to get to him. So obviously i encountered performance issues, since im using alot of enemies. about over a 100-150 (i really want to try and push the envelope here, so its prob going to increase)on screen at once. first tests tanked my cpu when i put all the enemies constantly trying to find player location. i realize this isnt the proper way of doing it. second, i tried something like trigger once and everything was smooth. but this raised a new problem:

    what if the player moves and changes the position?

    that raised alot of questions again. i started thinking that maybe i could find something really simple, not cpu intensive pathfinding.

    i came up with the idea to make a single dummy object for a large group of enemies, make the dummy handle its way to the player by using RTS object and make the enemies as simple, rough physics objects, constantly adding force to the dummy objects position and when they are close enough and have line of sight to player, add force towards him instead.

    i havent tried this(or any other alternative) yet, and i wanted to ask if anyone else have been struggling with a large number of AI pathfinding or is the RTS object pretty much the way to go? or perhaps someone has even found a great cost effective solution?

    i know physics object is cpu intensive too, but it sounds tempting cause it gives great collision options and reaction to force and such.

    i could really use any kind of guiding on this matter.

    thanks.

  • Here is something you can do to make your program a little less CPU intensive:

    1 - When a target is found, set a couple variables to store the targets X and Y.

    2 - If the target is outside the attack distance of the object with the PF behavior, run the PF behavior to get the original path.

    3 - Every second (or any time length you feel works best with your setup) check the targets position against the oiginal X and Y to see if a new path needs to be found (set an acceptable margin of error so if the target is say 10 pixels away from the origin, it still counts as in the origin)

    4 - If the target has moved far enough, run these steps over again.

    This will keep the PF behavior from triggering every tick and allow your characters to each find their own path.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • hello and thank you for replying.

    i actually tried something along the lines of what you described last night. one thing that i couldnt really get to work is that number 3 - the margin of error, i dont quite know how to do that. do you mean it like:

    store the last known position to variables (XY) and then compare it to current position? how does that look as a code with the margin of error?

    second thing that came to mind is still the collision, ive read that the RTS behaviour doesnt like solids,so im kind of confused how exactly would i need to tackle this. would it be best to give each enemy a dummy sprite in container with collision( i would very much like if they collided with each other, instead of overlapping)?. although i feel the collisions wouldnt have to be pixel perfect at all, just some kind of rough implementation would do just fine.

    anyway, thanks for your time!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)