Further down the ray-cast path..
Still very primative, but more progress has been made.
WASD, spacebar
P to attempt path solution
R casts a ray at the mouse and shows the first sidewalk.
The enemy will stop if it is to far offscreen. It helps if you resize the flash window to make it bigger.
To avoid needless backtracking and cut corners when possible, extra tests are now performed each time a way point is reached. These tests cast more rays at way points further down the list. The furthest way point touched without obstruction will become the next way point and the points in between discarded. Every second or third way point reached will probably need to trigger a completely new path finding solution, because of the time it takes to travel that far.
I’ve added a coefficient of average obstacle size that for now is just a variable, but might (eventually) be set automatically after a few solution attempts. The coefficient helps by hinting when the path should to turn off the ‘sidewalk’. In spaces with small obstacles, you’ll want to get off the sidewalk sooner and the coefficient will be smaller.
It turns out, that a sparse, empty space is ill suited to the ray casting approach, because it relies on bouncing rays off walls. Luckily, featureless spaces are simple in every other way, and often require no path finding whatsoever.
I’ll need to do some observation and tests to determine what order of left or right turns in a row is most likely to make progress towards the destination. I’d like to think that a lot of this can be done at runtime, but I need to be careful not to push this project towards the informed sort of pathfinding. I’m determined to keep the AI in the first person. It will have to learn it’s own space by casting ‘learning rays’. A lot of the tests I’ll need to make will be towards finding the important characteristics of obstacle filled spaces, and hopefully finding a few soft rules to follow.
It’s fun to program a solution with such unpredictable results. As I fly around and press P, I can see the rays cast, but if they were not shown, I’d anthropromophize the behavior of the pathfinding enemy. If the enemy was a bit faster and deadly to touch I think it’d be fun to try outsmart it.
Hi, i’m just starting to use flash, could you atatch a .fla of that so i can work out the code?
The code is probably not appropriate for your purposes. It is undocumented and dependent on the ray casting available in the also undocumented glaze physics engine. It does not make much sense to try to use it outside of the context of my sandbox.
It’s a novel approach to a path finding problem, but not necessarily a good one, I recommend you look into A* and navigation meshes.
It just occurred to me that you might not be talking about the code for the path finding algorithm, but the code for the whole game. The game engine is still in active development and the source may eventually be released with some documentation. Check back at my blog every few months and see!
I don’t think the code as it is now would be of much use to someone just starting with flash unless they are already an experienced programmer in some other language.
You might want to look at Flixel if you need a game engine, it looks pretty cool and has documentation and a support forum.
If you feel there is something unique to my game in progress that cannot be found in a more supported engine, then describe your project to me and I’ll consider sharing what I’ve got so far.
Thanks for your interest, and have fun!
-Jake