Author
Topic: Path Finding (Read 30007 times)

Version 2.0 - Released April 16, 2008. It now creates significantly less lag, and there is also an option to set a maximum amount of iterations to reduce lag at the cost of occasional failure to find a path. You are also able to force a path through call script as well as through a move event, for use in other scripts

Version 1.0 - Released April 11, 2008

Planned Future Versions

Version 3.0 - Will look into developing an algorithm that works faster and more efficiently. Allow for recalculation en route if original path is interfered with. Will not force a route in move path and allow for recalculating path instead.

Description

This script finds the shortest path from an event's current position to a target position specified by the user. It then sets that path into action. Be careful when using it though. Depending on the layout of the map, it can take a fair amount of time to calculate. So, don't use it for any huge, funky mazes or anything.

Features

No more looking at the map and setting a move route command by command. It only takes one command now to go from any square on the map to any other

Very easy to set a new path

Always finds the shortest path

Very little lag for most paths

Can set a maximum amount of iterations to reduce lag further at the cost of occasional failure

Will work if you allow diagonal movement as well

Screenshots

N/A for this type of script, really.

Instructions

To use this, merely use the script command inside a Set Move Route event and use this code:

find_path (target x, target y, diagonal, max_iterations)

Where target x and target y are the coordinates of the target. diagonal is an optional boolean value (true or false) denoting whether or not you want the event to be able to move diagonally or not. The value for diagonal defaults to false if it is not set by the user. max_iterations is also optional, and you can set this if you want the algorithm to quit if it is taking too long. The number you set here refers to how many nodes you let it search through before cancelling the process. If this is set to 0 or less, it will take as many iterations as necessary to find the shortest path

A sample Event:

@>Set Move Route: This Event : : $> Script: find_path (12, 33)

It's that simple. You can also put other move commands around it, use it on any characters that you could move via a normal move route, and set all the same conditions on the move route, such as Wait, Skippable, and Repeat. Like so:

Repeat works by repeating the path, not recalculating it. This means that if the path that was calculated was Down, Down, Left, the character will repeat that pattern, not necessarily going back to the square every time.

You can also set a default value for diagonal and max_iterations by call script with the codes:

#==============================================================================# Path Finding# Version: 2.0# Author: modern algebra (rmrk.net)# Date: April 10, 2008#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# Thanks:# Patrick Lester! For his tutorial on A* Pathfinding algorithm (found at: # http://www.gamedev.net/reference/articles/article2003.asp) as well as # another amazingly helpful tutorial on using binary heaps (found at: # http://www.policyalmanac.org/games/binaryHeaps.htm). Without his excellent# tutorials, this script would not exist. So major thanks to him.# Zeriab, for tricking me into believing that this was an actual exercise.# Also, his table printout actually makes Tables useable :P#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# Instructions:# To use, merely use this code in a script call INSIDE a Move Event:## find_path (target_x, target_y, diagonal, max_iterations)## where target_x and target_y are the target coordinates and diagonal is an# optional boolean value (true or false) stating whether or not to allow # diagonal movement. max_iterations is also optional, and you can set this if# you want the algorithm to quit if it is taking too long. The number you set# here refers to how many nodes you let it search through before cancelling# the process. If this is set to 0, it will take as many iterations as # necessary to find the shortest path.## You can also set a default value for diagonal and max_iterations# by call script with the codes:# # $game_system.pathfinding_diagonal = true/false # Allow diagonal movement# $game_system.pathfinding_iterations = integer # When <= 0, no limit## For scripters, you can force-move a character down a path via:## character.force_path (x, y, diagonal, max_iterations)## character is any Game_Character object, such as $game_player or an event.## Then, when you do not specifically set diagonal or limit, it will default# to the values you set in there#==============================================================================#==============================================================================# ** Game_System#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# Summary of Changes:# new instance variables - pathfinding_diagonal, pathfinding_iterations# aliased method - initialize#==============================================================================

I sent you a PM. I think it should work, but if it doesn't then PM me again. Also, I didn't actually see a script project in the PM you sent me, but that's okay. I think it will work regardless.

EDIT::

