Pathfinding behaviour and overlapping instances

1 favourites
  • 10 posts
From the Asset Store
Units do not overlap each other and use different ways if there are several free ways.
  • There are some instances with pathfinding behaviour, they are overlapping when they move. Is there a way to solve this?

  • Have you seen the new "Path Groups" in the Path Finder?

    Link: https://editor.construct.net/#open=pathfinding-groups

    Example:

    Without "Path Groups":

    Here is how it will look normaly when a group of objects tries to find a path, they will all overlap.

    And with the new "Path Groups"

    They will try to find an alternative paths so they dont overlap much

  • Thanks brother for your reply. I tried the one you shared but still there is some of them is overlapping. Is there a way to get a result like objects not overlapping solid

  • Thanks brother for your reply. I tried the one you shared but still there is some of them is overlapping. Is there a way to get a result like objects not overlapping solid

    To avoid overlaps with each other completely is not an easy task. This is an incredibly difficult problem as it quickly becomes highly CPU intensive and chaotic if you dont know how to manage everything that's going on, and is easy to end up with objects getting permanently stuck, for example, pushing each other and not finding a way out, or some pushing others against a wall which they cant end up permanently stuck on that wall. I have tried in the past just a mini test for fun and I quickly recognised how much work and how many edge cases you have to count for.

    This is gonna be case per case, depending on how complex is your project you will try one way or the other and keep adjusting and identifying edge cases.

    The simplest way to start is by using Timers:

    For each Object: call Timer ---------Set Time = (0.5 * loopindex) or something like that and on timer find a path.

    The push-out of solids:

    Can be a bit junky sometimes when they push out each other as they can fly from one place to the other so you can try and see.

    There is not one solution to fit all, it all depends on the project and how perfect you want it to be.

    The smoothes I have seen today that the objects dont (fly or get stuck often) is by using Physics which was done by "R0J0hound", so if you dont mind using physics for everything like (Solids & Movement) then you can give it a try.

    I can't remember the link but do a quick search on his name you will be able to find it.

  • My scenario is, when player shoot, by hearing that sound some enemies will find the path to the player's area, they will search there. Like the android game Hunter Assasin. But my issue is when they move along path enemy instances are overlapping each other. Not sure how to solve this.

    I've an another thought in my mind but not sure whether it will work or not. Pathfinding can be use for just to find the path but movement is doing via other behaviour by using the found path. Is that possible?

  • My scenario is, when player shoot, by hearing that sound some enemies will find the path to the player's area, they will search there. Like the android game Hunter Assasin. But my issue is when they move along path enemy instances are overlapping each other. Not sure how to solve this.

    Have you checked the Physics example from R0J0hound that I mentioned in my last post?

    Because I checked the "Hunter Assasin" and that is exactly what you looking for, as if you press attention to the enemies in that game to avoid overlap they slightly push each other and that is what Rojoh does in their examples.

    I've an another thought in my mind but not sure whether it will work or not. Pathfinding can be use for just to find the path but movement is doing via other behaviour by using the found path. Is that possible?

    Yes, you can definitely use it with any Behaviour, you just have to save in a variable the waypoints generated from the Pathfinder then every time you reach a waypoint you will target the next one by (Waipointindex+1). My preferred behaviour for most types of movement is "MoveTo" You even have the Pathfinder integrated with it.

    Though if you didn't fix the overlap issue with the Pathfinder not sure how using other behaviours will help you.

  • I don’t think I’ve made a complete example of that.

    Using the physics behavior with the path finding behavior kind of solves that. But it can be janky because the two behaviors fight with how the objects move. It’s slightly improved by setting the physics velocities to 0 every frame, but the behaviors are still at odds.

    To remove the fight you’d ideally just use the physics behavior to move, and not use the pathfinder for movement, although you would use it for finding the path. Basically you’d set the velocity to velocity+(targetVelocity-velocity)/10. Where target velocity is the velocity you’d want to go toward the next waypoint on the path. The /10 is to make it smoother, but isn’t frame rate independent as is. Then you’d just need to check if a waypoint was hit or no so it would move on the the next waypoint.

    The main issues here are not being able to reach a waypoint so it could cause things to get stuck.

    There is also a technique called steering behaviors (not actual C3 behaviors) or boids that I think could be useful here. The math above is basically steering, it changes the velocity till it’s facing a certain direction and velocity. Basically you’d find the paths, or since it’s many objects to one spot you could use dijkstra's algorithm to get kind of a flow field. Then you’d steer the enemies to move along the path, away from each other and walls, and in the average direction the enemies around them are going. A last step would be the physics to keep things from overlapping as a last ditch effort. Lighter than the physics behavior is one technique called verlet physics which has the benefit of inferring velocity from the previous position which could be useful here.

    To handle a high volume of objects using some kind of grid spacial partitioning would reduce the number of collision checks.

    In theory the enemy’s would the flow around the terrain while not overlapping each other.

    Anyways that’s just few rough ideas. Might attempt it later and see how much simpler an actual example would be.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I don’t think I’ve made a complete example of that.

    Using the physics behavior with the path finding behavior kind of solves that. But it can be janky because the two behaviors fight with how the objects move. It’s slightly improved by setting the physics velocities to 0 every frame, but the behaviors are still at odds.

    What I meant is to use the whole system you created, Pathfinder including:

    Here is one of the examples I'm referring to, it comes already with the pathfinding

    https://www.dropbox.com/s/79rd7hoyig86hmv/R0J0hound_pathfind_test_physics.capx?dl=0

  • Oh nice. I forgot about that one.

  • Just quick clarification to not cause any confusion to you guys:))

    The two questions were unrelated questions to me so I treat them separately:

    For the first:

    My scenario is, when player shoot, by hearing that sound some enemies will find the path to the player's area, they will search there. Like the android game Hunter Assasin. But my issue is when they move along path enemy instances are overlapping each other. Not sure how to solve this.

    I recommended using the Rojoh example I posted above which uses Physics

    For the Second:

    I've an another thought in my mind but not sure whether it will work or not. Pathfinding can be use for just to find the path but movement is doing via other behaviour by using the found path. Is that possible?

    It is just a general question about if you can use the official pathfinder with other behaviours, so I said yes storing the nodes and using them as waypoints.

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