I would check the node closes to the clickpoint, do a trace (or more advanced check) to see if it is reachable. Then let the player follow the path toward the endnode, and check every second or so, if the path could be reached dirctly now, and then go to the target in a straight way.
yep damocles thanks but you would still move from node to node on a zigzag course or have hard cuts. you can smooth those a little bit with steering shure... i think the more nodes the smoother is the path.
thats why iam interested how many of the nodes are used in daemonica and what are the average placement rules (whats a good place for a node?)?
Damocles is right, ulf. That is basically what we do (there's little bit more to it, but not much). The real problem is, as you might have guessed, that for a big level you need a huge number of nodes - especially for the outside levels (3-4 per single tree for example) that need to be placed manualy. I tested some ways to make this process semi-automatic and use less nodes. Although some of the results were quite promising, I didn't have enough time to make it work truly reliable.
EDIT: as for the short zig-zag turns: no one says that you have to turn immediately (flip) all the way to the next node once you've reached the previous one. You could simply go on and start turning the player. For this however you need to be sure that there is always enough space for him to make the full turn (it has to be rather fast anyway) or, which is the best way, check it if it is possible at all and if not, turn him immediately in the direction of the next node.
I'm going to ask a very dumb question but I'm a visual guy, not a programmer, so cut me some slack .... It made me wonder when I read this if it is possible/beneficial to create a 'potential nodes' map by painting say red paths on an bmp around obstacles and so on -like the placement map for trees idea, placed on terrain as a layer- then a player scans this map for the nearest red pixel (which is the path painted on this map) and then builds nodes along this 'path' when needed? This way you wouldn't have to have a huge amount of nodes ahead of time, just build a branch using the 'node placement map' when needed? Don't shoot if it is a wacky idea!
@bupaje: I don't think anything is gained by that. You would be using lots of memory for a mostly empty bitmap and searching for red pixels would probably be slower than searching for path nodes.
bupaje: I've seen programmers use this technique. Mostly they use it as a tool for the "non-programmers" to draw what they want to happen. Then a compiler converts the map into nodes that are quicker and take up less space.
I don't think they do this much anymore, since even most non-programmers are better at placing nodes then a compiler.
Baldurs gate (the infinity engine, dont remember the name), used this approach to define the field of passability.
It was just painted "on top" of the actual playground with different colors, of course scaled down. I guess the pathdinding then takes this "picture" to make A* search.
The colors also defined, whether the caracters where on the top floor, where the steps are and to on.
Thanks.