Hmm, I thought of a problem. You'll also want to be able to override a command if the player clicks to a different place. Give me a few minutes and I'll see if I can think of a solution. I have an exam tomorrow, so I might not come up with something tonight but by tomorrow I should have thought of something.

Never mind - that actually shouldn't be a problem. It should be overridden automatically

I was joking modern, it's not my fault you took my joke seriously There are probably some who are happy that you took my joke seriously, but even so. You don't have to credit me. I had nothing to do with it. You have found out and made everything without my help.I'll probably look into it eventually. If not before, then for when I try to make a path finding script for RMXP

I have not published my Table script because I forgot about it. Feel free to do it if you want, I probably won't do it myself.

@woratana: After some searching through my outbox I found it: (It's nothing special, not really)

class Table ## # Gives a special string representation. (For debugging purposes mostly) # def to_s if ysize == 1 begin return to_s_1d rescue # In the rare case where you have a 2- or 3-dimensional end # table with ysize = 1 end if zsize == 1 begin return to_s_2d rescue # In the rare case where you have a 3-dimensional table end # with zsize = 1 end return to_s_3d end

## # Returns a representation of the 1-dimensional table as a string # Assumes that the table is 1-dimensional. Will throw an error otherwise # def to_s_1d str = '[' for i in 0...(xsize-1) str += self[i].to_s + ', ' end str += self[xsize-1].to_s + ']' return str end

## # Returns a representation of the 2-dimensional table as a string # Assumes that the table is 2-dimensional. Will throw an error otherwise # def to_s_2d str = '[' for j in 0...ysize str += "\n[" for i in 0...(xsize-1) str += self[i,j].to_s + ', ' end str += self[xsize-1,j].to_s + ']' end str += "\n]" return str end

The Path Finder uses the same method for passability as when you are walking, and so the only squares that should block a path are ones that you wouldn't be able to walk through if you were trying to move that event or player manually. That being said, the passability method is retarded in RMVX and events at same level cannot walk over other events no matter what setting they're on, though your player can. I think worale wrote a script to fix that though.

As to your other question - no, not really. The way that it currently works is that it will replace the command with the commands that are generated by the algorithm - it will not continually try to find the player. Adding to the problem is that the player himself is an impassable square, and so it will not return a path anyway.

I am probably going to return to this script soon though, and I will see what I can do to address the stupidity of the approach method. I intend to do a few things once I start revising this script, and that list is:

Allow for revising a path if an impassable event moves into the way of the path already generated - this will require a different way to setup the paths perhaps, though I will keep the same interface.

Create a few additional pathfinding algorithms, including a near-optimal hierarchical pathfinding and a fringe search algorithm

Fix the approach method so that it uses the pathfinding script to find better paths to the player.

Heya, I'm spaniard, so I'm sorry if my "english" is hard to understand... *heh*First, thanks for writing this script.

I'd like to know if it's possible (in case the destination of the path isn't "passable") to find the shortest path to an adjacent location.

I fear I haven't explained it well, but I hope this helps:

"If $game_map.passable? (X,Y)$game_player.force_path (x,y) Elseif $game_map.passable? (x+1,y) or $game_map.passable (x-1,y) or $game_map.passable (x,y+1) or $game_map.passable(x,y-1) $game_player.force_path (the location that is closer to the player)

In any case, I will be working on a version 2 of this script soon which is going to be a lot better I hope. Part of it will include the ability to walk to closest square to destination and moving around moving events that interfere in the path after the path has been calculated.

Great script! I was hoping a solution to some eventing issues would be this easy to fix.

BUT! I was wondering if there's an easy way to make the script recalculate the path every time it is called...

Example:

I have K.T.S. set for in the day time, the villagers walk around aimlessly... but, at night time the villagers in town return to their respective houses (using your path finder). So since it only calculates each path once the next time the script is called (if i haven't left the map yet) it repeats the path taken before, even though since the villagers are set to random movement it may not be the same path needed...

When I write a new version of this script, I will allow for it. As it is, you would need to alter the script so that it retains the size of the path and the old command, and then just reset the move event command.

Did test, not sure what caused it, but something more than this script mucked it up. Not sure what so can't provide a straight test conclusion.I know path finding worked in a room with no obstacles but not from one room to another. Odd that, really.

"Lightning is like a troll, you don't know what hit you till you smell it!"

How easy would it be to allow this to create a path to get to the position (but one) of the player? Looking at the script and running some tests, it doesn't seem to like you specify a position that VX determines as impassable.

I tried to do something with it without going into anything too heavy for the GIAW contest, but didn't get too far with it at the time. Thinking about it though, I'd also need something along the lines of what you had planned for V3 of this script, in particular the recalculation of the route part due to the game including many moments in which the situation of the game and the player could change (in both subtle and dramatic ways).

Really, it'd just be nice to be able to move towards the player's location. Unless it'd just be simpler for me to work on my own version of the script so that I can make it work easier with the other idea(s) that I have planned.

I have no issues with scripting path finding algorithms (having based my uni dissertation on said algorithms), but seeing as this script already exists, I figured I'd see what you could do before I start the researching and planning that I'll have to do. Even some good ideas for me to look into/work on would be appreciated.

Thanks in advance, for whatever you can provide me with.

(Why do I always feel like it's the end of the world and I'm the last man standing?)

Hey MA, any news on a V3 of this script? We're trying to get a stable mouse system going, and we're running into problems with the current version of this script, which we're using for the script. It's actually just lag stuff, which we're trying to fix in other means, but we're getting some problems. I read that you have a better, faster version of this coming.. Is this still in development?

Or heck, what would be even easier, if you could maybe explain how we could set two different counts. One to keep track of the iterations, and one to keep track of the steps between the paths, and I think we could fix the problems we're having.

The script allows me to make a npc (or character) walk to a specific x and y coordinate on a map. It will determine the shortest path and walk there. How ever I found in maps with heavy obstacles that npc will not move.

For example, Suppose you have a pub with lots of NPC's, chairs, tables and obstacles. now make an NPC walk from point A to b, wait, walk from point b to the exit (disappear - wait re-apear) and walk to point C (some other place in the pub). Depending on how obstacle heavy your pub is (and this one is obstacle heavy) that NPC will disappear (it will essentially skip to the "leave the pub" section) and then after some frames re-apear and try to walk across the pub. This should not happen. the NPC should follow the command given by:

find_path (target_x, target_y, diagonal, max_iterations)

in this instance max-iterations is set to 0 (tested it with a number like 10 still doesn't change anything). Now maps that are not obstacle heavy like plains or a small forest the character can walk to the location given by this command. How ever if the map were to have lots of barrels or trees and lots of ways that the character could get to there destination it will skip that step or not move at all or in this case, the case of the pub example, leave and come back - essentially skipping to some other part of the movement commands given.

Are you still planning to make V3 of this script? I'm just curious because I can't use it, since routes aren't being recalculated. It would be great if anyone could fix this, as my scripting skills aren't good enough to alter this script by myself. And sorry for necropost.

Is there a way to make an event go directly to the player ? This sounds like a gnar-gnar script, but it'd be even better if you could do that.I've tried setting the script in the move route to "find_path($game_player.x, $game_player.y)" on repeat, but it doesn't seem to work. The event stays in place. And the pathfinding on the default "approach" is really iffy... when the events are too far away from the player, they get stuck in walls or don't move at all.

This is the only viable pathfinding script I can find for VX, unfortunately I'm having the same problem as slayer.

Would really appreciate it if you could do something about that recalculation (maybe a line that reloads the event page?). Script doesn't need to be any more efficient IMO, it just needs to be able to recalculate.

If it helps as reference, I have an ACE pathfinding script which does recalculate:

#===============================================================================# Pathfinding & Event formations# By Jet10985(Jet) & Venima#===============================================================================# This script will allow you to use a pathfinder to move players or events.# Modification: This script will also allow you to use a pathfinder which # incorporates formation handling.# This script has: 2 customization options.## Modifications:# Pathfinder:# Goal location may now be inpassable, pathfinder will still reach it.# Pathfinder still works "as intended" when the move route is set to repeat.# Added parameter: distance (explained below).# Added parameter: jump (set to true if the moves should be jumps instead of# walking).# Added parameter: commonEvent (provide the common event id for the pathfinder# to run the event before each move (useful for adding sound or effects to # movements)# Added parameters: # catchup (provide a value to indicate how far from the target the event # should be before it speeds up its movement)# catchupSpeed (provide a value for the speed when catching up)# normalSpeed (provide a value for the speed after its caught up)# Note: Pathfinder is a bit more processor heavy when used with a repeating # move route (it was useless before, so this is only a benefit)# Formations:# Added find_formation_path function# Added turn_with_player function##===============================================================================# Overwritten Methods:# None#-------------------------------------------------------------------------------# Aliased methods:# None#================================================================================begin

distance is set to 0 by default and can be omitted to keep the default value.While x and y represent the target location, the event will only be moved up to the specified distance from the target. This makes it easier to have an event follow the player, without getting in the player's way. This could be used as an alternative to following, except it works on any events, not just party members.

jump is set to false by default and can be omitted. Jump specifies that instead of the event "moving" to the target, the event will make small "jumps" to the target. If you specify jump, you cannot omit any previous parameters.

commonEvent is set to 0 by default and can be omitted. This specifies the id of a common event that you want executed before each move step. Currentlythis only applies to repeating paths. When set to 0, no common event is called.If you specify commonEvent you cannot omit any previous parameters.

catchup is set to 0 by default and can be omitted. Catchup specifies that ifthe event is equal to or past the catchup distance, they will move faster to "catch up". Their speed becomes the catchUp speed. Once caught up, they will return to the normalSpeed. If you specify catchup you cannot omit any previous parameters.

catchupSpeed is set to 5 by default and can be omitted. It is used when catchup is specified to a value above 0. (see catchup for details). If you specify catchupSpeed you cannot omit any previous parameters.

normalSpeed is set to 5 by default and can be omitted. It is used when catchup is specified to a value above 0. (see catchup for details). If you specify normalSpeed you cannot omit any previous parameters.

Running the script outside of a move route (as a standalone script call)has two extra parameters after x and y called "ev" and "wait" but has no commonEvent or catcup parameters.

find_path(x, y, ev = 0, wait = false, distance = 0, jump = false)

ev is set to 0 by default and can be omitted like so: find_path(9, 4).Ev represents which character is to be moved. -1 is the player, 0 is thecalling event, and anything above is an event on the map whose ID is the ev.

wait is set to false by default and can be omitted like so: find_path(9, 4) or find_path(9, 4, -1)find_path(x, y) or find_path(x, y, ev)wait specifies if the player will have to wait for the move route to finishto start moving again.

followId is the character that this event is in formation with. -1 = player,0 = current event (although this is pointless) and above 0 is the event id.

shiftX is the relational x position from the followId character WHEN that character faces "down". If you enter -1, this event will move to the left if its facing down, or right if its facing up.

shiftY is the relational y position from the followId character WHEN thatcharacter faces "down". If you enter -1, this event will move above if its facing down, or below if it's facing up.

catchup's default value is specified by the parameter FORM_CATCHUP_DIST andcan be omitted. This specifies how far behind this event can get before it speeds up to catch up.

catchupSpeed's default value is 5 and can be omitted. This specifies how fast this event will move when it's "catching up". If you specify catchupSpeed, you cannot omit any previous parameters.

normalSpeed's default value is 4 and can be omitted. This specifies how fast this event will move when it isn't "catching up". If you specify normalSpeed, you cannot omit any previous parameters.

You also have another command for formations:Entering "turn_with_leader" as a separate script after find_formation_pathwill cause the event to turn the same way the player is turned after arriving at their formation position.Entering "turn_with_leader(1)" will turn the same way as event with id 1.Turn_with_leader also has a second optional parameter. Entering "left" or -1will turn this event left of the leader's direction, entering "right" or 1will turn this event right of the leader's direction, and entering "back" or 2 will turn this event opposite of the leader's direction. Again, if you specify this parameter, you cannot omit the previous one.

# While mainly for coders, you may change this value to allow the # pathfinder more time to find a path. 1000 is default, as it is enough for # a 100x100 MAZE so, yeah. # Note from Venima, you probably don't want to change this value too much MAXIMUM_ITERATIONS = 500