[Behavior]PathFinder

  • edit: nevermind, I'm convinced it's just the behaviour that can't perform at reasonable speed for my task.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Kyatric, there is a bug. If you enclose the Sprite into a box of walls and click outside of that box, the Sprite will jump into the top left corner of the layout.

    This bug will only happen on the first click of the mouse but if you click inside where it's movement for the Sprite, the bug won't happen if you click outside of the enclosed box.

    Are you working on this bug or knows of it's existence?

  • : I'm not working at all on the PF for now and have no knowledge about this bug.

    Could you provide a capx with repro steps please ?

  • Kyatric actually, I found a fix for it. When the user first clicks anywhere where the Sprite is surrounded by obstacles, it bugged out and sent it to position 0, 0. Just disabled the added coding I put in there and see for yourself. I'm using Chrome as my browser.

    To fix it, I added IF statements if the PathFinder couldn't generate a correct path, I set the destination to the Sprite's x&y and set moving to False.

    http://dl.dropbox.com/u/69588589/MovObj_PF_r7523523.capx

  • yumarod3: I can't get the file it's asking me to signup or login.

    Try to upload it on dropbox, it's far fairer to share files.

  • I updated the link into Dropbox :)

  • yumarod3: Ok I saw it.

    It's a "bug" in the moving example, not the plugin itself.

    That's also why the conditions "On path generated" and "on path failed" exist, so that the developper handle the behavior of their application according to the result of the generation.

    If there's no path, there's no need for the object to be set to moving.

    Anyway the examples are provided as it, as an illustration of how to use the PF.

    They need to be adapted for each usage, not be simply ripped of.

    You found yourself a possible implementation with the branch plugin, as I said earlier, you could simply use the "on path generation" conditions. In one case setting the move variable to 1 as expected and to 0 in the other case.

    The PF itself only deals with finding/generating a path.

    The movement is up to the developper as there could be thousands of ways and expectations on how should the object move.

    BTW I believe there were automated movement behaviors that were released since the first release of the PF that could handle the movement easier, it needs a bit of browsing in the plugins list I think.

  • Yann

    Hi Yann, thanks for the great example you've provided! I understand some of it, but I don't quite get the following action:

    Lerp(Sprite.PathFinder.getCtXPathList(max(0,floor(iteration)-1)),Sprite.PathFinder.getCtXPathList(floor(iteration)),iteration-floor(iteration))

    Would you mind breaking it down for me? Sorry I might need the dumbed down explanation :)

  • Basically, once the path is generated, the list of coordinate to go through is stored in an array you can query via getCtXPathList(n) and getCtYPathList(n), n is just the index of the cells listed. It goes from 0 (starting cell) to the the number of cell to travel-1 (the last cell).

    But it's just coordinates, if you simply read the array and change the position of the sprite accordingly, you will have a stepped movement.

    Lerp(a,b,t) = a + (b-a) * t

    so basically if t evolve from 0 to 1 you get a nice interpolation from a to b.

    Here I use lerp() to go from index n (a) to index n+1 (b) in the array.

    The global variable iteration simply count time since the start of the interpolation.

    t = iteration-floor(iteration) means that I only keep the decimal part.

    t = 5.2 - floor(5.2) = 5.2-5 = 0.2

    So for example, if you are at iteration = 5.5 seconds

    You will get something like

    Lerp(getCtXPathList(4),getCtXPathList(5),0.5)

    Which means you'll be halfway between the X coordinate at n=4 and n=5.

    Which also means that if you choose the cut corner option, you'll go faster in diagonal than in orthogonal movements.

    This formula can be enhanced by taking into account the distance. But it should be handle at the 'iteration' incrementation. With something like

    set length to distance(getCtXPathList(max(0,floor(iteration)-1)),getCtYPathList(max(0,floor(iteration)-1)),getCtXPathList(floor(iteration)),getCtYPathList(floor(iteration)))
    set iteration to (length > 0) ? dt*Speed/length : 0[/code:27m508yq]
    
    Well, as there was still some mistake in my capx, I updated it with these new formula and some comments.
    And I added a debug text you can set to visible to see how some of the values evolve.
    
    [url=https://app.box.com/s/zo7vfwjpnz4j6g80rajp]kyat-PF.capx[/url]
  • It'd be a good idea to figure out the equation for having the sprite follow a already moving object. I'm trying to make a pac-man like game to sort of play around with this, and I'm beginning to wonder how I can get the sprite to follow the player. IS there a post I missed that has the equation for it?

  • TheOMP: there is an element listed in the how do I FAQ : Compagnon that follows the player - LINK

    Maybe that helps ?

  • Not exactly what I was looking for but it might help regardless. I'm was thinking more of generating a path that leads to the player's last position and making the enemy follow that path.

  • It's possible to use it with moveto behavior? tried but got error

  • Guif0DA:

    You probably want something more like A* and pathfinding. 00Rez came up with a really sweet couple of plugins that can work in conjunction with one another to do what you're hoping. You can find them here in the Rez Repo topic. You can even find an example of using Rex's moveto in conjunction with the pathfinding behavior and A* plugin. Pretty cool stuff.

    Quoted from the moveto behavior's topic.

    I haven't tried it myself, but if there's already a provided example, it sounds like 00Rez's solution might be more suited to your needs.

    I guess with my plugin, the iteration solution stands, iterating through the path's array, sending the next step's coordinates to the moveto behavior, and rely on a "on destination" trigger to iterate the next step.

  • Guif0DA:

    > You probably want something more like A* and pathfinding. 00Rez came up with a really sweet couple of plugins that can work in conjunction with one another to do what you're hoping. You can find them here in the Rez Repo topic. You can even find an example of using Rex's moveto in conjunction with the pathfinding behavior and A* plugin. Pretty cool stuff.

    Quoted from the moveto behavior's topic.

    I haven't tried it myself, but if there's already a provided example, it sounds like 00Rez's solution might be more suited to your needs.

    I guess with my plugin, the iteration solution stands, iterating through the path's array, sending the next step's coordinates to the moveto behavior, and rely on a "on destination" trigger to iterate the next step.

    Thanks for reply!

    I would like to use your pathfinding than the one from REZ, your seems more complex, with more actions and expressions.

    The example that uses moveto uses the pathfinding from REZ..

    But I will try again to make it work and see if this time the game doesn't crash.

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