My First PathFinding Program

Blitz3D Forums/Blitz3D Beginners Area/My First PathFinding Program

YellBellzDotCom(Posted 2006) [#1]
It took me 3 weeks and about 100 hours to get here, but I feel like I'm close. Please post some comments to help me optimize or correct this.

there are some collision issues that stop player movement, but I'm tired.

Edit 10-26-06: Heres the version 4 with collision between character, scenary, and structures turned off
http://www.hilbily-works.com/Downloads1/PathFinding_TestV4.zip

You can download the exe file here http://www.hilbily-works.com/Downloads1/PathFinding_TestV3.zip

Thanks!!
Pathfinding testV3.bb is the main program
Globals.bb is an include for the Testv3.bb and the PathfindingV9.bb
PathfindingV9.bb is the main code for the pathfinding


This is the global.bb


here is the PathfindingV9.bb code


and here is the main program Pathfinding TestV3.bb



puki(Posted 2006) [#2]
Great - apart from the 'entity' doesn't actually navigate its way around objects.


mindstorms(Posted 2006) [#3]
to make it move around objects, simply reduce the entity radius of the sphere...You are making it have an actual radius of .5, then telling the collisions with a radius of 2...To make the player seen over the path I also made the path spheres only .2 instead of .5 because the player sinks down with a smaller entity radius.

There is a small problem in rare occurance when an object goes crazy...It makes the path look like an area of a triangle, and the player just moves seemingly randomly through it...

edit: happens when the player is on one side of the orange box and you click almost directly on the other side of the box...


Great engine otherwise! Keep up the good work.


YellBellzDotCom(Posted 2006) [#4]
Thanks for the replies, even yours puki, lol.

I was thinking today though, if your pathfinding system is meant to make an object move around another object, then why would you need collision detection for those 2 objects?

lol, I'll keep playing with it.

Edit: Just as I suspected, turning the collisions of the player, scenary, and structures off, makes the player move alot better. And thanks for the idea of turning the radius down too, but like I said, why gobble up processing time if you dont need the collisions in the first place?


mindstorms(Posted 2006) [#5]
Yeah, but sometimes the player will move through corners of other meshes, making them look bad...I guess a better system to handle that problem would be to check the surrounding nodes to see if they are blocked and if so then perform a simple enititydistance on the entity that they represent...it would be faster and accurate to do it this way, but maybe not needed.


jfk EO-11110(Posted 2006) [#6]
If you can manage to get rid of NPC collision then you'll save a lot of CPU power. You may want to turn collision between the player/camera dynamicly on when the NPC reaches a certain min distance.

BTW thanks for sharing your code. I didn't test it so far, (need to copy it to an offline machine first) but it sounds good.

What is it like, an "A*" thing or what?


YellBellzDotCom(Posted 2006) [#7]
Thanks again for the input, I can see what your talking about, if a characters mass exceeds the distance between 2 coords then, for instance, his shoulders may pass through objects. I will keep an eye on it and if it looks bad down the road, your fix may be the way to go.

JFK, it is A* up to the end, I dont trace a path back to the starting point using the parent flag although the parent flag IS filled in for each possible path cell, but when I looked at the closedlist file output, it always showed the correct cells for the path. This may be why the path gets bunched up around buildings though. Again, Ill look at this down the road again.


Ross C(Posted 2006) [#8]
Good work man. This is the main area of programming i just don't get. I've yet to read a tutorial that fully explains this. I get it up to a certain point, then it goes down the tubes. So, good work!


YellBellzDotCom(Posted 2006) [#9]
Thanks Ross,
This was a major deal for me. I had to re-read everything that everyone posted about pathfinding everyday. I've tried everything I could think of to make a half way usable include file for pathfinding. Im sure there are alot of optimizations that could be done here like using heaps(?) or banks(?) but those are a wee bit out of my scope. Just getting the custom Type Array as Stevie G suggested made it feel like I just climbed Mt. Everest, hehehe.

This will be a major component of the project I'm working on, Im pretty jazzed that I got it this far.

Thanks.


mindstorms(Posted 2006) [#10]
Hey Xyle, I made some major changes to your code (it was a better start than what I had prieviously), thought you might want them...

there is a problem with the colored spheres, sometimes they pop an error, just get rid of them will solve this and it will also speed up the pathfind by about 10 times as well :)

main.bb



pathfinding2.bb


this uses Ocothorpe's container hash tables, they are very useful.


I'm still not sure whether using the quicksort algorithm is faster than a binary heap, but I use the quicksort anyways.
Edit: binary heap made much faster, updated above. note: took away the spheres, just uncomment them to put them back in.


YellBellzDotCom(Posted 2006) [#11]
WOW!

I dont understand Heaps and hash tables or some of your coding lingo you used there, but I love it!! The complicated code of the A* tutorials is what made me try and plug this thing out. I will keep my eyeballs on this little dandy. I never used types before I began this adventure and now I know theyll be growing out of my code, so I know Ill get the hash/ heap thing sooner or later. You did 1 helluva job there mindstorms and I greatly, trully appreciate it. Please forgive the smudges here, a few tear drops fell.

Thank you, thank you!!


mindstorms(Posted 2006) [#12]
Thanks Xyle!

There are always improvements to make, right now I am working on a two-tiered system...

Just thought I would let people know that using arrays for the grid data is much faster than using hash tables...