I'm still learning about Behaviour Trees and my understanding of the "blackboard" is essentially a state object. When passing the state object through the ticks to the function calls (which are nodes and leaves), how should I share the states amongst all the executions of the trees triggered from all previous ticks?
I initially thought the states should be immutable so that the functions can be "pure". However, if the states are immutable, that would mean that whatever consequences triggered from a previous tick will have to be performed in its entirety even if a later tick that came in the middle of the execution has a different state value.
For example, if the behaviour tree was something like this:
When Tick_1 first came in, the state was something like this:
{
user: { cash: 10 }
}
So, at Tick_1, user has $10 and has enough cash to buy milk. The behaviour tree will go down the path of walking to the store and then buying milk.
However, the action of "Walking to Store" is asynchronous and takes some time before the "Buy Milk" action can take place. Now, when the "Walking to Store" action from Tick_1 is still taking place, another tick Tick_2 came in at this time with a state that the user now has $0 in his pocket:
{
user: { cash: 0 }
}
Based on the latest state from Tick_2 the user has no more money probably due to something that happened during Tick_2. But because the previous execution of the tree from Tick_1 is still in progress and has no knowledge about the new state since its copy of the state is the old one and they don't shared a common mutable state, it will eventually go on and perform the "Buy Milk" action when it really shouldn't because by this time, the user has no more cash!
It seems to me that if the states passed to the ticks are immutable separate copy of states, the previous decision made has to be completed and we can't "cancel" the previous decision or execution.
If we use a shared state, however, this would mean the state is mutable and any of the functions or actions can change them through any side effects. It might turn out to be very messy and difficult to maintain with too many places changing a common state.
My question is:
- How should the blackboard or states of a behaviour tree be constructed? Should the states be mutable or immutable?
- Should every ticks share a common copy of states so that executions of the tree from the previous ticks are aware of the latest values in the states so that they either stop proceeding or react differently?
- If so, how should this be done elegantly?
I'm using Typescript in my case but I'm assuming(?) the concept should be similar in any other context and languages.
PS: I guess I could swap the positions of the condition and "walk to store" to reduce the problem in my example but I'm trying to use this to illustrate the dilemma I'm having.
