This topic is getting more interesting by the day.
Quote:
(its basically an additional avoidance vector added
to movement, calculated by the discance of two
collisioncircles, and defined by an exponetially growing
strength of the force the closer the units get)

Damocles, this is basically what I was going to use the force field for, yes. The interesting part for me was how I could direction movement without having to make the ships check too much of their surroundings, and instead check if there's already a pre-suggested path they can follow around the object.

Saturnus, I like your first aproach (projecting onto the "field of view" and then deciding where to go from there) the most so far. Problem with this is that
a) I don't know the maths behind it, I'm just done with school and haven't studied maths (yet) and so my knowledge is somewhat limited there and
b) I don't see how it will find gaps between asteroids if they overlap. My approach here would be: project it onto the sphere and then see if there's "gaps" in the array and then fly through them. But if two asteroids overlap here (and so there's no gap in the array), I'd still need to check if there's a gap between them somehow... I'd have to do reading up on this one. Do you know what the method's called?

Actually, there were more reasons I had that kept me from using A*, I just didn't think of them when writing that post (last time I worked on this pathfinding must've been over 18 months ago) and I wanted to keep the post shorter.
- A* is based on a grid. This means I need to have a huge grid for my levels, because the smallest ships could be blocking only one cube. Also, it has to be 3d, so it would be quite a large field. Probably around 1000^3 cubes... which I find way too large.
- Also, I find A* works better (from what I understand) with static objects than with moving ones, since moving ones mean I have to recalculate the path so many times, or build in a good obstacle-avoidance which may mess up my path that I found completely.
That said I loved learning another new method for pathfinding. It's awesome, I would never have thought of filling the array with values like a minesweeper game. That's great!
Similar thing goes for the projection onto a 2d plane. It seems to be a great method, but my ships are supposed to go over or under the asteroid, if that's the shortest way. This would mean I'd need to project the scene onto an upright plane as well, which then again means that I'm back to 3 dimensions, and I think the purpose of this approach is to limit it to two.

Damocles, can you expand on your "flood fill topography"? I'm not making an RTS but I'm interested in all the possible approaches. And googling it didn't help me at all... found nothing useful there...


Some of the thinking I've been doing about this probably seems a little complicated considering most of the game's empty space. But I want to fill as many asteroids into the game as possible (it makes the game much more fun) and have them sitting very close together. So there'll probably be (and from gameplay-perspective: hopefully be) lots of complicated maneuvers. Also, I wanna do this right and not have an AI that's stupid sometimes. And even if it's over the top, I'd still like to gain the skills for more advanced pathfinding...


~"I never let school interfere with my education"~
-Mark Twain