Varied Pathfinding

  • Who is that in response to? Yes it would be but nobody suggested to do that.

    Sorry, it was to Laurent - they said:

    Just disable obstacles once path is calculated.

    Sequence is :

    • Activate random set of obstacle

    ** - regenerate obstacle map **

    • calculate path
    • deactivate set of obstacle
    • move along path

    In the manual it states that doing this is very CPU intensive

    Edited for clarification

  • Yeah don't do that. I was talking about creating obstacles to block paths so the player has to go a different way. You said you tried this, but you were walking through the obstacles. It's because the player cannot see them, you need to regenerate the obstacle path at the point of creating the obstacles. The player will then find a new path as the previous ways will be blocked.

  • Yeah don't do that. I was talking about creating obstacles to block paths so the player has to go a different way. You said you tried this, but you were walking through the obstacles. It's because the player cannot see them, you need to regenerate the obstacle path at the point of creating the obstacles. The player will then find a new path as the previous ways will be blocked.

    Ah, I think you've misunderstood - it's not the player who's pathfinding, it's an object, also I said the issue was that I don't want the player to be stuck on the obstacles when made solid for objects that pathfind

    I think you should check if you have added a Solid behavior to your obstacles and make sure Solids are assigned as obstacles in the Pathfinding behavior.

    The random numbers that are generated will determine witch obstacle's solid behavior will be turn from Inactive to Active.

    There is something you can do :

    - put obstacles on your stage

    - design different (let's say, 5) possible paths that are determined by a different combinaison of obstacles. Put the corresponding set of obstacles in different families named (for exemple) pathObstacle1, pathObstacle2, pathObstacle3...

    - for every moving object, before path is calculated, select a random family and put it as an obstacle in the Pathfinding behavior

    - calculate path

    Should be something like that :

    + System: For each MovingObject

    -> MovingObject: Add Pathfinding obstacle Obstacle(random(1,5))

    -> MovingObject: Find path to (targetx, targety)

    There is no way to add a random obstacle in Construct 2, you need to select a single family/object.

    I tried to work around it by assigning a variable to the moving object when it's created and having the path be set for the object depending on that variable, but that creates a myriad of issues...

    Here's what I've done:

    +System: On MovingObject Created

    ->MovingObject: Set path_number to round(random(1,6))

    +System: For each MovingObject

    ->MovingObject: On path_number = 1

    -->MovingObject: Add Pathfinding Obstacle: path_obstacles1

    -->MovingObject: Add Pathfinding Obstacle: tilemap_walls

    -->MovingObject: Regenerate Pathfinding Obstacle Map

    -->System: Wait 1 seconds

    -->MovingObject: Find path to (goal.x, goal.y)

    +System: For each MovingObject

    ->MovingObject: On path_number = 2

    -->MovingObject: Add Pathfinding Obstacle: path_obstacles2

    -->MovingObject: Add Pathfinding Obstacle: tilemap_walls

    -->MovingObject: Regenerate Pathfinding Obstacle Map

    -->System: Wait 1 seconds

    -->MovingObject: Find path to (goal.x, goal.y)

    etc.

    Any ideas on what I'm doing wrong?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • > Yeah don't do that. I was talking about creating obstacles to block paths so the player has to go a different way. You said you tried this, but you were walking through the obstacles. It's because the player cannot see them, you need to regenerate the obstacle path at the point of creating the obstacles. The player will then find a new path as the previous ways will be blocked.

    >

    Ah, I think you've misunderstood - it's not the player who's pathfinding, it's an object, also I said the issue was that I don't want the player to be stuck on the obstacles when made solid for objects that pathfind

    > I think you should check if you have added a Solid behavior to your obstacles and make sure Solids are assigned as obstacles in the Pathfinding behavior.

    > The random numbers that are generated will determine witch obstacle's solid behavior will be turn from Inactive to Active.

    >

    > There is something you can do :

    > - put obstacles on your stage

    > - design different (let's say, 5) possible paths that are determined by a different combinaison of obstacles. Put the corresponding set of obstacles in different families named (for exemple) pathObstacle1, pathObstacle2, pathObstacle3...

    > - for every moving object, before path is calculated, select a random family and put it as an obstacle in the Pathfinding behavior

    > - calculate path

    >

    > Should be something like that :

    > + System: For each MovingObject

    > -> MovingObject: Add Pathfinding obstacle Obstacle(random(1,5))

    > -> MovingObject: Find path to (targetx, targety)

    >

    There is no way to add a random obstacle in Construct 2, you need to select a single family/object.

    I tried to work around it by assigning a variable to the moving object when it's created and having the path be set for the object depending on that variable, but that creates a myriad of issues...

    Here's what I've done:

    +System: On MovingObject Created

    ->MovingObject: Set path_number to round(random(1,6))

    +System: For each MovingObject

    ->MovingObject: On path_number = 1

    -->MovingObject: Add Pathfinding Obstacle: path_obstacles1

    -->MovingObject: Add Pathfinding Obstacle: tilemap_walls

    -->MovingObject: Regenerate Pathfinding Obstacle Map

    -->System: Wait 1 seconds

    -->MovingObject: Find path to (goal.x, goal.y)

    +System: For each MovingObject

    ->MovingObject: On path_number = 2

    -->MovingObject: Add Pathfinding Obstacle: path_obstacles2

    -->MovingObject: Add Pathfinding Obstacle: tilemap_walls

    -->MovingObject: Regenerate Pathfinding Obstacle Map

    -->System: Wait 1 seconds

    -->MovingObject: Find path to (goal.x, goal.y)

    etc.

    Any ideas on what I'm doing wrong?

    And it works ?

  • Doesn't work for me... Here's what happens:

    When the first MovingObject spawns it is assigned (for example) path_number = 1 and moves along the path beautifully.

    However, a second later when another MovingObject spawns and is assigned the same path_number (path_number = 1), it moves along the path slowly and doesn't turn as sharply - it seems to me that it's continuously finding a path, moving, finding a path, moving, finding a path, moving etc.

    If any MovingObject spawns and is assigned with a path_number that isn't the same as the one previously spawned, they will all stop moving. This is infuriating to me :// These are the only events that influence the MovingObject so there's no conflict...

  • Could you post your capx ?

  • It is continually finding paths, you need to take out the 'for each'. I have some experience with this when I tried making a theme park game with pathing guests . It's better to just say if moving object var is this then find a path.

  • Would it help to have another approach entirely?

    https://www.dropbox.com/s/96purzfhhs4j7 ... .capx?dl=1

    It's rough in almost every way, but it's at least similar to what you're after?

    I can be made faster by using an array instead of the node sprites for the pathfinding grid, although it may be a bit more complicated. The net gain is the units would be able to see what direction to move with a array lookup instead of a collision check.

    If you want to use behaviors then the physics behavior can do a lot of it. It looks pretty good.

    https://www.dropbox.com/s/d6w816e483q2w ... .capx?dl=1

    To vary the path a bit more you maybe could use a perlin noise function to alter the forces on the units. Or maybe have a random force that you change periodically to each unit.

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