Irrlicht Engine

I am thinking how to search the range a character can move now. I made a sample program, so I expose.
Look at pictures. "S" is a start point, brown squares are walls and cyan ones are floors, and each number signifies move power left for shift -- the search process stops when the move power is exhausted. Green ones are the woods, and two move powers are used there. Pink is a route.
Those pictures were drawn by Irrlicht.

Binary
http://www.mediafire.com/download.php?jxyzjtyttkh

Do you have any code, or at least some description about how you create the levels/search results?
This isn't really a project, so I'll move it to code snippets - you just have to add the code therefore.

I've use bitmap file as the Map of finding. An average value as the searching value ( <64 is no moving into).

I tried searching move range by "A*", and succeeded. This is a very simple program for testing, and I must coordinate it for common game usage. Needless to say, this program is necessary to characters' moving of various games.

i'm not a tech guy here but normally if let say I am S and I'm going after F, wouldn't I go straight to him rather than walking along the sideway? Since there isn't any obstacle in the middle. just my 2 cents though.

Virion wrote:i'm not a tech guy here but normally if let say I am S and I'm going after F, wouldn't I go straight to him rather than walking along the sideway? Since there isn't any obstacle in the middle. just my 2 cents though.

Same distance, but like you say; i think most games will try to zig-zag.
This could be done by keeping a record of last move direction, then if you have an equal cost of moving in 2 directions try not to move in the same one as the last time.

Virion wrote:i'm not a tech guy here but normally if let say I am S and I'm going after F, wouldn't I go straight to him rather than walking along the sideway? Since there isn't any obstacle in the middle. just my 2 cents though.

no, if you look at this picture:

you'll see that each square has a moving range value...
and if you count the values you'll see the (long) path has a lesser value than the streight path...
(at least this how I understand this )

No, that version was probably the completely clear version. But as ErUs said, both ways are the same distance (as we're not in euklidian space anymore) and hence are equally good. So it depends on side conditions or the search order which path is found.

He's talking about weighted graphs. Each node has it's own weight.

But the example he gave, both paths add up to 6

Ulf wrote:Each node has it's own weight.

..., that's what I meant with "moving range value" !!!

Virion, your point that it seems more natural that a character trads zigazag is correct, but zigzag will increase useless actions --waste time for turn-- in the project I am imaging. I let a man walk as straight as possible.
The first, second, and third pictures are not A*. They are calculated only by a move value each square has without A*. All a* programs have window-titles "A*".

This is a sample that I extended my A* program to 3D. It is so easy to apply a complete program on Irrlicht to 3D.

Demo
http://www.mediafire.com/download.php?mzzojwgkuo2

[/url]

Vandal wrote:This is a sample that I extended my A* program to 3D. It is so easy to apply a complete program on Irrlicht to 3D.

looks good! hope to see a 3d model running on the path soon!