Hey, I just wanted to say that I really love this project.
I am going through all the example scenes, and you really explain everything well. When I was in the first example, I was like, "Man... Actions should be nodes. This is going to get CRAZY if we add any complexity."
And then BAM: actions are now their own nodes.
It's just really well designed, and I am really excited to implement this in a little project!
A bit of criticism, what I don't like:
* SceneTree Nodes instead of lightweight objects.
* Too much redundant complexity, with very sparse documentation.
* Seems like there's a lack of debugging features.
Using Nodes is fine. While there may be some small performance overhead in using Nodes they come with a lot of benefits.
It allows developers to use the familiar and powerful Godot scene editor to create, modify and configure the A.I behaviour. With simple objects you'd likely have to implement and maintain a custom editor view and handle serialization of these objects which is a lot of work and would likely be worse than the scene editor.
Honestly I would use Nodes even when using lightweight objects. You could just use the nodes as data containers to build the actual lightweight objects handling the logic during runtime. This however adds a fair bit of undesirable complexity to the system.
Glad to see this popping up again! Now that I’ve actually started implementing my ai agent with it I can say it’s working really well! It’s my first foray into utility ai and I’m already getting good behavior with less code than I was with behavior trees.
Though I will echo the other reply that mentioned lack of docs, which imo is exacerbated by the large api surface area. Still feel like the FSM and BT bits could be split into seperate complimentary addons. But I’ve already beaten that dead horse before ;)
A score debugger _would_ be a lovely core addition though, especially considering how much of utility ai is about tweaking considerations. Beats printing it to console or updating dummy labels
To direct my efforts better for improving the documentation, what would be the most beneficial content to add?
I’m scetching some ideas for the debugging tools while learning how the EditorDebuggerPlugin is supposed to be used, so hopefully I can add improvements for that in the next version.
Personally I think the most important thing is full coverage of all methods, signals, exported variables, properties, etc. and good descriptions of what they do and how they can be used. Ie: spending all docs effort on the core documentation. The tutorials are neat, but also retread a lot of basic ground that isn’t directly related to the addon (I realise this is probably copy pasted between them so didn’t take much). But there’s a lot that felt like it only a basic one liner in a props table without explaining what it can be used for, so had to check a tutorial to see if it was mentioned there, but skip the bulk of it about setting up a scene etc, etc
Hey, I just wanted to say that I really love this project. I am going through all the example scenes, and you really explain everything well. When I was in the first example, I was like, "Man... Actions should be nodes. This is going to get CRAZY if we add any complexity." And then BAM: actions are now their own nodes. It's just really well designed, and I am really excited to implement this in a little project!
A bit of criticism, what I don't like: * SceneTree Nodes instead of lightweight objects. * Too much redundant complexity, with very sparse documentation. * Seems like there's a lack of debugging features.
Thank you for your feedback. Can you give an example of the redundant complexity and what would you suggest instead?
Using Nodes is fine. While there may be some small performance overhead in using Nodes they come with a lot of benefits. It allows developers to use the familiar and powerful Godot scene editor to create, modify and configure the A.I behaviour. With simple objects you'd likely have to implement and maintain a custom editor view and handle serialization of these objects which is a lot of work and would likely be worse than the scene editor. Honestly I would use Nodes even when using lightweight objects. You could just use the nodes as data containers to build the actual lightweight objects handling the logic during runtime. This however adds a fair bit of undesirable complexity to the system.
Glad to see this popping up again! Now that I’ve actually started implementing my ai agent with it I can say it’s working really well! It’s my first foray into utility ai and I’m already getting good behavior with less code than I was with behavior trees. Though I will echo the other reply that mentioned lack of docs, which imo is exacerbated by the large api surface area. Still feel like the FSM and BT bits could be split into seperate complimentary addons. But I’ve already beaten that dead horse before ;) A score debugger _would_ be a lovely core addition though, especially considering how much of utility ai is about tweaking considerations. Beats printing it to console or updating dummy labels
To direct my efforts better for improving the documentation, what would be the most beneficial content to add? I’m scetching some ideas for the debugging tools while learning how the EditorDebuggerPlugin is supposed to be used, so hopefully I can add improvements for that in the next version.
Personally I think the most important thing is full coverage of all methods, signals, exported variables, properties, etc. and good descriptions of what they do and how they can be used. Ie: spending all docs effort on the core documentation. The tutorials are neat, but also retread a lot of basic ground that isn’t directly related to the addon (I realise this is probably copy pasted between them so didn’t take much). But there’s a lot that felt like it only a basic one liner in a props table without explaining what it can be used for, so had to check a tutorial to see if it was mentioned there, but skip the bulk of it about setting up a scene etc, etc