Add additional behaviors

[Francois Belair]

There are more behaviors out there and they could prove useful for certain games. They should be their own issues, but they are gathered here for discussion and as a central location for now.

Some contenders:

Individual

• Wander: Gives an agent an acceleration in a random direction inside of its environment.
• RaycastObstacleAvoid: Uses raycasts to give an agent an angular acceleration that will keep it from running into obstacles
• FollowFlowField: Gives an agent an acceleration along the tangent of a flowfield's direction vectors or a heatmap's numerical difference.
• Interpose: Gives an agent an acceleration that will take it to a target but through an imaginary line between two other agents.
• Jump: Gives an acceleration that will take it to a starting point with enough speed to commit to a jump and reach a target destination upon landing, using a callback or signal.

Group

• Alignment: Gives an agent an angular acceleration to rotate and face the same direction as everyone in its proximity
• Hide: Gives an agent an acceleration that will move it to a position where an obstacle in its proximity is between it and its target
• Follow the leader: Gives an agent an acceleration that will move it into position to follow a given leader in its proximity
• Queue: Gives an agent an acceleration that will move it through a target point without conflicting with others in its proximity trying to do the same.

[Francois Belair]

Full-3D, six-axis enabled behaviors from #32 would fit here as well.

[Kotob]

Hello, I have some experience with 3D steering boids in godot and can probably help with some of these. Which of these are free to take and which have higher priority?

Here is a sample project that shows the 3D boids AI that I made from scratch: https://asheraryam.itch.io/flying-game

(Excuse the strange control scheme, it works best with a controller)

It has pursuit, evasion, alignment, grouping, follow the leader (which I use for staying within orbit range), and is fully multi-threaded and supports several hundreds per cluster with little noticeable slowdown (the in-game bottleneck is from my custom trail render graphics code which I put on the same thread).

I actually started porting the class to c++ for more speed but it would be a better use of my time to contribute here and optimize it instead 😄

P.S. I can also share the project source if it would be helpful

[Nathan Lovato]

@asheraryam your help would certainly be welcome! I'll let @Razoric480 tell you which behaviors you could work on.

Also, here are our style guides and contributor's guidelines:

• Godot GDScript style guide
• Commit guidelines

If you have any questions, we're here to help, or on Discord

I actually started porting the class to c++ for more speed but it would be a better use of my time to contribute here and optimize it instead smile

The day GDNative becomes really easy to set up and to use, and if GDScript's future performances aren't enough, we may port the slower behaviors to C or C++. But currently, it's hard to distribute that kind of code.

[Kotob]

@NathanLovato Thank you, I'm looking forward to it.

The day GDNative becomes really easy to set up and to use

Haha tell me about it, I definitely wasn't suggesting this project should shift to C++.

[Francois Belair]

I'm not working on any of them at the moment, so they're all free. If I had to prioritize a couple, however:

1. Raycast obstacle avoidance. Ideally, you should be able to give it a generic "raycast configuration" object that determines how the raycast works, and there should be some prebuilt ones (3 rays fanning out, a single one shooting forwards, etc.) The tricky part is that it should work in 2D or in 3D with minimal hassle. We may have to split this one into two classes because Godot's physics is split between 2D and 3D and it would make more complicated code to differentiate them. That or we have the one class, but the raycast configuration is abstract, and is extended into a 2D and 3D abstract classes, from which the prebuilt configurations are made from.
2. Wander.
3. Alignment group behavior.

Not that I'd reject code that implements the others.

• Raycast's job is to produce an angular acceleration that will steer it away from an obstacle.
• Wander is to move around in a randomized manner in its area
• Alignment is to produce a linear acceleration that will keep its owner aligned with the agents in its proximity.

Like the rest of the framework as it is, some inspiration has been taken from GDX-AI so feel free to source some ideas from it.

[Francois Belair]

As for GDNative, yeah; needing to distribute a DLL, dylib, and so file would bloat up the size of the framework, and expecting everyone to pull in and learn how to use scons to compile their own just to use the framework would make it severely inconvenient.

If we do make a GDNative module, it'd be an optional alternative. At the moment, however, performance hasn't really been necessary.