well, here's an easy way I discovered a long time ago and only costs you like 10-20 bytes of data storage:

You have a list of directions the an enemy/NCP is allowed to go, and run through them in sequential order.  Let's say the path takes 10 movements to get from point A to point B.  that's 10 list elements, each with a number specifying direction.  Let's take this code for ex.:

Code: [Select]

.PATH:
[01010303020303010101]->Str0
For(P,0,9)
.RIGHT
If {Str0+P}=1
X+1->X
End
.LEFT
If {Str0+P}=2
X-1->X
End
.UP
If {Str0+P}=3
Y-1->Y
End
.DOWN
If {Str0+P}=4
Y+1>Y
End
End
.End of subroutine, Interrupt, or just normal code section
.Continue on to rest of code or Return

You see, it'll read the path values, and if the value is equal to a certain number, the enemy will go that direction.

There are a lot of ways to do path planning algorithms. Do you want to have the path calculated on the fly (fast, but doesn't guarantee success) or precalculated (slow and you have to figure out where to store the path data)?

Also, is there a known map that the algorithm can use? How important is it that the algorithm always finds the point? If it's very important that the point be found, then you're pretty much stuck with the potential fields approach. If it's not as important and the path will generally be fairly direct, then the simplest and fastest way is to give the character random motion with attraction to the point.

Before i write up an algorithm, i have to ask, are there going to be more than one Red dot?  Is there only going to be a singleGreen dot?  Can the Green dot move?

Quote from: Qwerty.55 on November 10, 2010, 04:37:13 pm

There are a lot of ways to do path planning algorithms. Do you want to have the path calculated on the fly (fast, but doesn't guarantee success) or precalculated (slow and you have to figure out where to store the path data)?

I want to precalculate the path. I just hope that the speed is still nice on a 20x20 map with 15Mhz.

Quote from: Qwerty.55 on November 10, 2010, 04:37:13 pm

Also, is there a known map that the algorithm can use? How important is it that the algorithm always finds the point? If it's very important that the point be found, then you're pretty much stuck with the potential fields approach. If it's not as important and the path will generally be fairly direct, then the simplest and fastest way is to give the character random motion with attraction to the point.

The path should be exact as long as the calculating dont get too slow.
The page you link to is only for members that pay 20$ for a registration.

There will be many red dots in my game representing the enemies positions. A enemy is able to (just for example) walk 8 fields per round. If this enemy already doenst has a location to focus, he will search for one green point that he can reach with 8 fields. If there is no green point with this close, he will focus the next green point he can reach and keep this focus.
Now the enemy has a focus in any case, so a path from the enemy to the focused location will be precalculated and the enemy follow this path by 8 fields. In the next round the path has to be generated again, cause the green points (the players characters) are also able to move (the focus follow the character/green point automatically).
I dont know how feasable this is, since the tilemaps are going to be 20x20 and the focus searching routine & the path calculating routine must will repeat by up to 30 times per round. Also, I have to take a look on the needed memory size.
The result should be looks like this (enemies are moving at 1:35).