You can do that, but it will require some additional work.
To communicate from the behavior Nodes to the Player, they can just call functions on it, (onready var player := get_parent()).
To communicate from the Player to the Behavior Nodes, you can:
- Have them set themselves as the “handler” for a task inside a variable of the player (for example a “var movement_handler” inside Player).
- Make that variable an array, if multiple “handlers” may offer their services.
- Or use a signal. The handlers connect to it, and anyone can emit the signal.
Note that the advantage of using an Array, is that you can have handlers that “try to do it once”. By that, I mean that they would return whether or not they where successful in handling their task, and you can break the loop as soon as the first is.
To communicate from the Behavior Nodes to other ones, you can do the same as above, but also use the “meta” functions, set_meta(), get_meta(), etc. The advantage being that this needs less assumptions on the Player, if you want to put those behavior Nodes on things with entirely different scripts.
Thank you for your answer. I decided on a similar implementation.
I made a node and called it input and attached a script to it.
Then I decided to put the logic related to input in there so that I can easily reuse the node later if I need input on other node trees.
Then I called the logic in my input node from the player node using get node while adhering to the technique of getnode down and signal up.
This way leto me create code so that I won’t have to write input logic again.
While also letting me put the player behavior logic in the player script.
My own extra thiughts:
For example we need to get player direction and I put that logic in the input node.
But for the speed applied to position logic i left it in the player script. Perhaps later I could put that into a movement node as well where I can build various functions on how exactly movement should be done.
This helps me easily reuse my code as a node and not have to write things more than once.and keep adding onto my input node for new functionality I may require or simply reuse old functionality.
Another example which I haven’t tried yet
For all my collision logic I can place it into my Collisonbody2d node script and by doing so I could seperate collision detection logic into that node and put the players reaction to the collision in the player script.
I chose to write my code in this way because at the moment it feels like the best format for me to build upon my code and reuse on other scenes later. As well as it being nice to be able to write my logic as scripts with single responsibilities only.