Beehave 3.0 Features

[bitbrain]

Beehave has been around for almost two years now and the sheer amount of people interested in this addon is something I myself would have never anticipated! When I first came to Godot, I found the lack of minimalistic but effective behaviour tree addons frustrating, so I took the behaviour tree example by @GeroVeni as a foundation for Beehave. Since then, hundreds of commits were merged and released by over 20 contributors:

The Beehave 2 release for Godot 4.x has received a lot of Quality of Life updates, bug fixes and improvements. However, there have been some discussions on it, and some of the themes were as follows:

• Lack of C# Support lots of people use C# in conjunction with Godot but since Beehave 2 is purely based on GDScript, this leads to some issues when trying to access members/extend scripts.
• Performance Concerns community members raised concerns about the performance of this addon, especially since it is purely running in GDScript. (see Achieving acceptable performance #222) - while we still have to produce a good benchmark for this addon (see Performance benchmarks of this addon #168)
• API Breaking Changes some API design decisions early on lead to some features being incompatible with the current architecture, notibly a Parallel Node as well as some better tick() method that also provides the frame delta. We cannot perform the changes without breaking almost any project out there. Due to our rather strict backwards compatibility mentality, we aim to solve this differently
• Debugger is buggy We have a behaviour tree debugger, which seems to have broken several times due to the underlying Godot nodes we are using receiving breaking changes. While this is natural in any software project, this area in particular has been difficult to test and manage.
• Addon initialization issues

Version 3.0: C++ GDExtension

To address all the points above, I am proposing a new project: Beehave 3.0 which should aim to support all existing features of Beehave 2.0 while also providing a cleaner architecture and aiming for a better API design:

• GDExtension which would re-implement all nodes and functionality inside C++; this would allow us to also access engine internal nodes that may not be exposed to GDScript. This also would allow us to support both C# and GDScript equally. As a side note, we do not have to start from scratch here. There is https://github.com/BehaviorTree/BehaviorTree.CPP which can be used as a point of reference and there is already https://github.com/warriormaster12/beehave-cpp which we could use as a starting point (on a new branch, e.g. bitbrain/beehave@v3 ) which we could eventually rename to godot-4.x and the existing godot-4.x we could rename to v2
• Better testing we would aim to also test the debugger specifically, to ensure it works as intended.
• Breaking changes Version 3.0 would be incompatible with projects currently using Beehave 2.x but an upgrade guide would be provided.

Some concerns

• GDExtensions do not come for free:
  • people need to know C++
  • we need to keep godot-cpp up-to-date
  • GDExtension bindings often experience heavier breaking changes compared to GDScript, so it makes updating to a new Godot version harder
  • tooling & CI knowledge required (e.g. scons)
  • debugging issues may be more difficult. In case of an error in Beehave, the game may just crash and one would need to compile beehave with debug_symbols=yes to investigate what may cause this
• planning required: before we can start the project, we would need to document the following:
  • new API design
  • new architecture
  • all supported features we need to build
• transition period may slow down development: while maintainers focus on Beehave 3 it may become difficult to maintain all three: Beehave 1 (Godot 3.x), Beehave 2 (Godot 4.x), Beehave 3 (Godot 4.x, C++)

New opportunities

This brand new version would allow us to "go wild" and rebuild things much nicer and more structured, and we could even make use of some APIs that would only be available to C++ but not GDScript itself.

What are your thoughts on Beehave 3?

[warriormaster12]

One concern that I have is building for platforms that require signing the code (mac os / ios) though that’s not something that necessarily needs to be addressed immediately but it’s something that should be kept in mind.

Hopefully I’ll get a MacBook at some point from my workplace so that I can test this troubling platform.

[TranquilMarmot]

Yeah, I develop on both Windows and macOS... I use Terrain3D and have to build it from source on macOS to get it running properly. It's not too bad, but definitely a pain point.

afaik there's not a great solution to this, other than maybe paying for a certificate and signing releases with XCode.

[RedstoneParadox]

If Beehave were to be ported to C++, would it still be possible to use GDUnit4 for unit testing?

[bitbrain]

Yes, as all beehave nodes would be available inside the Godot editor as if they were native nodes.

[zvolchak]

planning required: before we can start the project,

Do you have any rough timeline in mind on when this could be started?

[bitbrain]

As soon as possible. I probably just need a proper weekend to set everything up.

[lostptr]

I am excited for this! I only have basic C++ knowledge but I would love to contribute!
However I fear if we dont have someone with solid C++ experience we will run into a lot of problems in the long run...

[bitbrain]

Made a start here: #287

[stechyo]

godotengine/godot-cpp#615

Seems like this issue would require 3.0 to have a different structure, no? We can't simply extend existing nodes like in the current version until this is closed.

[bitbrain]

According to https://chat.godotengine.org/channel/gdextension?msg=f4nLbN3tZMHNl4Cjx it works.

[stechyo]

godotengine/godot-cpp#615 (comment)
heh, interesting timing

(probably due to your thread on godot chat ofc)

[stechyo]

And yeah, forgot to elaborate but I did that a couple hours ago in my own extension and it seems to work now.

[Martanti]

Super excited for this! Will try to wait for 3.0 as much as I can before working on the AI bits for my game!

[LuukEbenau]

This would be amazing news if you're able to port beehave to gdNative. I really like the way beehave works, but its currently not very liable since the majority of my project uses c# instead due to performance concerns. Being able to run it from C# would certainly be a big step forward!

[danbraik]

Hi, just a though: it already exists a good plugin LimboAI which is a GD Extension. The problem of C++ Extension is that it doesn't run as Web HTML export. This is why I use Beehave since it runs everywhere easily, it is his advantage. Maybe we could continue to support Gdscript version like a long term version ?

[lostptr]

Oh I did not know this, does it have an issue in the godot repo? The problem is that we cant use gdextensions on the web build of godot or is it that we cant export games using gdextension to web?

[bitbrain]

Web exports for GDExtension were fixed with Godot 4.2 so this should be possible now.

[ElQDuck]

But with the LimboAI GD Extension its not possible to export to android. Will it be possible to export to android with Beehave 3.0 GD Extension?

[ICEFIR]

But with the LimboAI GD Extension its not possible to export to android. Will it be possible to export to android with Beehave 3.0 GD Extension?

curious - whats the issue with exporting to android? it shouldn't be a problem for any GD Extension as long as they provides the build for it

and in the case of limboai, worst case scenario is just to use the custom engine build and export against android

[abstractionfactory]

Hi @bitbrain and thank you for your work. I have a concern regarding C++ which I didn't see mentioned yet: which compiler would you use/support for this extension? This is mainly a concern because if someone were to recompile Beehave from source alongside other extensions (say, a Steamworks integration), it would be ideal if one toolchain could be used. However, the Steamworks SDK only works with the Visual Studio C++ compiler on Windows and breaks in subtle and insidious ways with gcc/mingw.

Also, as a side note, please support Cmake. It is much easier to get running with the likes of CLion than SConstruct, which requires Python to be installed.

[yosimba2000]

I'm an interested user! The features I'd love the most are C# support and a GUI tree interface.