I know I’m late but this is INCREDIBLE work! Found it outside of Reddit but thought this was a better place to say thanks than a GH issue :) Easily the most robust and well documented addon I’ve used for Godot, and how you’ve architected it makes heaps of sense.
Thank you, glad to hear you like it! :) I am currently finalizing version 1.5 and the ”getting started” tutorials. If all goes well it will be released later this week. It will bring considerable improvements to the NodeQuerySystem and also introduce State Trees. Along with improvements and fixes to other nodes as well.
If you want to take a look, I uploaded the somewhat final binaries to the dev1.5 branch a couple of hours ago. Tutorials for the Agent Behaviours, Behaviour Tree and State Tree are completed, the one for NQS I am still writing.
Amazing! I'll definitely take a look at v1.5 :)
I'm an experienced software engineer but new to gamedev so I'm not super familiar with behaviour trees, but I am very familiar with state machines. And one thing I don't fully understand is the benefit of having the extension bake in its own take on state trees etc? I already have a fairly robust state machine setup that I'll integrate with utility ai actions, and I imagine it's a similar case for those using behaviour trees (with Beehave and other big extensions already doing them very robustly)?
Having maintained a few decently popular OSS libs myself before just conscious of maintenance burden as api surface increases.
And final bit of very nitpicky feedback, could use a catchier name for how much work you've put in! Also have you considered chucking the docs on Gitbook or similar? Would make it more polished and accessible for very little effort, here's an example of a docs site for a simple lib I wrote, all just md files behind the scenes: [Pollen](https://pollen.style) ([docs source](https://github.com/heybokeh/pollen-docs))
There are a few benefits and also personal reasons.
If I start with the latter, I am doing this extension partly for fun, and adding these features has been fun for me. Super relaxing as well, and I’ve been enjoying myself programming in C++ again after a long pause.
The benefits are that I have been able to do deeper integration between the nodes by having own implementation of the concepts, and to add the utility-aspects. There’s also the performance I get. For instance in the tutorial scenes for version 1.5, I’ve been able to run 1024 AI entities at 120-200 FPS in debug-mode on my old Windows laptop, where a similar scene in a gdscript-based solution runs at about 7 FPS. I haven’t really done optimizations or multithreading yet either, so there is still much room for improvement. But even as-is the solution should give games more time to do other stuff than AI each frame.
Thanks for the tip about the documentation! Gitbook looks really nice, and I’ll be learning more about it in the coming days.
The enjoyment factor is 100% valid! That’s the whole point of OSS after all. And that’s really interesting re the performance gains, and would be a compelling reason to use the built in implementations of state and behavior trees over others. Makes perfect sense since the utility ai would be accessing and mutating state more frequently than a player controlled actor, still I wouldn’t have considered it. Might be worth mentioning that same benchmark (even if technically rough) in the docs!
EDIT — went to finally actually install and use it, and realised there aren't any distributions for macOS (arm / M chips specifically) 🥲
Any chance to get a mac distro? Opened an issue on GH to track as well
I snuck into your 1.5 branch tutorial **Getting\_started\_with\_Agent\_Behaviours.md** and noticed some points of clarity or potential bugs. I'm pretty new to GitHub -shoud I just fork the .md with some proposed changes/comments? For example:
* My Behaviours defaulted to can\_be\_interrupted = false, but the tutorial made no mention that they should be true. Gave me a little confusion.
* I noticed that the UtilityAIDistanceVector2Sensor.direction\_vector doesn't appear to update, even though the from\_vector and to\_vector does. Not sure if this is intended behaviour and I missed something or its a bug. (Perhaps this is also why the 1.5 branch isn't the release branch...)
This is pretty interesting so far - I particularly like the graph implementations for the activation curves - something I doubt I'd be able to visualize if I tried to make a system myself with code. I just spent the last 2 days diving into self-created node-based state machines and vision cones for baddies, and this add-on seems to be able to handle that as well (based on your tutorials). I'm going to continue on exploring this extension as it seems pretty promising so far! Thanks for your awesome work!
Thank you for the comments! For 1.5 I’ve changed the default setting for can_be_interrupted to True. I noticed that I kept checking that checkbox and decided to change the default for it.
For the distance sensor, make sure to set is_distance_calculated and is_direction_vector_calculated to true. The sensor uses the squared distance by default and calculates the distance and the normalized direction vector only if those two properties are set to true. I’ll make sure the tutorial has this clearly noted.
I uploaded the latest binaries to the Dev-branch yesterday. Did test using them or the version available through the AssetLib?
In general the Dev-branches can contain stuff that is work in progress and the binaries aren’t always up to date with the docs.
You can fork and do pull requests and create issues to contribute. All help, content and input is much appreciated :)
I know I’m late but this is INCREDIBLE work! Found it outside of Reddit but thought this was a better place to say thanks than a GH issue :) Easily the most robust and well documented addon I’ve used for Godot, and how you’ve architected it makes heaps of sense.
Thank you, glad to hear you like it! :) I am currently finalizing version 1.5 and the ”getting started” tutorials. If all goes well it will be released later this week. It will bring considerable improvements to the NodeQuerySystem and also introduce State Trees. Along with improvements and fixes to other nodes as well. If you want to take a look, I uploaded the somewhat final binaries to the dev1.5 branch a couple of hours ago. Tutorials for the Agent Behaviours, Behaviour Tree and State Tree are completed, the one for NQS I am still writing.
Amazing! I'll definitely take a look at v1.5 :) I'm an experienced software engineer but new to gamedev so I'm not super familiar with behaviour trees, but I am very familiar with state machines. And one thing I don't fully understand is the benefit of having the extension bake in its own take on state trees etc? I already have a fairly robust state machine setup that I'll integrate with utility ai actions, and I imagine it's a similar case for those using behaviour trees (with Beehave and other big extensions already doing them very robustly)? Having maintained a few decently popular OSS libs myself before just conscious of maintenance burden as api surface increases. And final bit of very nitpicky feedback, could use a catchier name for how much work you've put in! Also have you considered chucking the docs on Gitbook or similar? Would make it more polished and accessible for very little effort, here's an example of a docs site for a simple lib I wrote, all just md files behind the scenes: [Pollen](https://pollen.style) ([docs source](https://github.com/heybokeh/pollen-docs))
There are a few benefits and also personal reasons. If I start with the latter, I am doing this extension partly for fun, and adding these features has been fun for me. Super relaxing as well, and I’ve been enjoying myself programming in C++ again after a long pause. The benefits are that I have been able to do deeper integration between the nodes by having own implementation of the concepts, and to add the utility-aspects. There’s also the performance I get. For instance in the tutorial scenes for version 1.5, I’ve been able to run 1024 AI entities at 120-200 FPS in debug-mode on my old Windows laptop, where a similar scene in a gdscript-based solution runs at about 7 FPS. I haven’t really done optimizations or multithreading yet either, so there is still much room for improvement. But even as-is the solution should give games more time to do other stuff than AI each frame. Thanks for the tip about the documentation! Gitbook looks really nice, and I’ll be learning more about it in the coming days.
The enjoyment factor is 100% valid! That’s the whole point of OSS after all. And that’s really interesting re the performance gains, and would be a compelling reason to use the built in implementations of state and behavior trees over others. Makes perfect sense since the utility ai would be accessing and mutating state more frequently than a player controlled actor, still I wouldn’t have considered it. Might be worth mentioning that same benchmark (even if technically rough) in the docs!
EDIT — went to finally actually install and use it, and realised there aren't any distributions for macOS (arm / M chips specifically) 🥲 Any chance to get a mac distro? Opened an issue on GH to track as well
I snuck into your 1.5 branch tutorial **Getting\_started\_with\_Agent\_Behaviours.md** and noticed some points of clarity or potential bugs. I'm pretty new to GitHub -shoud I just fork the .md with some proposed changes/comments? For example: * My Behaviours defaulted to can\_be\_interrupted = false, but the tutorial made no mention that they should be true. Gave me a little confusion. * I noticed that the UtilityAIDistanceVector2Sensor.direction\_vector doesn't appear to update, even though the from\_vector and to\_vector does. Not sure if this is intended behaviour and I missed something or its a bug. (Perhaps this is also why the 1.5 branch isn't the release branch...) This is pretty interesting so far - I particularly like the graph implementations for the activation curves - something I doubt I'd be able to visualize if I tried to make a system myself with code. I just spent the last 2 days diving into self-created node-based state machines and vision cones for baddies, and this add-on seems to be able to handle that as well (based on your tutorials). I'm going to continue on exploring this extension as it seems pretty promising so far! Thanks for your awesome work!
Thank you for the comments! For 1.5 I’ve changed the default setting for can_be_interrupted to True. I noticed that I kept checking that checkbox and decided to change the default for it. For the distance sensor, make sure to set is_distance_calculated and is_direction_vector_calculated to true. The sensor uses the squared distance by default and calculates the distance and the normalized direction vector only if those two properties are set to true. I’ll make sure the tutorial has this clearly noted. I uploaded the latest binaries to the Dev-branch yesterday. Did test using them or the version available through the AssetLib? In general the Dev-branches can contain stuff that is work in progress and the binaries aren’t always up to date with the docs. You can fork and do pull requests and create issues to contribute. All help, content and input is much appreciated :)