@No Time to Code
I have checked out both programs. Very nice. The first file to find the passable positions works well, the pathfinding in the second file also seems to work well.
The problems you mentioned with locking up when using the terrain object have to do with collision, I'm pretty sure. The method in my test post of the house on the terrain uses a feeler object that moves up and down until it collides or doesn't collide with the terrain and then returns that height to position the camera. I think the feeler object is also colliding with your plane nodes so it can create an "infinite search for height loop" as it bounces between the terrain and a plane. I was able to get the camera to leap out of the suspected loop and then the program ran, but at about 35 to 50 fps. This is good and bad for a couple of reasons:
1. I had only tested the getting ground height with a feeler object without having possible conflicting objects in the same path or position, therefore, I have found that I need to work on this method of getting ground height to make it realisitcally usable in a game. So, now I have some information on where to go with that.
2. Having a grid of individual nodes, especially with collision destroys way too much processing power to be used in real time. The plane/node check is good for the initial setup to get an array of the passable and impassable positions, but beyond that, an array of the nodes, as opposed to actual planes, makes more sense.
I realize in the second program the planes are also used as a visual representation so we can see the physical path, but I wanted to address that I do not think they should be used in game (even hidden) but for the demo it is an excellent visual aid.
I also wanted to caution you on your approach to single versus multiple enemy pathfinding. The method has to be generic enough that it can be applied in any situation no matter the number of objects or enemies.
This is how I see the basic game flow of movement:
main loop
check user input for character control
record movement command (forward, backward, left, right, rotate etc)
jump to movement function
...function move(object,f,b,l,r,ry,rx)
object can be enemy or player
if object is player
move player routine
if object is enemy
check for inside or outside
...inside use path finding system
loop through ememies
jump to movement function
combat
physics
etc.
So perhaps your path system has to be able to be integrted into an overall game movement function. If entities in the game use the same function, all movement can be similar in a similar physical world.
And here's more monkey wrenches to be thrown in the machinery (not really)
. When the player moves, the final target position in the path finding may change, but perhaps not enough to warrant an entire recalculation of the A* . Is it possible to only check the last node or target square against the player's new position and see if it still leads back to the enemy's original path? The test would be if the players current grid square touches or leads back to the previously calculated enemy path. That way you could eliminate a lot of time and recalculation of paths if say the character is just dodging back and forth in a room or confined area.
This may go hand in hand with a distance check between the player and the enemy - if the distance has reduced then perhaps the whole path is recalculated so the enemy can find a shorter route. If the path has increased then check to see if the original path still touches the player's new position and only calculate from the previous target to the new target and add that onto the enemy's path.
This may mean setting up a path array for each enemy
dim ememypath(obj,2)
enemypath(obj,0)=next square in path
enemypath(obj,1)=x position of next square
enemypath(obj,2)=z position of next square
@Digger412
We need a bunch of miscellaneous things around. Fences, barrels (steel and wood), trees, bushes, chairs (broken and intact), dressers, chests, individual planks (for boarding up windows) - you can build any of thes and or collect them from various sources. If you collect them, make sure you can prove that we can use them in terms of copyright and licensing.
Also we need good quality sound effects. Good quality means if they are looped that they don't have an obvious start and end spot, they don't contain hiss, they are small in terms of bytes but sound good, they are monophonic (will allow us to use 3d spacial positioning with the built in DBC commands). Things like:
wind
rain
creaking boards
footsteps - gound, wood, metal, stone etc
dogs barking
crickets
tumbling tin cans
night sounds
etc
You, know, general night time spooky stuff and atmospheric sounds.
Enjoy your day.
