In typical programmer fashion I've done a ton of research into AI generally and making navmeshes for Godot but completely forgot about the basic movement. Looking up patrol paths etc. is pretty easy there are lots of resources but surprisingly I can't find that many on randomised wondering and I often end up wondering into Unity code. Ideally what I'm looking for is similar to Random.OnUnitSphere position data but within a fixed radius rather than a constantly updating one once the destination has been reached.

I'd be grateful if someone could point me in the right direction on this. I also have plans to help out the Godot community a bit by posting up my own code with the AI experimentation I'm doing now I'm way more familiar with the engine. It should mean that people will have more access to some more information that has been neglected.

In case anyone is wondering, it's part of a project that I'm pushing to churn out this year and I'm going to try mimicking the AI that games like Halo have where you've got NPCs battling it out with each other in factions. Except this of course will be all done with modern software and Godot especially.

  • Lethn replied to this.

  • Lethn One thing I did think about was randomly spawning a raycast within a radius and then spawning a node at the hit point of the raycast and then having it delete itself when the AI reaches the destination then the process would repeat but I feel like that would be way too hacky of a solution for navmesh.

    Not dissimilar to what I did ages ago for something, but instead just used an arbitrary random direction vector from the Unit's position * arbitrary random distance range as the 'random point', then once the distance of unit to this point was below a certain threshold, repeat.

    Avoids Raycasts & creation/deletion of Nodes which are more expensive operations at scale, and could be offloaded to a separate thread (I think Raycasts are locked to physics system/single thread, I may be wrong).

    Also do not make these checks happen every frame, something like this could happen 1 frame in 30 or slower and still have the same visual effect to the player. Creating frame offset groups like this for a subset of Units (e.g five units processed in frame 1, five in frame 2 etc. upto 30), or threads = more performance.

      Lethn One thing I did think about was randomly spawning a raycast within a radius and then spawning a node at the hit point of the raycast and then having it delete itself when the AI reaches the destination then the process would repeat but I feel like that would be way too hacky of a solution for navmesh.

          Lethn One thing I did think about was randomly spawning a raycast within a radius and then spawning a node at the hit point of the raycast and then having it delete itself when the AI reaches the destination then the process would repeat but I feel like that would be way too hacky of a solution for navmesh.

          Not dissimilar to what I did ages ago for something, but instead just used an arbitrary random direction vector from the Unit's position * arbitrary random distance range as the 'random point', then once the distance of unit to this point was below a certain threshold, repeat.

          Avoids Raycasts & creation/deletion of Nodes which are more expensive operations at scale, and could be offloaded to a separate thread (I think Raycasts are locked to physics system/single thread, I may be wrong).

          Also do not make these checks happen every frame, something like this could happen 1 frame in 30 or slower and still have the same visual effect to the player. Creating frame offset groups like this for a subset of Units (e.g five units processed in frame 1, five in frame 2 etc. upto 30), or threads = more performance.

              Lethn

              Yah is just a Vector3 defining the target point and the nav server deals with the rest. Also you could handle for height manually by just clamping the Vector3.y value if you wanted to limit to a specific floor for example.

              Another thing is depending on your level/nav design you may end up with some convoluted paths, so may not hurt to throw in a moving average of distance to ensure the Unit is consistently moving closer over time and have a fallback solution if it gets stuck in any way.

              I think I had some scenarios where the end point was essentially unreachable, but that shouldn't happen if you set up the navmesh parameters correctly.

                  4 days later