Its done, its more accurate but somewhat slower. heres a link
http://scratch.mit.edu/projects/Rurigok/191111
Offline
its still glitchy and acts weird sometimes, but it was the best i could figure out at the moment. I tried a y-positioning technique, but the 2nd probe kept getting stuck.
Offline
I was just having an inspiration on the matter: how about this, I don't know if it'll work, it's just a theory.
What if, in crowded areas with limited walking space (say, a sudoku-style grid), we pose sensor nodes at the intersections or major points in the map, like train stations. The AI would not be allowed to find a direct route, and the first step is to locate the nearest node to the sprite and the nearest node to the target. The sprite travels to the nearest node, and there is a network of invisible "railways" in all possible routes so it follows the railway to the node nearest to the target. At this point, if no railway is present, it "detaches" from the railway and completes the journey. So there will be minimum "off-track" time and most times it will be adhering to a grid of railways. It only seems feasible to do this in a cramped space, since railways have no maneuvering space, so to suit cramped situations. But if the invisble grid is constructed, and that the AI will be programmed to search for its nearest sensor node, the thing should be good to go.
Offline
But that means you have you specified every possible route after you set your obstacles. That can't be a general solution. The problem is solved, if you can draw other obstacles and the sprite still find the shortest path. This is very hard.
I think lestrade3333 way with the mayor Points are the right way. But this points should be created automaticly at the corner of the obstacles, which are in a direct line to the sprite. To find these corners, you can use something like a beam, which starts from the sprite. Then you should make a 360Turn and check if an obstacle is touching the beam. If the different of the point, where the beam touches the obstacle from one turn-step to the next, suddenly increases very much, than a corner is found. From this point, we have to do it again. If one beam reaches the target, we must go back to check if the beams are crossing another beam which is a shorter way to the destination. Now you have all these crossing Points or corner Points, which is the shortest path.
This could be a way which is possible with Scratch. But still very hard.
Offline
Bobby500 has a similar project. The scripts are incredibly complex, and I don't see how anyone could possibly adapt them for use in their own project and sleep in the same week. http://scratch.mit.edu/projects/Bobby500/239173
Last edited by fullmoon (2008-09-25 07:45:26)

Offline
You have try looking at this tutorial on path finding.It isn't language specific so you may be able to implement it into scratch.
http://www.policyalmanac.org/games/aStarTutorial.htm
Offline
Now you can draw your own obstacles!
http://scratch.mit.edu/projects/bhz/278433
Offline
lestrade3333 wrote:
Rurigok, that's exactly what I need, is there a link?
By the way does the project you refer to chooses the logically shortest path to the target?
If you have the link, I would be really grateful.
I have the link, It was made by AddZero:
http://scratch.mit.edu/projects/AddZero/186736

Offline
why not do what the proffesionals do? set up a grid, (two lists) and store vlues. you could use one grid though..anways. in the grid store weather its blocked or not(you would need to scan the screen) then have th AI figure out the fastest way to the target. this grid would be like, 32x32 etc etc to reduce scan time. it would make an interesting max solver, but to slow for scratch.
Offline
AddZero wrote:
Interesting problem.
Paddle2See, your's is perfect for small obstacles- what lestrade3333 is trying to do.
I puzzled over AI navigation for a while, this is a good time to try it out! It can do some larger obstacles, but it can still give up and do nothing. It could be improved.
http://scratch.mit.edu/projects/AddZero/186736#
I have improved it by adding a third probe that changes how many walls it bounces off of depending on how many tries.
P.S. Forgot the link:
http://scratch.mit.edu/projects/Leer10/840267
P.S.S. It won't give up, on every single try, it passed on turbo!
Last edited by Leer10 (2010-01-12 02:19:50)

Offline