I am trying to create a game in which ships have to fly around and dogfight each other, while avoiding objects and other ships. I have opted to use A* Pathfinding because it seems to be the best type for my situation.
Most importantly, the ships will usually be fighting near a planet, so there are many potential objects, both nonmoving and moving, which it has to avoid (e.g. enemy/friendly ships, moons, etc.).
I will also use BodyMovers (now called Constraint Movers) in order to make the ships fly forward, and rotate the ship to their desired target.
I’ve done some research recently on A* Pathfinding. However, I cannot find anything related to using it in a 3d space on Roblox (so a 3d grid, not a 2d one).
So now I have come to the forums for whether anyone has any experience with A* pathfinding, or any advice on how I can use it.
I have made a tutorial on A* pathfinding; albeit unoptimized, but you can add more direction values such as up, down, up-left, up-right, down-left, down-right
you might need to find a good heuristic function for your environment, some heuristics work best in open-space environment, some perform bad in open-space environment
Assuming you have a decent understanding of how pathfinding systems like PathfindingService works:
Navigation in 3D space isn’t too different from the techniques used to traverse navigation meshes. The difference is that instead of traversing surfaces, you’ll be traversing volumes. Unfortunately though, this does mean it is inherently slower.
Most systems, as far as I’m aware, achieve this through traversal of (sparse) voxel octrees. You can learn about this technique here, and watch a conference on Warframe’s implementation here. The optimisation techniques, such as zoning, can be applied in a similar manner: see this relevant blog post here.
The issue with this implementation, of course, is that you’ll have to create a system to prepare, divide and simplify the volumes yourself. Not sure if this reference is any good, but a quick google of an implementation available as FOSS on Github: Nav3D for Unreal Engine
Other naive methods do exist though. For example, have you considered ‘faking’ it using 3D waypoints? You could further improve this by using an object avoidance system if the agent ‘gives chase’ to its target? Depends how accurate you need this system to be, and how important it is to your gameplay
I don’t understand what you mean by ‘faking it’ and other agents ‘chasing’ to their target. I interpret ‘faking it’ as instead of generating parts which might lag the game, I use tables of vector3 locations, which have an [identification #] [activation state] and a [vector3]. This would be very resourceful, and a splendid idea for the system.
I don’t understand what you mean by ‘faking it’ and other agents ‘chasing’ to their target.
The chapter I referenced on ‘3D Flight Navigation Using Sparse Voxel Octrees’ (here) goes into a little detail about the naive waypoint method in chapter 21.2, but the general idea would be to implement what you described:
Preparation
Level designer places volumes of free space where the agent can move around freely, e.g. an orientated-bounding box
Level designer places waypoints between these volumes that describe a clear path between them (in a similar manner to how you’ve described it)
Traversal
The connected waypoint graph is traversed to find the path to the target if outside its current volume
If the agent and target is within a volume the agent can path directly to the target
The idea of implementing object avoidance would be to avoid dynamic obstacles despite using a static waypoint graph, or to avoid obstacles if the agent were to deviate from the predefined paths (e.g. in the case of Zombie-like chasing). Reference to collision avoidance can be found within another chapter from the same reference here.
As I mentioned before though, this is pretty naive and has its limitations - it all depends on whether this would be acceptable for the gameplay you’re envisioning.
I interpret ‘faking it’ as instead of generating parts which might lag the game, I use tables of vector3 locations, which have an [identification #] [activation state] and a [vector3].
I’m not sure I understand what you mean by ‘generating parts’? Unless, maybe, you mean storing the volumes & waypoint locations in parts to be read by the pathfinding implementation?
You could store them as that before initialisation if performed; but as you’ve already said, the waypoint graph & volumes would be stored within a data structure such as a table.