Closed leleleSDX closed 10 months ago
Thanks, that's a good observation. I went with nodes because it is easy to use them to create the structure and to extend them. I believe the idle processing (_process-method) and physics processing (_physics_process-method) are only called if the method for them has been defined - though I'm not that well versed in Godot's source code to be 100% certain that there wouldn't be some processing going on in any case. I'm going to have to do a bit of research and testing to see what would work best to trim them down if that turns out to be a performance bottleneck in the future.
I like the idea about using resources in the inspector for considerations and actions, I'll look in to that for the 1.5 release. I'm just now finalizing 1.4 which brings in Behaviour Trees that work together with the Utility AI Considerations. Maybe for the BT-nodes as well the use of resources can give more flexibility and make larger numbers of custom properties more manageable. So I'll add that to my todo-list for 1.5, too.
I've now added resource-versions of the considerations, so they will be included in version 1.5. Performance wise, hard to say yet if they are more efficient or not (needs measurement), but they do make the node structure cleaner especially for the behaviour tree nodes. To make debugging easier some additional inspector view is likely required, but that I'll include in a future version.
Forgive for the rhetorical question. But I kinda noticed that we extend the native class Node for each property of the Utility AI.
We can get up too 100s of nodes from the behaviour ai if we're making actual games. "Node" kinda takes and makes too many calls.
Is there a way we can trim them down. Maybe change some properties to extend Refcounted. Like maybe considerations and actions be pushed inside the Inspector as a resource for behaviour nodes?