Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Event-based update for BT. #74

Open
ODtian opened this issue Mar 16, 2024 · 1 comment
Open

Event-based update for BT. #74

ODtian opened this issue Mar 16, 2024 · 1 comment
Labels
breaking-compatibility Implementing this issue would break compatibility with the current minor versions. enhancement New feature or request

Comments

@ODtian
Copy link

ODtian commented Mar 16, 2024

Currently, the BT update mode primarily invokes the _tick() method to poll the current state at each frame. This approach is generally inefficient when executing time-consuming asynchronous functions, such as playing animations, navigating, and timing. It may cause a useless function call just to poll whether it is finished.

For actions based on signals, implementation would be straightforward: set the update mode to manual upon node setup, and switch it back to auto upon exit. For user convenience, adding an option to automate this function for task nodes would be beneficial.

@limbonaut limbonaut added enhancement New feature or request breaking-compatibility Implementing this issue would break compatibility with the current minor versions. labels Mar 23, 2024
@limbonaut
Copy link
Owner

The decision to use a first-gen approach to behavior trees was made for simplicity, usability and maintainability sake. Concerning polling, it's all up to the implementation of the task. You can have _tick return a cached status, instead of polling, and still rely on signals for time-consuming external functions. Event-based approach can be reevaluated for version 2.0. It will likely cause major compatibility breakage. However, it may be possible to have a less invasive, hybrid solution, that would keep the API mostly intact. I'm not sure if it's actually worth it to optimize method calls like this (taking in the context of a hybrid solution). Maybe for massive cases with hundreds and thousands of simultaneously active agents.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-compatibility Implementing this issue would break compatibility with the current minor versions. enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants