Discussion [REQUEST] Motion planning

[xDGameStudios]

As happy as I am (OR NOT ) with the motion planning system (there are some lacking functionalities that could added


CHANGES::

mp_grid_add_cell(id, h, v);

to

mp_grid_add_cell(id, h, v, [value]);

USAGE: the optional value could be used as cost for other motion planning functions!
(as gml uses only real/string types... this would not create that much of a memory usage... true is actually a real! I could be wrong! Let me know!) Default = -1 (unpassable)

mp_grid_clear_cell(id, h, v);

USAGE: Would set the cost value to 1.

ADDITIONS::

mp_grid_set_cell(id, h, v, [cost]);

USAGE: the optional value could be used as cost for other motion planning functions!
(as gml uses only real/string types... this would not create that much of a memory usage... true is actually a real! I could be wrong! Let me know!) Default = -1 (free).

mp_grid_path_ranged(id, path, xstart, ystart, xgoal, ygoal, allowdiag, range);

USAGE: Lets you select a range (using the cell cost) that would limit the path... return a bool... if the goal was reached or not... if it was limit by range (returns false) else (returns true)

mp_grid_range(id, xstart, ystart, allowdiag, range, [ignore]);

USAGE: Returns a 2D array (1st dimension - the number of clear cells within range; 2nd dimension - [0] cell horizontal value and [1] cell vertical value). This would let people define a starting point but no ending point. Useful for tactical grid based games. Ignore would make every free cell cost be 1 (limiting only by range).

ds_grid_to_mp_grid(source, destination);

USAGE: As default cost value is added it allows for the existence of this other function.

What do you think!!?
Sure there are some other functionalities (what would be your suggestions?)
built in A* algorithm (it's widely used... it's sad it isn't implemented by YoYo, yet)

 

[YellowAfterlife]

As far as I know, the built-in algorithm is A* - it is just that it was historically written with 1-bit weight (for performance?).

While the built-in functions could use some additions, ideally you shouldn't be using grid-based A* at all - node-based (manually or automatically optimized) solutions are often magnitudes faster, even if they are written in GML.

 

[DeScruff]

As far as I know, the built-in algorithm is A* - it is just that it was historically written with 1-bit weight (for performance?).

While the built-in functions could use some additions, ideally you shouldn't be using grid-based A* at all - node-based (manually or automatically optimized) solutions are often magnitudes faster, even if they are written in GML.

Ooo this is the first Ive ever heard of l1... Hmmm interesting gonna have to look more into it

 

[xDGameStudios]

As far as I know, the built-in algorithm is A* - it is just that it was historically written with 1-bit weight (for performance?).

While the built-in functions could use some additions, ideally you shouldn't be using grid-based A* at all - node-based (manually or automatically optimized) solutions are often magnitudes faster, even if they are written in GML.

What about pathfinding with range?! (return all cell within range, applying terrain cost) are those functions acceptable?! or are we better with GML?! what do you suggest using?