FindPath

[nra]

Hello Guys,

At the moment the AGD has no means to do efficient 16x16 squares(by sprites) pathfinding--no arrays, stacks/queues, more sprites/instances, and so on.

So, how about an external ASM, considering the current X;Y and returning A,B parameters if the sprite could make a next step towards the paramA;paramB, avoiding the solid/fodder blocks?

It seems even trivial, and if the path is blocked, then just nil the A;B.


Any ideas?
TY

[lukebord1]

...what exactly are you trying to achieve?
Not sure what do you mean about "pathfinding", but generically, by setting a couple of global variables to "mirror" the sprite coordinates (e.g. "LET O=X / LET P=Y" at the end of the sprite event), it's possible to trace its position.

[nra]

Ok, one would use A*/wave (and others en.wikipedia.org/wiki/Pathfinding) to check whether the sprite can reach some other point/sprite considering the current obstacles via the same DIM in Basic and other languages, but how about AGD?

I think the best approach is to re-use the current AGD infrastructure (blocks map), without unnecessary overhead.

[lukebord1]

Ok i see, interesting argument.

Don't think AGD uses any kind of algorithm to get the best path; it seems a calculation more related to a custom routine (which could be built using some variables and instructions).
The AGD documentation provides a good explanation of all the available commands, it's a very basic syntax to code 48K Spectrum games; for sure it isn't a tool comparable to the development tools for today's apps.

[nra]

Luke, it's quite possible even in Basic, let alone AGD (yet).

Also I'd really like to have a FindNear counterpart...
However, let's not press Jonathan far too much)

[alessandro]

Path programming can be done in AGD. Just be sure to state the precise coordinates for each node of the path.

See this thread for a suggestion.

[nra]

Alessandro, they are but two opposite tasks: to set a path vs. to check if there's a path from A to B.

Why, it's still possible to bruteforce waypoints, yet at the expense of non-optimal approach, not to mention a couple of such checks.

Also I think that a LineOfSight or SpriteCanSee function, which are for PC version of AGD, perhaps)

[alessandro]

Hi nra,

the method in the other thread is meant to create a fixed movement pattern. To check a path between two points you could refer to the IF CANGOetc. conditions in order to let the sprite follow a certain direction whenever it can. You could also add other checks, for instance if the sprite is located before or after a certain line/column, it will move in a certain direction instead of another.

I implemented a sort of "line of sight" for the spiky balls in Sophia. The Y value for the main sprite is continuously stored in another variable, T in my case. When T is equal the Y value of the spiky ball sprite, it means Sophia is passing underneath it, and this activates the ball.

The script for the chasing sprite also uses a similar concept.