Pathfinding Implementation suggestion

Discussion in 'Ideas and Suggestions' started by Occam's Razer, Feb 22, 2015.

  1. Occam's Razer

    Occam's Razer
    Expand Collapse

    Joined:
    Aug 7, 2013
    Messages:
    1,267
    I'll admit I'm no expert at coding, only having ever gotten my feet wet with a little bit of Python here and there. But I do think I may have a good (if flawed and likely temporary) solution for implementing AI pathfinding in BeamNG. Whether the devs wish to consider/ have considered this, or if some enterprising community member would like to try this out, I don't have any patent on this idea.

    The entire system would revolve around a custom form of Path Node, an editor-based, -generated, and -modified object. Each node would contain:

    • A user-generated list. This would contain the names or level IDs of all other path nodes that are accessible from this point. It would allow for additional variables to be added, to allow for more potential paths from this point (or subtracted, for fewer).
    • A radius variable. This would define how close a vehicle must come to this node to move on in the path.
    • A speed variable. This would be the advised speed (in whichever unit of measure Beam uses) that the vehicle should go.
    The path node would be invisible and intangible, by the way.

    The way that this would be implemented into chase AI is to:
    1. Define the target. Beam's AI already currently does this, of course.
    2. Determine whether there are any path nodes closer than the target. If there are, move on to #3, if not, pretty much just do what the attack AI currently does: drive straight at 'em. Same if there aren't any Path Nodes in the level anyway.
    3. From here, it's pretty much an A* pathfinding system. Take the closest accessible nodes, and their accessible nodes, and their accessible nodes, etc. until you find the target. Measure distances, add up how far each path is, and select the shortest. Do this every couple seconds just to remain updated.
    4. If you get within the current node's radius, repeat #3 again and point your nose toward the next node. If you've passed the current node somehow, and are closer to the next node, just skip the current and move on to the next.
    For race AI, the race track nodes would likely be assembled into a single-file chain, with each node leading to only one other node, so having the AI simply follow the node chain would be the most advisable method.

    Traffic could be created by just defining the paths as single-file one-way paths along the lanes of the road. Intersections could be handled by simply choosing from among the available options randomly.


    Advantages:

    Well, firstly, it's an extremely simple system code-wise. It would not be particularly costly in terms of computing power and should be a reasonably easy task for an experienced programmer. It would cost practically nothing in levels wherein path nodes are either unnecessary or not included. The editor-based system allows large amounts of user control without having to modify the source AI (if you want them to smash into walls or fall off of cliffs, that's up to you), and makes it easier to define one-way paths in relation to navigation meshes or splines, in theory.


    Disadvantages:

    Well, it does take it out on the level designer quite a bit. Many nodes may need to be placed and defined to properly flesh out smooth curves. The system also fails to account for multiple parallel paths (having multiple cars traveling side-by-side, which a navigation mesh would be better equipped to handle), or inter-vehicle detection and collision avoidance. In its current form, the setup would also not account for the effects of steering; i.e. whether a path is really shorter when you account for the time taken to turn around, or whether a vehicle can clear a sharp corner at the node's advised straight-line speed (if it's an intersection).
     
    #1 Occam's Razer, Feb 22, 2015
    Last edited: Feb 23, 2015
  2. kruleworld

    kruleworld
    Expand Collapse

    Joined:
    Aug 24, 2013
    Messages:
    180
    it's good to keep this sort of thing on the burner while devs think about implementing it. Assetto corsa uses a spline object to define the path that the AI follow, and they also use it to define where the track cameras are located.


    (imported from here)
     
  3. Occam's Razer

    Occam's Razer
    Expand Collapse

    Joined:
    Aug 7, 2013
    Messages:
    1,267
    Don't worry; I have no illusions of this feature's urgency. I'm not saying it's something they need to pressingly implement within the next week or else I'll blow up something important. If some form of AI pathfinding works its way into Beam within the next 10-14 months, I'll be pleasantly surprised. I'm just speculating about implementation, and/or giving modders an idea as to how this sort of system *could* work.

    That would certainly be the better option for long, winding roads and race tracks. Easier for the level designer to build, and with smoother results on the NPCs' part. I somewhat question its application for car chases, but I know the devs would rather/sooner have good race AI than chase AI.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice